macOS Carbon vs. Cocoa: A structured debate

[GothicChess.Com]

I guess that depends on what you sell. If its a shrink wrap kind of product, then a rewrite could add new features or UI fluff which would allow you to market it as a new version. New customers pay full price and existing customers have the option to upgrade at a discounted rate. This revenue will help offset your investment in development with the added benefit of future proofing yourself from the eventual deprecation of Carbon.

This wins the EASIER SAID THAN DONE AWARD by a landslide!

1. That is a Micro$oft Mindset in Microcosm -- "add some feature, charge more, sell upgrades", even if there is really no need for the "fluff" that was appended to the software package.

2. Where do you think the money is coming from to pay for the upfront development to make the product(s) happen? You can't create demand for a non-existant product, nor can you spend money on sales that haven't happened yet!

3. The time-to-revenue would be extremely long, and time-to-profitability much longer. If your focus group marketing showed something like:

$profitability/manpower cost = K/time to develop

...where "K" is some very attractively large constant, your most critical factor would not be manpower cost, but time to develop. In that case:

$profitability = K x manpower cost/time to develop

Since manpower cost is tied to development time, the quicker you get it out the door, the better off you will be. But, as we know:

• development time for such an undertaking would be long
• The constant "K" is most likely not large
• Operations cost are ongoing, even if there is no profit!

 

[Krevnik]

Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

If you don't actually need a 64-bit UI (and really, how many people do?), then just write your computation code in a CLI app and just call it from your Carbon app.

Incidentally, I wonder if you can fork()/exec() from a 32-bit executable to a 64-bit executable...

This is the recommended way to run an app that needs 64-bit in Tiger, FYI. So yes, it is possible.

It does complicate your app somewhat though, since you are now talking about interprocess communication.

 

[Catfish_Man]

One nitpick; the Cocoa menu system is built on top of the Carbon MenuManager. The rest of Cocoa is, as stated in the thread earlier, unrelated to Carbon (mostly built on CoreFoundation or other lower level APIs).

I'm also wondering whether we'll get a Cocoa replacement for HITheme for custom control drawing. I know of several cocoa apps that use it (fairly major ones).

 

[mags631]

Metrics?

Any one have metrics on LOC differences between Carbon and Cocoa for same functionality? I have to believe Carbon source code > Cocoa source code given that Cocoa requires much more handling by the developer... but I don't have any metrics on that. Links?

 

[garethlewis2]

Here is how it really works.

You build an application in Carbon and then tell Apple to screw themselves for mandating the use of Cocoa. Your competitor decides that using Cocoa and all the features and ease of use that brings is worth the risk. One year later, your product is no longer used and theirs is. And yes, this is how things are done in the real world.

I work in Financial software development. The previous company I worked at continued using C when everybody else was moving to Java or C#. The head of IT stated the risk of moving to Java was too great. They were the biggest supplier of financial software to Wall Street and all investment banks. One year later, they had no customers. The CIO's of all the banks had read the releases from Gartner and Sun stating C's days were over as an enterprise platform due to massive problems with memory overruns and requiring a particular platform to run on. They were not willing to give in to the companies worries about cost rewrite or testing. Nobody in Finance uses C, the front office guys use C++ and Motif as they still believe this is the fastest way to run a program. They are a minority.

 

[Eraserhead]

I have to believe Carbon source code > Cocoa source code given that Cocoa requires much more handling by the developer...

Why, Cocoa seems to require less work than Carbon according to Wil Shipley, and his arguments, at least on that make sense.

 

[gnasher729]

Why, Cocoa seems to require less work than Carbon according to Wil Shipley, and his arguments, at least on that make sense.

Cocoa isn't bad at all for new development, especially for Mac-only new development, plus if you want to use some really nice new features then you are actually restricted to Leopard only development. Makes lots of sense for in house development where you can control what OS the end users are running.

