Symphonious

Living in a state of accord.

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

Category: Apple
  • Rosyna says:

    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 9, 2007 at 7:59 pm
  • kellyp says:

    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 10, 2007 at 12:50 am
  • Jim Hillhouse says:

    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 10, 2007 at 1:40 am
  • God of Biscuits says:

    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 10, 2007 at 4:42 am
  • Ilgaz says:

    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 10, 2007 at 10:02 pm
  • Gaz Hay says:

    Any decent programmer would write in assembler and not need any frameworks.

    August 11, 2007 at 7:31 am
  • odysseus says:

    Hi Adrian,

    What about RealBASIC — just as good as Cocoa/Carbon?

    August 11, 2007 at 9:59 pm
  • Adrian Sutton says:

    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 12, 2007 at 9:11 am
  • Ingemar says:

    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 25, 2007 at 6:25 pm
  • Shawn Morel says:

    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.

    November 27, 2007 at 4:48 am

Your email address will not be published. Required fields are marked *

*