Recently there’s been a reasonable amount of ruckus about the lack of 64-bit Carbon. It’s going to be possible to compile your Cocoa app as a 64-bit application - and no, this wasn’t possible before; the UNIX layer frameworks and libraries were available in 64-bit versions, so you could do stuff like spawn worker processes, but everything above was still strictly 32-bit only. It’s going to be possible to compile X11 and Java apps, but it’s not going to be possible to compile Carbon apps for 64-bit. This is especially remarkable since X11 and Java are both supplemental APIs - Java doing what Java does best (on Mac OS X even using Aqua chrome for Swing apps) and X11 to accomodate Linux, BSD and UNIX users and their existing apps.
Those who know are presumably under NDAs, but we can still guess. There are three major possible outcomes here:
- Carbon is going to get canned shortly.
- Carbon is going to live on but without 64-bit support.
- Carbon 64-bit support was cut for the beta “preview” build given out, but is slated to make an appearance shortly.
My money is on 2. with 1. on the distant horizon (within 15 years, but not in the nearest five years).
Contrary to conventional wisdom, Carbon apps are not automatically old or uncapable or fast and Cocoa apps are not automatically really fast or really slow or capable. In fact, the only real difference is that good software developers make good apps no matter what the technical prerequisites. This is not a new revelation; people like John Gruber and Rich Seigel have been saying it for years. iTunes and the Finder are Carbon-based and manage perfectly well to between them pretty much define the Mac OS X user experience, and Parallels Desktop, one of the best “Mac-like” newcomers I’ve seen, is even put together using the Qt cross-platform user interface toolkits. (Cross-platform! Mac-like! In the same sentence! Wonders have not ceased.)
The problem with Carbon is twofold. It’s not a secret that Apple management are falling over themselves to prefer Cocoa over Carbon. It’s also not a secret that, say, Adobe and Microsoft have hitherto refused steadfastly to adopt Cocoa in existing applications.
Right now, today, in Mac OS X 10.4 (or, if you will, Tiger), Carbon is as much a ‘legacy’ framework as is Cocoa. Both have their roots in 80’s technology, and both are continuously being refreshed. Apple’s actual route, as opposed to the route Steve Jobs and Avie Tevanian (back when he was still with the company) would have liked to take, has been to invent common ground and use the right tool for the right job. Core Foundation and its toll-free bridging, wherein you can cast a Core Foundation C “object” directly to the corresponding Cocoa Objective-C object in what amounts to drastic voodoo, is a testament to this.
The problem going forward is that preparing for the future is hard.
QuickTime, for example, is armed with one of the most vicious C API ever made by man, and five years ago its internal architecture was not quite optimized for Mac OS X. If you take QuickTime as of 2002 and imagine a QuickTime as of 2012, QuickTime is going to have to be updated for 64-bit, resolution independence, codec parallelization, random access codecs and more and more integration with the hardware abstraction in Mac OS X. Most of this has already been done, but Apple has announced that starting in 10.5 - Leopard - the new development in QuickTime API will happen in Objective-C layers, like the new QTKit.
It is a monumental task to complete a 64-bit transition of any scale and keep header file backwards compatibility (wherein if you compile the new, enlightened code for 32-bit again, a binary with identical function definitions is produced). The QuickTime API was certainly old and crusty, and Carbon is in better shape than that. But will it stand the test of time in the next few years? And, more importantly, since Carbon mostly underlies the whole Mac OS X UI (menus and some UI components are fundamentally handled by Carbon on which Cocoa builds) and many core technologies like Apple Events, what happens if it doesn’t? What about Microsoft’s and Adobe’s product catalogs, and in fact most of the cross-platform software? Mix this with Apple’s tendency to prefer Cocoa for new development - can anyone even remember the last new Carbon app from Apple? - and you have a very tricky equation.
The future is uncertain, at least for those of us without NDAs. My ultimate guess is that Carbon is not going to go away in a drag-out-of-the-Dock-like puff of smoke, and neither is Cocoa. Interoperability is going to be the guiding word going forward. Safari’s WebKit engine has from its initial appearance a few years ago had a central WebView view that’s been embeddable from within Carbon HIViews, despite being predominantly a Cocoa creature. You can already mix C, C++ and Objective-C, and thanks to Objective-C++ you can mix them freely. And, what’s more, support from either side to invoke or embed parts of the other side is going to improve beyond what’s already there.
Ultimately, Cocoa and Carbon are two frameworks that offer wildly different APIs and event models - and this is what the terms Cocoa and Carbon apps come from since you can only choose one for any given app - but canny developers have been mixing them for years, cherry-picking the things they want from each. I think it is telling that one of the three only officially advertised Carbon session this year at WWDC was something called the “Carbon and Cocoa Integration Lab”. (Thanks to Scott Stevenson for pointing this out.) The other two were about HIToolbox, and the “See What’s New in HIToolbox” session’s description noted content about “embedding Cocoa views in Carbon windows [and] extending your Navigation Services dialogs with Cocoa”.
Carbon developers. Cocoa developers. Put down your guns. Give peace a chance.