Cocoa is awful for cross-platform development. All the good features are pointless, because you have to rewrite everything from scratch for Windows, for example. Using Carbon, you can take an existing Windows application and turn it into something that looks right on Windows, looks right on MacOS X and is maintainable for the future (not everybody does it right, it requires having developers who understand the Mac and MacOS user interface, but it is not really difficult). With Cocoa, you can't do that. You have to rewrite the user interface completely.

 

[elppa]

Cocoa isn't bad at all for new development, especially for Mac-only new development, plus if you want to use some really nice new features then you are actually restricted to Leopard only development. Makes lots of sense for in house development where you can control what OS the end users are running.

Cocoa is awful for cross-platform development. All the good features are pointless, because you have to rewrite everything from scratch for Windows, for example. Using Carbon, you can take an existing Windows application and turn it into something that looks right on Windows, looks right on MacOS X and is maintainable for the future (not everybody does it right, it requires having developers who understand the Mac and MacOS user interface, but it is not really difficult). With Cocoa, you can't do that. You have to rewrite the user interface completely.

Unless Cocoa gets ported to Windows…

 

[jeremy.king]

1. That is a Micro$oft Mindset in Microcosm -- "add some feature, charge more, sell upgrades", even if there is really no need for the "fluff" that was appended to the software package.

Nope...hate to break it to you, but this is just how the software world works. Even Apple does this with every major OS upgrade.

2. Where do you think the money is coming from to pay for the upfront development to make the product(s) happen? You can't create demand for a non-existant product, nor can you spend money on sales that haven't happened yet!

Well, this particular example was about an existing company, so they should have some level of ongoing sales/support revenue to help offset the initial development.

3. The time-to-revenue would be extremely long, and time-to-profitability much longer. If your focus group marketing showed something like:

$profitability/manpower cost = K/time to develop

...where "K" is some very attractively large constant, your most critical factor would not be manpower cost, but time to develop. In that case:

$profitability = K x manpower cost/time to develop

Since manpower cost is tied to development time, the quicker you get it out the door, the better off you will be. But, as we know:

• development time for such an undertaking would be long
• The constant "K" is most likely not large
• Operations cost are ongoing, even if there is no profit!

Profitability = Revenue - Cost where costs including development time, marketing, support and distribution amongst other things. Not sure what your K constant is supposed to represent - perhaps you are trying to show that some costs are the same no matter what technology is being used.

Using your own formula, since the time to develop is generally much faster using Cocoa, its in the business' best interest to adopt it for greater profitability.

 

[GothicChess.Com]

The previous company I worked at continued using C when everybody else was moving to Java or C#. The head of IT stated the risk of moving to Java was too great. They were the biggest supplier of financial software to Wall Street and all investment banks. One year later, they had no customers.

<opinion> This sounds extremely exaggerated. I know of some pretty bad companies, especially from the mid 1980's, that built their foundations on matchsticks that survived longer than a year amidst seas more turbulent than those "waves" that are created merely by the consequence of your development platform! Come on, who can run off 100% of their own customer base, even IF they did plaster all of the Wall Street Journal "We code in C, we code in C" ? How can the external buyer say "Damn, this was written in C, I ain't buying it!", can you tell me that?
</opinion>

 

[GothicChess.Com]

Nope...hate to break it to you, but this is just how the software world works. Even Apple does this with every major OS upgrade.

I ran two software startup companies. One in the late 1980's early 1990's (Circumflex Software) and one in the mid 1990's (Infinite Loop Software.) Your example is NOT how the software world works.

Well, this particular example was about an existing company, so they should have some level of ongoing sales/support revenue to help offset the initial development.

Very, very poor assumption when you talk about jumping to entirely different coding environment. You can't "offset" something unless you have 100% of it in cash reserves to start. Do you even work for a real software development company? Some of your comments reflect extremely puerile thinking.

Profitability = Revenue - Cost where costs including development time, marketing, support and distribution amongst other things. Not sure what your K constant is supposed to represent - perhaps you are trying to show that some costs are the same no matter what technology is being used.

