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.

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.

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

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?

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.

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.