The Myth Of Cocoa Apps
There's this myth that's existed ever since the beginning of OS X – that Cocoa apps are automatically better than any other type of application. They use less RAM, run faster and are just all round better – you can't dispute it. If you take a lousy carbon app and rewrite it in Cocoa it will become amazing and all it's problems will be solved.
This is of course, complete and utter bull.
The latest person to buy into that theory is Paul Stamatiou with his review of VMWare Fusion:
Fusion was built from the ground up in OS X’s native programming environment, Cocoa, and as such Fusion benefits from speed increases and lower memory overhead. The use of Cocoa in the development of Fusion also means that Fusion puts less strain on your computer than any other virtualization product at this point.
Actually, Cocoa requires Objective-C which is a much higher level language than pure C and with every level of abstraction comes increased memory usage and slower performance1.
Cocoa is a great framework and it makes developers a lot more productive but it's not some magic bullet that makes an application fabulous. Yes, it's easier to create a really "Mac-like" application with Cocoa than with Carbon or other frameworks, but from an end user's point of view it just doesn't matter whether or not the application is Cocoa. Let's get over it and move on.
See also:
1 – not that you shouldn't use Objective-C, it just won't magically make your code faster↩
August 7th, 2007 at 5:35 pm
That’s how it was essentially packaged to us in VMware’s conference call; don’t kill the messenger. ;-)
August 7th, 2007 at 5:53 pm
Don’t believe everything you hear, particularly when it’s from a marketing guy talking about technical issues.
August 7th, 2007 at 8:38 pm
Doesn’t Carbon need more GUI adaption layers than Cocoa?
(Or isn’t Carbon developed on top of Cocoa and uses Cocoa for GUI rendering? Is Carbon directly on top of Quartz?)
Peace
-stephan
August 7th, 2007 at 8:56 pm
Carbon is not developed on top of Cocoa – they sit side by side on top of Quartz (roughly). If anything, Cocoa is built on Carbon, though that’s only for certain aspects. Regardless, the biggest difference is in the language that is required – Cocoa requires Objective-C whereas Carbon requires C/C++. You can use C/C++ in a Cocoa app, but the Cocoa APIs themselves are Objective-C and so is Cocoa itself.
The bottom line though is that it makes no difference – an end user of the application simply won’t be able to tell the difference if you write the application properly.
August 7th, 2007 at 9:13 pm
Thanks for the clarifications, as a Java developer (though long time MacOS user) I don’t have much knowledge of Cocoa/Carbon. I’ve learned something.
Peace
-stephan
August 8th, 2007 at 1:28 am
Really, the comparison was intended to be between native toolkits like Cocoa *or* Carbon, and non-native toolkits like Qt.
Qt makes apps that look and feel almost, but not quite, entirely unlike native apps. Qt also has a lot of really weird resource consumption issues on Mac (take a look at your WindowServer memory usage in Activity Monitor after running a Qt app!), so Cocoa really does put less strain on the OS.
August 8th, 2007 at 4:45 pm
“The bottom line though is that it makes no difference – an end user of the application simply won’t be able to tell the difference if you write the application properly.”
Agreed, but “[writing] the application properly” is a huge, huge “if”. The reason that this myth has propagated and persisted is precisely because you CAN tell the difference between a Cocoa app and a Carbon app. Not necessarily in the memory usage or the performance aspect (although as you point out Cocoa apps often use MORE memory and CPU), but in the interface.
There are *so* many things that are dead giveaways for Cocoa apps, for the vast majority of the time. Standardized customizable toolbars, the dirty dot in the close button, the application shipping as a package rather than an app that has a data folder outside of it, the availability of services, standard spell-checking with red underlines, command-dragging to select discontiguous text in a text area, option-dragging to select a square of text in a text area, etc., etc., etc.
Yes, I know all of these things can be made to function in Carbon apps, but they take time and effort and very few Carbon developers take the time to do that. The result is that it is often very easy to tell whether a given app is Carbon or Cocoa. So, yes, in a sense, it *does* matter from an end-user’s point of view whether or not an application is written in Carbon or Cocoa, because you *can* easily tell the difference!
I’ve heard this refrain over and over again, of barking at users for wanting an app written in Cocoa. But it’s not them that’s at fault — after 6 years of Mac OS X, they can tell when an application is Mac-like and when it isn’t, and the vast majority of the time, “Mac-like” means “written in Cocoa” because the developer doesn’t have to think of all the little niceties that Cocoa offers for free. And that translates to a better user experience for users, which translates to them wanting more applications written in Cocoa so that they get those standard features. Don’t blame the users if they’re not articulate enough to say WHY they want something written in Cocoa: they’re not the ones doing application development, so they’re hardly expected to know how to articulate exactly what they want in a program. Perhaps you should blame Carbon developers for not implementing those niceties, or perhaps you should blame Apple for not making those niceties easier to implement in Carbon, or whatever.
In the end, it’s the job of the *developers* to get this perception turned around. But it’s disingenuous to tell your users to be quiet about what framework to write your apps in when there’s some truth to what they are saying.
August 8th, 2007 at 4:52 pm
Actually, I think he compares Cocoa to Qt, which is used by Parallels, not Carbon. And Qt sucks on any platform.
August 8th, 2007 at 5:03 pm
Carbon must have a much bigger impact on Mac resources than you realize. Isn’t that why we keep hearing about Carbon credits in the news all the time? Supposed to be a way of managing the impact of all the environment damaging, resource abusing Carbon out there. Something to do with Apple’s board, Al Gore, etc. I’m pretty sure the proceeds are used to fund the development of alternate Cocoa applications.
August 8th, 2007 at 5:13 pm
Simone, you make a good argument but none of that applies to an application that is precisely designed to run other OS’s on top of OS X – it is by definition not Mac like. It also does almost nothing with windowing toolkits – the vast majority of Parallels and Fusion will be the virtualization code, not the UI. All a virtualization app needs to do is get a rectangle on screen that they can draw to and display the odd preferences dialog. I doubt that Qt is really making that much difference to Parallels because of precisely that but I could be wrong.
It’s also embarrassing that VMWare are touting the use of Cocoa as such a big feature – it’s irrelevant to users, they should have focussed on the wonderful text selection capabilities that they don’t have any need for. :)
BTW, I suspect you came via Daring Fireball which only quoted the first paragraph about Cocoa vs Carbon so I understand where you’re coming from.
Mark – funny.
August 8th, 2007 at 5:51 pm
Adrian: yes, you did reference VMWare specifically and perhaps my arguments don’t necessarily apply there (and yes, I did come from the DFLL :) ), but you’re still addressing the general situation in the last paragraph.
Sure, I agree that it’s dumb to tout something as being “made in Cocoa”, but since, as you pointed out, the argument has been reinforced over six and a half years of Mac OS X, perhaps the VMWare makers consciously made a decision to tout it being written in Cocoa. It’s not an entirely ridiculous possibility: there’s precedent in Andrew Stone of Stone Design who lambasted Carbon apps and refused to support them in his FontSight software.
August 8th, 2007 at 6:00 pm
Well, it DOES matter to the end user.
But not for the reasons you’ve mentioned, though Simone was pretty close.
I’m not a programmer. My mac is powerful enough that I never really have to worry about my computer resources, which is strange coming from a PC environment where every bit counts.
But why it matters is program and service interoperability. So many of my apps can do some pretty amazing things, but they need to work with cocoa apps to get the full range of abilities. Hell, I’m not a big fan of Safari at all… I love Firefox, but I end up using Safari because its cocoa – its faster, and I can easily use it with other applications. And as Simone says… it is more Mac- like, it is what I expect a mac application to be.
More to it all than Ram and processor usage – thats why we use Macs, cause Apple realizes that.
August 8th, 2007 at 6:27 pm
Simone, John Gruber put forward quite a good argument why the Cocoa-only FontSight software was a stupid policy – namely, that all the major applications that people who really care about fonts use are carbon. I’m not overly familiar with that case though so I’ll defer to Gruber’s comments. I also understand why VMWare would play the Cocoa card – it does resonate with a lot of people as meaning the software is wonderful, it’s just technically ridiculous and since I’m a technical guy I called them on it.
Gideon, it’s funny you should use Safari and Firefox as examples of good Cocoa, bad Carbon. Firefox isn’t Mac like because it is deliberately made to be cross platform with as little platform specific code as possible. There’s no wonder it doesn’t act like a Mac application. Additionally, Safari is faster because the key objective for the Safari team was to create an insanely fast browser – they have performance benchmarks that must be met before they’ll ship a release. It’s that focus on being fast and Mac like that makes it a better browser than FireFox, not the particular framework they chose to use. That’s why developers get so frustrated that people focus on the framework so much instead of the quality of the application – it’s a red herring and it’s not hopeful. It’s very rare that rewriting an application from scratch makes it a better application (http://www.symphonious.net/2006/05/28/when-should-you-rewrite/) – normally it just reintroduces bugs that have previously been fixed and trades one set of problems for another. You don’t want a Cocoa Firefox, you want the Firefox development team to focus on being Mac-like and speed which is completely different.
All that said, if you’re starting a new OS X app from scratch you would be well advised to use Cocoa than Carbon – it is a much better framework for development and makes a lot of things easier, but if you have a Carbon app it’s unlikely to be worth switching.
August 8th, 2007 at 6:32 pm
Sure sure, I agree there. The speed isn’t the big concern though… it’s the interoerability.
I’m not saying Cocoa’s bad, just that when it comes to using the programs I use a lot like Curio or Yojimbo – a program being in Carbon is a problem. Because I can grab something quite easily in a Cocoa app, and not so much with a Carbon one. The web browser issue comes up because there is where I most often must pull info.
I’m not arguing with the fact that Carbon cannot be as good as Cocoa or fast or whatever else, because I’m just speaking as an end-user who those minor differences don’t matter much to. I want things to “just work” and when I use a Carbon app in the context of services or interoperability, I cannot depend on that.
August 8th, 2007 at 6:35 pm
“Simone, John Gruber put forward quite a good argument why the Cocoa-only FontSight software was a stupid policy [...]”
Oh, I’ve read Gruber’s articles on that, and I agree. And I agree that it is a ridiculous policy. And I agree that they should be called on it. :)
“That’s why developers get so frustrated that people focus on the framework so much instead of the quality of the application – it’s a red herring and it’s not hopeful [helpful?].”
But that’s the thing. More often than not, it’s *not* a red herring. Sure, for VMWare it’s ridiculous that they tout Cocoa. And sure, it’s the policy of Firefox to be as cross-platform as possible. But for many situations, Carbon developers don’t focus on implementing all of the tiny little things and it shows, to users of all amounts of Mac experience, and they latch on to the Cocoa vs. Carbon issue. In these cases, the choice of framework did have a direct impact on the quality of the application. Rewriting them in Cocoa isn’t the right way to solve the problem, but users who want Cocoa apps aren’t latching on to a ridiculous notion, they just lack the ability to articulate exactly what it is about Cocoa apps that they want.
August 8th, 2007 at 6:41 pm
I think we’re basically agreeing but viewing it from different angles. As a developer I blame the developers not the frameworks, users tend not to look that deep see the trend that Mac-like apps use Cocoa and unMac-like apps use Carbon so they ask the developers to switch to Cocoa instead of what they really want. The real complaint probably should be at Apple to find ways to make Carbon apps more Mac-like by default but there are significant technical and compatibility challenges with that.
August 8th, 2007 at 6:44 pm
@Paul Stamatiou: If you’re writing a review on Fusion, you are *not* VMware’s messenger. You should research your article before writing anything. Don’t just repeat company lines. And update the article if you find there was an error in it.
August 8th, 2007 at 6:53 pm
Adrian: Agreed. I would still place a little blame on the frameworks (since with a given amount of time, a Cocoa developer will probably do more, and thus the framework choice does make a diff), and by extension Apple for not making Carbon apps more Mac-like by default, as you said. But yeah, it’s entirely in the developer’s hands to change the perception of their app.
August 8th, 2007 at 7:15 pm
> Actually, I think he compares Cocoa to Qt, which is used by
> Parallels, not Carbon. And Qt sucks on any platform.
But of course, Parallels uses Qt in a way that makes the app virtually indistinguishable from a Cocoa app.
And by the way, the reason Safari is so fast is KHTML/WebKit, which has nothing to do with Cocoa.
August 8th, 2007 at 7:49 pm
It seems to me a theory vs practice. Theoretically, the non-Cocoa app could be just as “good”. But in practice, the vendors who really, really care about the Mac LAF tend to be using Cocoa. ( And bad programmers converting a bad app to Cocoa will not cause any miracles. ) So being Cocoa does not intrinsically make an ap better – but that’s the way to bet.
August 8th, 2007 at 7:59 pm
Some errors from Simone:
“There are *so* many things that are dead giveaways for Cocoa apps, for the vast majority of the time. Standardized customizable toolbars”
Certainly common in Cocoa apps, but these are available to carbon apps.
“the dirty dot in the close button”
No. Carbon apps do this too (it’s an extension of the greyed proxy icon in the title bar – originally a Mac OS 8 feature)
“the application shipping as a package rather than an app that has a data folder outside of it”
No, packaging is no indication of framework: Pretty much all Carbon apps are Mach-O/bundles these days. The converse applies: if it’s CFM then yes, it is Carbon, not Cocoa
“the availability of services, standard spell-checking with red underlines, command-dragging to select discontiguous text in a text area, option-dragging to select a square of text in a text area, etc., etc., etc.”
These are mostly true. OTOH, at least Carbon apps know how to properly handle dragging the window proxy icon. Cocoa apps totally screw that up.
August 8th, 2007 at 8:13 pm
I’d think that in the early days of OS X that sentiment was true, but now it’s as much down to the developer rather than the API as to whether their app is slow or fast. Anyone can write crap code and a framework doesn’t prevent you writing crap code. The only thing you can say as a fact about Cocoa over Carbon is that it’s faster to developer an application with Cocoa, though faster to develop does not mean faster to execute
August 8th, 2007 at 8:47 pm
I’m an end user who knows basically squat about programming, but I can almost always tell when an application was written in cocoa or carbon. It’s a look and feel thing. Carbon apps usually feel half-assed and look strange. The only app that has ever fooled me in this regard is Intaglio, which I assumed to be cocoa, but apparently is really carbon. Intaglio proves that carbon apps can be as nice as cocoa apps, but in my experience Intaglio is that rare exception.
August 8th, 2007 at 8:59 pm
Of course it’s nonsense, in the sense that the same is (in general terms) *possible* using Carbon, and someone sufficiently brilliant and dedicated could produce an app of “Cocoa quality” using Carbon.
The thing is, nobody has three years to dedicate to doing something that pointless, when they could do it in six months in Cocoa.
There is a reason the industry heads for higher-level languages with more powerful APIs… and in any real-world situation, Cocoa apps *are* better, faster, and more Mac-like than Carbon apps. Debunking the myth on theoretical terms does nobody any good. If you have concrete examples of fantastic Carbon apps, by all means hold them up, but it doesn’t change the general truth of the statement.
August 8th, 2007 at 9:55 pm
I’m not a developer and have rudimentary understanding of programming. However, I definitely am more knowledgeable than most end-users, not exactly a point-and-clicker.
I don’t know if this is a difference between Cocoa and Carbon, but I’m guessing it is: one of the programs (an XML parser) I use and love is Carbon-based. It cannot interact with long file names as a result. This is serious problem as it prevents interoperability with other programs. I imagine long filename handling is built-in to Cocoa and can be added on to Carbon.
So, presuming this to be true (otherwise this example falls apart) this is one of many benefits that programmers can provide their end users by porting their code to Cocoa.
I don’t disagree many developers give their users Cocoa pills to pop. But I do disagree with the reactionary position that there is little to no benefit of porting Carbon apps to Cocoa, a position implied by Adrian’s incisive but stubborn arguments.
As an end-user, I prefer Cocoa apps. If my preference is the result of superstition, so be it. But arguing that end-users beliefs are misguided is not going to change anything. Port your app to Cocoa and be done with it already.
Johnnie Wilcox
aka mistersquid
August 8th, 2007 at 10:17 pm
Let’s revisit the argument when the Mac OS X landscape is filled with 64-bit cocoa applications post 10.5 and decide which is a better framework.
August 8th, 2007 at 10:32 pm
I am sure this myth comes from ex NeXT, and ex Linux developer who hated the fact that Apple has put Carbon layer and the fact even develops it further on Leopard. What they want is a FreeBSD/NeXT hybrid having nothing to do with Mac at all. E.g., some 100.000+ licensed user graphic application will “die” because its being coded for 12+ years and it has carbon bindings. They will be happy about it but not the graphics artist/DTP pro working at their daily newspaper. :) As result, OS X will be “true new NeXT” with pure Unix and they will be happy with their elite system.
Of course, OS X never being successful and Apple possibly canceling further OS X development and focus on Windows/iPod are just minor side effects (!) of such purist attitude. They will be happily using a 0.001% market share “pure” elite OS, who gives a heck?
I experimented with the open source, true *nix packages. I have a bad habit of watching compile process for years. Guess one of the first things autoconfigure checks before compiling any serious application/suite? It says “checking for Carbon.” Could these people who claim to be very advanced, elite developers explain why? So lets say, we renamed carbon.h to carbon.broken at header files, will those true open source packages compile?
There is nothing wrong with pure Cocoa or pure Carbon apps; a true professional developer uses whatever fit his/her needs. Of course, if you suggest Apple should not bother with Carbon and everything must be pure Cocoa/Objective C, as a very stupid end user, I suggest you take a look at Versiontracker top ten apps and ask those developers of those apps if they don’t know how to code in true (!) OS X Cocoa. They could have good answers and may teach you some professionalism such as “don’t fix if it isn’t broken.”
If one application hit one million downloads years ago and you _know_ it is in use even at NASA, every newspaper you can imagine, every Fortune 500 company, the developer is credible. Not some random people who learned a bit Objective C and trained only to code Cocoa.
I want to hear a true successful, professionals developers take on “why everything should be pure cocoa,” not some random people commenting.
August 8th, 2007 at 10:40 pm
“Qt” sucks on any platform.
Is that the same Qt which made KDE, Skype, Google Earth,Opera and some not that popular but hugely credible applications possible? Or the Qt 4 which will bring a natively working (yes! without X11/Cygwin) KDE 4 and entire suite of apps to OS X and Windows users?
That was what I mean by the difference between professional developers and some people never coded any successful application.
August 8th, 2007 at 11:14 pm
Thanks for posting this. There’s too much Carbon hate going around. If the average Cocoa developer knew how much of Cocoa was built on top of Carbon it would probably blow their minds.
August 8th, 2007 at 11:27 pm
@mistersquid : The file name limitation is a result of the developer using older APIs, not strictly from using Carbon. While similiar code in Cocoa wouldn’t hit that constraint, there’s nothing stopping the developer from fixing it in Carbon. If you look at Microsoft Office for Mac v. X vs. 2004, you’ll see that the file name length limitation went away but they didn’t switch from Carbon to Cocoa in order to do so. Unaddressed shortcomings are just lazy programmers, not frameworks.
August 8th, 2007 at 11:46 pm
@Ilgaz, Skype is the only one of those apps whose user interface isn’t completely miserable on OS X. Not coincidentally, Skype used Cocoa for the OS X version of their app, and gets all the Mac-like goodies that go along with that for free. Cross-platform toolkits like Qt will feel weird in OS X almost by definition — there are probably *some* apps that blend in relatively well, but the majority are going to feel as bizarre and clunky as Google Earth.
August 9th, 2007 at 12:00 am
Professional developer here. Mr. Sutton has it right. Cocoa makes developers more productive. It isn’t a silver bullet, but it is a boon. It has no bearing on whether or not VMWare sucks. It just (theoretically) means VMWare’s developers had to work a bit less hard on the user interface. It should not be a marketing bullet point.
August 9th, 2007 at 12:05 am
I’ve been a Mac developer since OS 6 and Ligthspeed Pascal, I needed 3 copies of Inside Mac Vol 1, and had as much invested in Carbon as anyone else. And my advice to you is SWITCH!
Yes the learning curve is high, yes you’ll throw away lots of little utilities you’ve grown to like, still, switch!
Its so much better here, once you get the cocoa philosophy its such an easy way to develop, and learning the clases isn’t as hard as learning PowerPlant (or Think Class Library) because the of the strict naming and coding conventions, you can usually guess correctly about an api call.
Cocoa Apps load faster because they are smaller, they are smaller because they link directly with the classes in the System, a carbon app has to carry all that code around with them.
While technically the runtime linking does slow down Cocoa apps, it is highly optimized, amazingly so, its also usually cached already. So running a cocoa app means most of your app was loaded before it was clicked on.
Not to mention the fact that Apple is moving Cocoa forward quickly while Carbon will always be left behind. Just switch developers, you’ll be very glad you did. Its great fun to be this productive with so little code, so little time spent on filling in ridiculous structures or poking through documentation for obscure parameters or error messages.
August 9th, 2007 at 12:24 am
If you have four kids, driving a minivan may be the right choice. Reasonable people will understand why you drive a minivan. Your friends will still invite you over for barbecues. It’s just not a barbecue without you, after all. Nobody really thinks much of your minivan parked in the driveway, surrounded by the German sport sedans your still-single friends all drive… At least until you have a few beers, and you start explaining how, “with the V6 and 16-inch wheels, that van drives like a Maserati.”
“Sure it does, Bob,” your friends say. Whatever you need to tell yourself.
August 9th, 2007 at 12:34 am
Adrian already said it …
“If anything, Cocoa is built on Carbon, though that’s only for certain aspects.”
… and that’s a point well worth making, IMHO: There is no such thing as a pure Cocoa application. Think about NSMenu, for instance — Cocoa menus have been based on Carbon menus for years. Does anybody even remember NSMenuView? Besides, there are still things you just can’t do in Cocoa.
The notion that Cocoa is more native than carbon, however, might at least partially be caused by what Apple themselves say about Core Foundation:
“Core Foundation is a library with a set of programming interfaces conceptually derived from the Foundation framework of the Cocoa object layer but implemented in the C language.”
I guess it’s a draw. And I’m thinking that both Cocoa and Carbon are here to stay, which is a good thing, because they work together in the most beautiful way. Just don’t trust anyone who says his application is great because it’s “pure Cocoa” — that’s either an intentional lie or a sign that the person you’re talking to doesn’t know too much about these things.
August 9th, 2007 at 12:44 am
This is the grossest oversimplification and concoction of half truths I have ever read on the subject. The interspersed comments by the original author of the article only make it worse and demean him further in onlookers’ eyes. And this article wouldn’t get any attention at all if not for the evil Sauron eye of DF who just can’t let the pathetic issue go. Mostly because his friends at BB still have not, after ten whole years, got on the wagon and learned the technology that’s supposed to be used with this operating system. And here comes Leopard, you losers. Two more months and you’re a bitter memory.
August 9th, 2007 at 1:45 am
You had me until I noticed your association with Ephox. Sorry, but the Ephox Editor on Mac is just horrible. It’s not Mac-like in any way, so now I’m supposed to find you a credible expert on how to provide a good Mac experience? I know this sound harsh, but honestly, actions speak louder than words.
August 9th, 2007 at 2:04 am
@Roland:
Skype still uses Qt. It also links against Cocoa. And Carbon.
I think the reason many Qt apps don’t look good on OS X is either lack of care for that platform or lack of resources to target multiple platforms effectively.
A Qt app that only targeted OS X could easily look and feel like a Cocoa or Carbon app.
That said, for people looking for one toolset to target multiple platforms, Qt is superb.
August 9th, 2007 at 3:18 am
One difference between Cocoa and Carbon apps which, while not relevant for the majority of Mac users, is a royal pain for few thousands of us, is that edit controls in Carbon applications don’t support right-to-left languages (Hebrew and Arabic) properly, while Cocoa applications get that for free. I can immediately point out Carbon applications for the lack of that feature.
For those of us who occasionally need to enter information this can be the deciding point when choosing between two similar applications.
August 9th, 2007 at 5:01 am
“an end user of the application simply won’t be able to tell the difference if you write the application properly.”
The key is, “properly”. The use of the Cocoa API’s gives you so much “for free” that you just don’t have to think about. The Services menu? Handled. Document icon handle in the title bar? It’s there. Right-to-left text support? Already thought of. Apple introduces a nice universal dictionary shortcut? It’s already supported in your text panes if you’re using Cocoa.
If you have the mythical infinite army of monkeys working in your design spec department, and equally magnificent hoards in your development and QA departments, yes, you can make a Carbon app look just like a Cocoa app with all the niceties of a Cocoa app.
In my experience, though, it just doesn’t happen. Microsoft’s MacBU has quite a collection of designers and developers, yet their Office 2004 apps still behave in many ways like OS 9 apps instead of good OS X citizens.
For me, “Cocoa” is a feature which should be advertised.
That having been said, I don’t see how it specifically increases speed and reduces memory footprint in Fusion, so in that case at least the point does stand …
August 9th, 2007 at 5:28 am
Adrian, in response to you comment 13.
I was the first UI developer to start working on what became Fusion along with a few senior devs hacking away on porting the virtualization platform and more devs joining us later in the effort to bring this product to market.
I’m sorry if the use of Cocoa came off the wrong way. We wanted to emphasize was that Fusion is not just a straight Workstation port. We re-designed (rather than re-wrote) from the ground up to meet the needs of Mac consumers. There was a lot that was written in a cross platform way that we were able to leverage. We could have even taken large parts of the GTK UI from Workstation on Linux and run that under X11 on OS X. We don’t think that would have been the optimal solution for our customers – we strongly believe that this is a different market segment. This was also a great opportunity to take a great product like Workstation and learn from the evolution it’s undergone over the years and start fresh; cut off some of the cruft, simplify and refine the user experience.
Why the choice of Cocoa then?
Lots of reasons none of which are because it’s less resource intensive than Carbon (though it is less resource intensive than options like QT).
- Cocoa allows you to prototype rapidly – ironically we don’t make use of some of the really rapid prototyping features like CoreData but rely on in house cross-platform libraries.
- Though the documentation isn’t perfect, Cocoa is less opaque than Carbon. Carbon will often make strange assumptions about your application running on a CFRunLoop and other odd obscure things.
- Carbon, though it was heavily cleaned up in the OS 9 to OS X transition, still has a lot of legacy stuff lying around.
- It is also very procedural in nature and we already had a C++ object oriented data model that we wanted to interface with.
- We use lib SigC heavily and that maps rather well onto Cocoa-isms. sigc::slot (a functor) can be translated into NSInvacation instances or more simply (delegate, selector) tuples. sigc::signal maps almost perfectly to Key-Value observing.
- Apple has also made it increasingly clear (at this year’s WWDC) that Carbon won’t be moving to 64-bit and that certain new features will be Cocoa only.
- Even when doing proper UI design it’s just easier to get a consistent OS X feel when using Cocoa for a lot of things – and yes that is because many people have come to associate Cocoa’s behaviour to that of Aqua; toolbars, window closing behaviour, app activation and deactivation, mapping of document types with the system, integration with the Dock are a few that come to mind.
That’s not to say that we don’t use Carbon at all. Certain API calls only exist in what is best described as Carbon (the boundaries are sort of fuzzy in some cases). But since Objective-C is a superset of C making C function calls is trivial.
I hope this helps clarify our position.
shawn
August 9th, 2007 at 7:47 am
Wow, lots of comments with a lot of good points – I can’t respond to them all. There certainly are multiple issues overlapping here with Cocoa vs Carbon and VMWare vs Parallels. It’s particularly good to see so many VMWare people turning up to defend and explain their comments.
I do want to respond to comment 37 – Donald, Ephox creates a cross platform Java-based HTML editor that primarily runs in web browsers. It’s nearly impossible to make an applet Mac-like, particularly given some annoying bugs in Safari (most notably it intercepts keyboard shortcuts which is why we’re unable to use the command key instead of control – drives me nuts). Additionally, we mostly sell to large corporate customers who are rolling out to thousands of Windows PCs and one or two Macs. As much as it annoys me (and the other people at Ephox who use Macs full time) it’s not a good investment to tune our app to be Mac-like. To work well and let people get their job done on Mac, absolutely and I don’t think you’ll find a better in browser WYSIWYG editor for Mac, but it’s not a Mac-like experience and while I wish we could change that there are technical and business considerations that make it impossible.
August 9th, 2007 at 8:16 am
“Though the documentation isn’t perfect, Cocoa is less opaque than Carbon. Carbon will often make strange assumptions about your application running on a CFRunLoop and other odd obscure things.”
This comment doesn’t make sense. How does Carbon make assumptions about CFRunLoops? Cocoa runs on CFRunLoops as well….
“Carbon, though it was heavily cleaned up in the OS 9 to OS X transition, still has a lot of legacy stuff lying around.”
Technically, Cocoa has much more legacy than Carbon does. If you have the source code for a pre-Mac OS X Toolbox application, there is no chance whatsoever it’ll compile and run in 10.5 64-bit. Hell, there’s little chance it’ll even compile on 10.4. Whereas if you have a Pre-Mac OS X Cocoa app, you’ll have to make little to no changes to the source code to get it compiling and working on 64-bit 10.5.
Hell, Mac OS X even has dummy cocoa classes (NSMenuView) and methods (NSFontManager’s fontManager:willIncludeFont:) solely for backwards code compatibility that have never, ever been implemented on any version of Mac OS X.
“Apple has also made it increasingly clear (at this year’s WWDC) that Carbon won’t be moving to 64-bit and that certain new features will be Cocoa only.”
Carbon exists in 64-bit 10.5, take a gander at http://developer.apple.com/leopard/overview/apptech.html
“Leopard brings complete 64-bit support to all of the Mac OS X frameworks, allowing you to create Carbon and Cocoa applications that can take full advantage of the latest hardware now and well into the future.”
“window closing behaviour, app activation and deactivation, mapping of document types with the system, integration with the Dock are a few that come to mind.”
This comment isn’t making sense. mapping of document types is done by LaunchServices, a C API. It has nothing to do with Cocoa. Also, no idea what you mean by “integration with the dock”, especially since the Dock is not cocoa.
Of course, it doesn’t help hat when a lot of people think “carbon” they think of horribly old applications with a lot of legacy like Microsoft Office. Applications like these don’t even use the Carbon APIs, instead they roll their own re-implementation of a lot of stuff or they use event models that are completely at odds with the way Mac OS X works (like using WaitNextEvent instead of carbon events and RAEL).
FWIW, DVD Player is a Carbon application.
August 9th, 2007 at 12:20 pm
@Oren: Carbon doesn’t get right-to-left support automatically, perhaps, but TextWrangler is Carbon, and I have no problem mixing Hebrew and English in alternating lines. The Hebrew lines go right-to-left and the English left-to-right. It does get a bit confusing when I mix them on the same line, but I suppose one would expect that. My point is that Carbon apps *can* implement this.
August 9th, 2007 at 1:31 pm
Carbon text fields like MLTE and the HIView stuff does get rtf automatically. Just so many apps people consider “Carbon” (like Office, IE, and whatnot) either roll their own or use WASTE.
And then if you do want to do the text drawing yourself (maybe you’re a DTP app or something that needs to be psycho and you happen to enjoy pain) there’s rules on doing RTL (which is mostly done automatically) if you want to tweak it at a lower level. See http://developer.apple.com/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui_chap2/chapter_2_section_9.html
Also, CoreText, CoreText, CoreText!
August 9th, 2007 at 2:01 pm
@Rosyna:
“Carbon exists in 64-bit 10.5, take a gander at http://developer.apple.com/leopard/overview/apptech.html”
Didn’t they announca at WWDC 07 that Carbon wouldn’t be 64bit? I know some developers who are very unhappy about this. It’s not a tech issue, it’s a marketing one. Even Apple appear to want to discourage Carbon dev going forward.
August 9th, 2007 at 2:07 pm
@TFA:
“Objective-C which is a much higher level language than pure C”
I’m not sure that “much higher level” is accurate. In fact Obj-C adds very little to the C language, and only a small runtime. It’s also a strict superset of C unlike C++ so you can write pure C code in Obj-C, warts n’ all. The original implementation of Obj-C didn’t even use a special compiler, just a preprocessor to turn it into “real” C, then compiled as C. The fact that you can do so much more with Obj-C than C is something of an illusion (a good one, it must be said!) and does not imply that Obj-C adds a big inefficient layer on top of C.
August 9th, 2007 at 2:39 pm
I started Mac development in 1996, so I too have been around the block a few times. First off, Carbon is going to take the Dirt Nap any month after Leopard has rolled out. Anyone who claims that there are no advantages of Cocoa in performance may be right…until you you try to do some of the new Cocoa-only annimation or 64-bit work. Carbon is being depricated piece by piece. And the other old Mac developer is right–it’s time to move with the future. The author is too young to be a credible traditionalist. No, it’s time to give up the descendant of the old Mac ToolKit and move with the flow of progress, i.e. Cocoa.
August 9th, 2007 at 2:39 pm
Objective-C has come a long, long way from when it was just a set of preprocessor macros. The message passing rules and OOP it adds are enough to reasonably call it much higher level than C. The addition of garbage collection makes it even more high level. It’s also not about how many keywords are added, it’s about what that lets you do and OOP in Objective-C makes a massive difference to developers.
Objective-C is very efficient (the caching that is done for message passing is extremely effective) but it does add overhead. Should programmers care? Not with the speed of processors these days, developer productivity is far more important than the very small amount of overhead that Objective-C adds. As I said earlier, if you’re starting a new Mac OS X application from scratch you should almost certainly use Cocoa and Objective-C, it’s just a fantastic set of libraries to develop with.
August 9th, 2007 at 2:48 pm
Ah Jim,
I was developing for Mac in 1994 – who are you calling too young? Now I’ll freely admit to not being an expert back then, but I have plenty of knowledge about the history of Mac and of development. I agree that Cocoa is a much better way to develop than Carbon – it makes developers tremendously more productive, but rewriting an app is rarely a good idea and most applications have no reason to move to 64 bit – plus it’s quite possible to do animation in Carbon, just not as simple as with the new Cocoa APIs.
Again, rewriting your app from scratch just so you can say you’re Cocoa is probably a really bad idea – it will just introduce regressions and waste a lot of your time in the process. Better to spend that time adding the extra polish that Carbon apps need to make services and the other OS X goodies work.
August 9th, 2007 at 7:59 pm
Where are people getting the crazy idea carbon is going anywhere? The File Manager, the Alias Manager, and other Carbon APIs are still the only *proper* and *correct* way to do a lot of things. This isn’t going to change. Paths are still even and should never be used. And you can’t not use paths unless you use Carbon. Do you think Apple is magically going to remove the Ink framework or Speech Recognition (both Carbon APIs)?
August 10th, 2007 at 12:50 am
Adrian,
i think your comment 49 sums it all up. These days developer efficiency is more important than application efficiency (within reason of course). if people are really worried about speed, assembly is your best option. Anything above the processor instructions is adding overhead.
kelly
August 10th, 2007 at 1:40 am
If people in the industry have learned anything, it’s be careful, very careful, when crossing the river (Rubicon?) of whether to rewrite or not. Novell, Corel, and Lotus are good examples of that. But, the thing was, when these apps were re-written, the paradigm they were shifted to was not one that offered increasing efficiency during the development process that Cocoa, Obj-C 2.0 and the new Interface Builder are adding compared to Carbon. Worse, the rewrites were all very badly managed in that the development of the traditional apps was frozen–no more updates or maintenance releases–opening the door to MicroSquish to use FUD and Vaporware to sway customers away from these companies and over to MS.
But not rewriting to take advantage of new technologies, new animation, new graphics, and 64-bit here, among others, is not a solution either. The tug-of-war between BBEdit and TextMate is a classic example of what we are talking about here. In the case of BBEdit, my (still) text editor of choice, it is adhering to allot of its Carbon code while TextMate, which is Cocoa only, is eating its lunch and dancing circles around it. Better would be for BareBones to have a Tiger team (an aerospace term, not the OS) start a full-up Cocoa version of BBEdit while the company continues to release updates to BBEdit 8. When the Cocoa version of BBEdit is close to some development tipping point, BareBones would concentrate development resources on getting it over the finish line.
The moral of the story, you can’t stay with Carbon and expect to compete with Cocoa competitors, especially after Leopard. There is allot of Carbon that is being deprecated in October while Cocoa-only capabilities abound. More will follow with the next OS release in a couple of years. Customers want the latest and greatest capabilities that Cocoa allows for free but for which has to be built in by the developer in Carbon, meaning that all things being equal, hour-for-hour, effort-for-effort, a Cocoa-only developer is going to be more efficient–TextMate’s team has shown that. So the move to Cocoa must begin at some time. But while you’re migrating over to Cocoa from Carbon, you can’t neglect your current customers and their needs for maintenance and incremental updates while you go off and recreate your great app. And this debate can go on for awhile. But for those like BareBone, if it is wrong in not breaking with Carbon, at the end of the debate are layed-off programmers and other workers and a once great product that is relegated to the ash-heap of history. Hey, nobody said this was without risk.
August 10th, 2007 at 4:42 am
Having done Cocoa, Carbon, PowerPlant, MacApp (Pascal and C++) and roll-your-own C applications for Mac OS 9/X over the years, I have to say that Jim Hillhouse gets it exactly right.
Nothing works better than the combination of Cocoa, Xcode and IB. Prototypes of small applications can become high-quality shippable apps because of Cocoa’s ability to do most everything on the UI side “quick-and-clean”.
I’d add something to what Jim says, however: rewrites do not have to be an all-or-nothing proposition. The parts of a legacy or other-platform app that you don’t want to rewrite because a) they already do what they’re supposed to do and do it well and have enduring much field testing already and/or b) they’re too crufty or complex to viably rewrite tend to live in separate libraries, or can be factored out quite easily (e.g., the purely computational part of a Mandelbrot explorer app).
There’s almost never a need to abandon those when you switch to Cocoa.
The great thing about talking about Cocoa is that you don’t have to. That’s a hallmark of much of Cocoa development itself.
Anyone with even modest programming skill or the barest of experience in software development can go through a tutorial or three and get a pretty good idea of the power of IB and the breadth and depth of Foundation and other Cocoa kits. Just go try it!
A slogan of Cocoa (nee NEXTSTEP) developers has been: “it makes simple things simple and difficult things possible.”
I’ve never been able to say that about any other Mac application framework+toolset.
August 10th, 2007 at 10:02 pm
If those developers enlighten me a bit? I am using 64bit CPU since 2003 starting with G5 1600 and now I am on Quad G5, if something magic happened and all applications actually use 64bit accessible memory for their needs and Carbon will be seriously effected because it won’t be 64bit (??), let me order 16*1 gig modules for my Quad.
All I see is horribly written apps in both carbon or cocoa which doesn’t even use 4 processors and it includes Apple’s own Quicktime while encoding too. A freeware dubbed “amateur” uses 4 CPUs while exporting H264 and Apple QT Pro uses 2. I don’t see anything figuring that I got 3 GB of Free RAM and use it to buffer their data. I am speaking about multi threading and cache, not getting into stuff using 64bit addressing needs. Does it have anything to do with Carbon or Cocoa? Not of course..
Cocoa is good for something: It effectively shows horribly written code pretty and professional. That is my opinion as a video editor of course. Some of the tools which some developers hoped they will die (yes, weird developer scene) after Mactel transtition have moved to Cocoa and we didn’t see they get magical speed boost or anything at all. They also ship CFM alternative and as a Quad G5 owner, I use the Carbon one since it is much more compatible with current plugins etc. Both have similar speed, same UI issues. What happened to Cocoa magic?
August 11th, 2007 at 6:25 am
[...] Symphonious » The Myth Of Cocoa Apps Yes, it’s true. No matter how nice the framework, you can’t save people from writing total crap. It might just look better by default though. (tags: programming cocoa osx) Share This [...]
August 11th, 2007 at 7:31 am
Any decent programmer would write in assembler and not need any frameworks.
August 11th, 2007 at 9:59 pm
Hi Adrian,
What about RealBASIC — just as good as Cocoa/Carbon?
August 12th, 2007 at 9:11 am
Odysseus,
The end user should not care which framework an application uses – it’s a technical detail. So yes, RealBASIC is likely to be just as good as Cocoa or Carbon if the developer puts enough effort into the application. It may take an unreasonably large amount of effort to do though.
August 29th, 2007 at 9:46 am
[...] while back I took Paul Stamatiou (and by proxy, VMWare) to task about their claim that Cocoa makes them so much more efficient. My take was that it was a Cocoa vs [...]
November 25th, 2007 at 6:25 pm
There is one small detail that I havn’t seen mentioned here:
Cocoa applications tend to be horribly buggy! To cite Steve Jobs: “I don’t mean in a small way, I mean in a big way”. Apple’s own Cocoa apps have a very bad track record of really, really ugly bugs, destroying user data. Two examples:
- Garageband can/could delete your recorded tracks when you hit “save”. This happens often, and for absolutely no apparent reason.
- iPhoto can/could delete pictures from your camera after failing to download them.
That’s the worst two, but they are really big. That kind of bugs should not exist in an app that is above 1.0. It is all too obvious that Apple’s own Cocoa developers are unable to debug their own applications. Could this be something that happens due to the different workflow?
How about lockup-prone apps like Disk Utility and DVD Player? They are the only Mac applications I know that are misbehaving so bad that they cause restarts. Are they Cocoa based? And could it be Cocoa’s fault that they are unreliable?
Third-party Cocoa apps also tend to be more buggy than Carbon apps, they often crash for no apparent reasons, but I havn’t seen quite the same level of bad engineering that Apple have shown themselves.
So either Cocoa is a bad solution or Apple need to straighten up their quality control for Cocoa apps. Or both.
November 27th, 2007 at 4:48 am
Those kinds of bugs have nothing to do with Cocoa. Bugs are inherent in the *current* way we develop software.
Having developed both client and web software on a variety of platforms I’d like to venture that there are a class of bugs that are possibly Cocoa only but they have to do with scaling rather than destructiveness. Since Cocoa isn’t as wide-spread as platforms like Java and .Net it’s harder to figure out what patterns to use when. This is made worse by the fact that Cocoa has certain concepts (like nibs) that aren’t used very much elsewhere. The question of how do I architect a large-scale Cocoa app is one I’ve asked myself several times as I’ve written larger and larger ones. There just aren’t that many examples to learn from out there.