Using your own formula, since the time to develop is generally much faster using Cocoa, its in the business' best interest to adopt it for greater profitability.

My formula was a first order extraction governing only the model of switching platforms, not an general formula applicable businesswide. And, you missed the point.

The time to develop an entire company's software suite as Cocoa applications is NOT faster if you are talking about retraining an entire staff first! Or, I suppose you would fire everyone and hire Cocoa staff and tell them to build it from scratch?

Do us all a favor, talk about stuff you know.

 

[jsw]

I ran two software startup companies. One in the late 1980's early 1990's (Circumflex Software) and one in the mid 1990's (Infinite Loop Software.) Your example is NOT how the software world works.

I work for a large corporation and work on network appliance management software. kingjr3's model describes exactly what we've done with that product - add features to make the people on maintenance feel they're getting their money's worth because they see new things listed with each upgrade. It's cheap, easy money. And companies are very much interested in cheap, easy money. Yes, someone uses every new feature. But no one uses all of them, and many are minor.

Very, very poor assumption when you talk about jumping to entirely different coding environment. You can't "offset" something unless you have 100% of it in cash reserves to start. Do you even work for a real software development company? Some of your comments reflect extremely puerile thinking.

Well, you need to be able to finance it over the development period, so you don't need 100% to start. You need income sufficient to handle the development costs as they occur.

The time to develop an entire company's software suite as Cocoa applications is NOT faster if you are talking about retraining an entire staff first!

It depends on how strategic your plans are. If you're living quarter to quarter, you won't do it until you need to, and then you'll go a long time without revenue. If you can think longer-term, you'd start doing it earlier.

 

[GothicChess.Com]

I work for a large corporation and work on network appliance management software. kingjr3's model describes exactly what we've done with that product - add features to make the people on maintenance feel they're getting their money's worth because they see new things listed with each upgrade.

Adding features for features' sake is not a way to build repoire with your clients.

And, does your company advertise it's practice of spawning versions it has no core belief in, other than the knowledge it will lead to more money downstream?

Whenever we released a new version, we were all proud of the enhancement, and we were sure there was "nothing left to add" because the new version was "so great."

We had dedicated staff in place to actually read letters and emails sent to us by users. This staff would review the requests, correspond with the user base, and prototype recommended changes that were seemingly worthwhile. We would send specialized betas to these core users, with their names emblazoned in their special version's about box, and we developed a large, loyal base of testers this way.

With so much positive feedback, we would eventually realize "Hey that guy in Tulsa has a pretty good idea, I think we should roll this out in the next version..."

And that's how we made the next version, and we were sure there was "nothing left to add" because the new version was "so great."

 

[GothicChess.Com]

It depends on how strategic your plans are. If you're living quarter to quarter, you won't do it until you need to, and then you'll go a long time without revenue. If you can think longer-term, you'd start doing it earlier.

It depends how strategic the stockhoders will tolerate you mean If your profit-to-earnings ratio thins out, so will your investor base. If you want to start getting granular, so can I You can't just withhold small chunks of money for some forever-away-date to dump when it comes time to make major revisions without an Executive Board Meeting. It's also tough to keep such big plans "secret" for a long time, and, inevitably, there is some competitor who will get wind of it, then leverage something to counter your initiative.

That's how the real software industry operates, not with non-stop rollouts served up to deep-pocketted lemmings.

 

[iSee]

An analogy of 32 to 64-bit is a bit like moving from a 4000 sq ft home to a mansion when you lived alone most of the time. While the old 16 to 32-bit move was a bit more like moving from a Japanese apartment in downtown Tokyo to the 4000 sq ft home. You get a lot more benefit moving out of the apartment than you do the house.

LOL! That's the best analogy I've seen no this. Back in the 16-bit days you constantly had to deal with the the limitations and tradeoffs. While there are definitely certain circumstances where 32-bits aren't enough, it is not a central issue, day-to-day, for most apps.

 

