Apple announced this week that there will be no 64-bit version of Carbon in Mac OS X 10.6. This has, of course, triggered a storm of comments on the Carbon development mailing list. Lots of people are unhappy about the decision.
For the non-technical readers: Carbon is essentially the part of Mac OS X that evolved from previous versions of the Mac OS. Many people have many years of knowledge and work invested in it and don’t want it to go away. Having a 64-bit version would make it easier to write Carbon applications that need to have large amounts of data in memory, such as very large image or movie files, or scientific applications that work with large data sets.
Most software developers don’t need to write 64-bit applications, but what’s going on here is that leaving 64-bit Carbon out of Leopard sends a clear signal from Apple to developers that Carbon has no future.
This upsets people for two reasons. One, as I mentioned, they want Carbon to stay, either because of the investment they’ve put into it or because they don’t like the alternative, Cocoa. The other is that a year ago, Apple said that 64-bit Carbon would be included in Leopard. As a result, many developers spent the past year getting their apps 64-bit ready according to the guidelines Apple gave - certain old Carbon technologies were excluded from the 64-bit version, so you had to switch to their modern replacements. Now they find out the past year was a big fat waste of time.
Aside from the issue of broken promises, another commonly raised point is that Carbon is more similar to how things work on Windows, which makes it easier to write applications that run on Mac OS and Windows. Cocoa, Apple’s preferred alternative to Carbon, not only differs at the conceptual level, but it requires learning a new language - Objective-C.
Now, Cocoa and Objective-C do have their advantages; that’s why Apple is pushing them. But the mere fact that they’re so different from the world of C++ complicates the situation and the development process. That’s not an attractive feature, and many developers as a result want nothing to do with Cocoa. I’m not that extreme, but I understand their complaints.
To be honest, I personally don’t expect to be doing much Carbon development in the future. But that’s only because I’m changing jobs. My former coworkers back an Final Draft are still stuck with difficult and awkward questions of how to proceed with developing a Carbon application that needs new features on the outside while the inside struggles to keep up with the changes required by the evolution of Mac OS X (not to mention Windows).
A recent post on the Carbon development mailing list revealed that the decision to yank 64-bit Carbon was not a technical one. It’s not so much that delivering it would be too hard; they just don’t want to. The merits of this decision and the future of Carbon have been debated for years, but this year Apple introduced a new factor: a broken promise. I think that’s the main thing that bugged me enough to write an 8-paragraph blog entry.