[jeremy.king]

*Snip some endless blabbing about how great you were*

Do us all a favor, talk about stuff you know.

Ed, what's the point of starting this thread if you have all the answers?

I don't need you to "learn" me how the software world works. In fact, the software world is much different than the 80s and 90s and its more than Blackjack or Chess, that's for sure. People want more and more and they want it now. Customers are impatient and are more than happy to pay for new versions. You wonder why things like Agile Methodologies are so popular nowadays - it's because software needs to change and adapt faster and faster.

You say you worked for two startups in the 80s and the 90s? Where exactly are those companies you mentioned today? What products were so great that they are still around today? Oh wait?! Let me guess, you got burned when OS X couldn't run them anymore? I really am curious all mighty one.

You are right, I don't work for a software company. I am a consultant and I have been in and out of various software companies so I have seen how they operate. I have seen what works and what doesn't. Speaking of which, why would you list your past companies as software consulting firms on your profile on GothicChess?

 

[RacerX]

Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it

What you should take into consideration is the fact that many of the people that designed the software environment for the 128K Mac left Apple with Steve Jobs and started creating NEXTSTEP.

For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.

But at what level are you really at when you are at "Programming the Macintosh: Day 1" with Cocoa compared to "Programming the Macintosh: Day 1" with Carbon?

With no programming background at all I can have a functioning app running within a short time with Cocoa... but the same couldn't be said with Carbon. I started on Macs back in 1987 and never got beyond a Hello World type of app (not counting AppleScripts). But I was able to create functional, useful apps in OPENSTEP on my first day. One of the reasons NeXT systems took off in many math departments was that with no programming experience at all people could write elaborate apps that could access Mathematica's kernel as their math engine.

So, given that other developers would probably be in the same boat, I ask the group, what is there to gain by undergoing "programming brain surgery" to learn Cocoa? What can a Cocoa application do/offer/perform that a Carbon app cannot?

While it should be noted that these days it is short sighted to think of this as a one or the other type of thing (you should be trying to take advantage of both where ever you can), the primary advantage of Cocoa is the same as it has been since almost day one back in the late 1980s... services.

The primary idea (beyond object oriented programming) of this environment was to make sure that developers didn't waste time reinventing the wheel with each new app. A great example is spell checking. Word has a spellchecker, so does AppleWorks and QuarkXPress, and even Illustrator. Why should you have four spell checking engines with four custom dictionaries? That is the type of thing that developer's shouldn't have to worry about.

Or how about font handling? A friend of mine (Andrew Stone who wrote the first third party app for NeXT systems) wrote TextArt for NEXTSTEP back in 1988 building on that system's Postscript foundations. He had started out much like you writing apps in Pascal on the Mac, but was able to make incredible software almost instantly on NeXT (TextArt, which later became Create, and DataPhile).


In all reality, you are doing yourself a major disservice saying that Cocoa looks like Windows because Cocoa and you have similar origins back with the original Mac. Instead you should embrace your shared heritage with Cocoa.

 

[jsw]

Adding features for features' sake is not a way to build repoire with your clients.

It seems to be generating revenue for us as well as for a number of other companies who do the same thing.

And, does your company advertise it's practice of spawning versions it has no core belief in, other than the knowledge it will lead to more money downstream?

No, because that would be stupid.

Whenever we released a new version, we were all proud of the enhancement, and we were sure there was "nothing left to add" because the new version was "so great."

I note the past tense.

What you did was great for apps you build because you love them, but not so great for apps you build so you can continue to have a job. If you wait until there's nothing left to add, you lose revenue on future releases. Software is a business, and the business of business is to make money.

We had dedicated staff in place to actually read letters and emails sent to us by users. This staff would review the requests, correspond with the user base, and prototype recommended changes that were seemingly worthwhile. We would send specialized betas to these core users, with their names emblazoned in their special version's about box, and we developed a large, loyal base of testers this way.

Again, nice and also past tense, but you opened yourself up to lawsuits if someone recommended something and you implemented it, especially unscrupulous customers that would suggest patent-infringing features.

And that's how we made the next version, and we were sure there was "nothing left to add" because the new version was "so great."

So... how's it selling now?

It depends how strategic the stockhoders will tolerate you mean If your profit-to-earnings ratio thins out, so will your investor base. If you want to start getting granular, so can I You can't just withhold small chunks of money for some forever-away-date to dump when it comes time to make major revisions without an Executive Board Meeting.

No, you plan for release dates and hit them. We do.

That's how the real software industry operates, not with non-stop rollouts served up to deep-pocketted lemmings.

Really. Well, we must know about different industries, then.

 

[SC68Cal]

Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>

Raise your hand if you care. This is not relevant to the debate.

In fact, didn't Wozniak back a lot of ventures and products that took a nosedive?

SEGWAY POLO ANYONE?

Greybeard.

 

[GothicChess.Com]

No, because that would be stupid.

My point exactly! If you TELL your customers about WHAT YOU DO, you would lose business! Yet, you have no problem doing it! Don't you have a conscience?

What you did was great for apps you build because you love them, but not so great for apps you build so you can continue to have a job.

NOT TRUE!

I built a small company that had only 4 products, one of them a shareware Blackjack program that was only $20. The shareware was released from 1991-1993, then the company was launched. We discontinued the shareware in 1993, launched the 4 programs product suite, sold the apps from 1993-1998, built up a consulting practice with the software sales revenue, sold BOTH businesses, and I retired at age 32. Then I started something else when I got bored

BUT WE WERE STILL GETTING SHAREWARE REGISTRATIONS IN 2003, 10 YEARS LATER!

While diminished greatly by that time, there were still about 1800 per year at $20 each = $36,000 a year. That's one product, on a dead platform, 10 years after final cutoff, and still generating revenue. It's like record sales for Elvis, going on long after he moved on. Of course, the checks went uncashed, but that is not the point.

Again, nice and also past tense, but you opened yourself up to lawsuits if someone recommended something and you implemented it, especially unscrupulous customers that would suggest patent-infringing features.

1. Our customers were loyal, not bloodsuckers.
2. We had attorneys on retainer when there was any doubt.
3. We're not stupid.
4. I have a U.S. Patent, #6,481,716 issued on November 19, 2002, so I am well versed in intellectual property matters.

So... how's it selling now?

The businesses were sold for a scalar multiple of their annual revenue streams to someone who took it to the next level. No mortgage on my 3 homes, no car payments for the rest of my life, so you tell me if I did the right thing

 

[janey]

I am looking for facts.

Well, judging from the lack of info about how much of Carbon won't be 64bit, are you expecting people to pull facts out of their asses or break NDA?

Your example is NOT how the software world works.

Do you realize that if you just read what you replied to and thought about it, it's practically what Apple and everyone else in the industry does all the time? You absolutely don't even have to be doing this for a long time or even know much to see this with plain eyes.

Or are you actually saying that Apple doesn't "'add some feature, charge more, sell upgrades', even if there is really no need for the 'fluff' that was appended to the software package."? I'm sure there's a LOT of things out there that changed in Leopard, Tiger...10.x, 9.x, ... that people considered as "fluff" or unnecessary but upgraded for various reasons.

"Fluff" is also highly subjective. I think Front Row is fluff. Automator is fluff. Time Machine is fluff. Dashboard is fluff. I think Voiceover updates in Leopard are sweet as hell, but I'm quite sure there are lots of people out there who don't know what Voiceover is, so for them it might as well be fluff.

Honestly, out of the over 300 "new features" in Leopard, how much of that will be fluff to you? I bet you won't even notice 300 "new features".

Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>

I won't be very impressed until you have a Knuth check.

 

[Eraserhead]

How can the external buyer say "Damn, this was written in C, I ain't buying it!", can you tell me that?
</opinion>

Because this is Finance software, if it isn't secure or is unreliable it isn't worth running, the amount of money lost for a software crash isn't worth it.

Adding features for features' sake is not a way to build repoire with your clients.

That's what MS does, and they are one of the worlds largest companies.

With no programming background at all I can have a functioning app running within a short time with Cocoa... but the same couldn't be said with Carbon.

One interesting point that I have noticed recently is the amount of Mac only freeware/shareware that is excellent, and a lot of it is free too. There is more than when I was running Windows a couple of years ago, which is incredible given that Windows has 15x the market share, it shows that the Mac development tools and frameworks are far better than on Windows.

When I was using OS 8/9 back in 1998, I noticed that most Mac free/shareware was expensive and not anything like as numerous as for Windows 98. Whereas now the situation has reversed, even though Windows has continued to dominate.

 

[GothicChess.Com]

Because this is Finance software, if it isn't secure or is unreliable it isn't worth running, the amount of money lost for a software crash isn't worth it.

So you are saying EVERY program written in C is unreliable and not worth running? And how many C programs do you think have been written in the last 41 years??

I have written Finance Software add-on modules for ADP, which ran on the payroll server at Morgan, Lewis, & Bockius, LLP, which was the 4th largest lawfirm in the United States at the time (was like 1998.) It was a C program that linked directly to the First Union Bank in Philadelphia (now Wachovia) and it moderated the outbound feed and performed some complex transactions on the overseas payroll, which ADP does not get involved with. It effected the people in the offices in Brussels, London, Tokyo, Jakarta, and Frankfurt.

That's what MS does, and they are one of the worlds largest companies.

They are also the most corrupt. They were investigated by the Department of Justice for unlawful business practices, remember? Netscape created a fantastic product, the web browser, and Microsoft tried to absorb their innovation by making it part of the OS, cutting off the outside worlds' attempt to market their own browsers, which were vastly superior at the time.

 

[kainjow]

This thread has gotten way off track. We're discussing Carbon vs Cocoa, not software development business strategies.

1. Is Carbon here to stay?

No. As you have already seen, they are not investing 100% into 64-bit Carbon, but they are investing 100% into 64-bit Cocoa.

2. If Cocoa is the way of the future, what benefits does it have over Carbon?

See below.

Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it

That's simply a matter of what you're comfortable with.

For example, Cocoa bindings is not "natural" to me since I started learning Cocoa before bindings, and bindings to me now doesn't add much benefit. Fortunately, bindings isn't "the future" but it's merely a convenience. But I have to learn it, either way (already know it fairly well).

What can a Cocoa application do/offer/perform that a Carbon app cannot?

Well, like I said, Apple is now investing everything into Cocoa. It is the future. It is easy to rapidly develop full featured applications in it. We are now in the time where most hard things have been done for us, and so we get to concentrate on what the actual app does. Like someone else said, it is given that every window you create in your app will all be closable, draggable, minimizable, etc. We don't need to implement that ourselves. It is a checkbox away. That is how Cocoa differs from Carbon.

It is 2007. Cocoa is mature. I am sorry that you are just now realizing that Cocoa is the "top dog" for OS X programming. But if you want to continue your career as a Mac developer, you must learn Cocoa (unless you want to write drivers all your life ).

 

[GothicChess.Com]

I won't be very impressed until you have a Knuth check.

My check was for a great deal more than $2.56, which is basically chicken feed considering Knuth has people "working for free" as proof-editors, a pretty good scheme.

I hold no candle to Knuth, I'm sure it's reciprocal.

Well, like I said, Apple is now investing everything into Cocoa. It is the future.

That being said, is there some, definitive references, the functional equivalent of the old Inside Macintosh volumes, for Macintosh Cocoa programming?

And, is there an expected "drop dead" date when Carbon apps won't run on a Macintosh?