Myths of Snow Leopard 5: No Carbon!
June 24th, 2008
Daniel Eran Dilger
Apple’s limited comments on Snow Leopard, the next version of Mac OS X due in about a year, have opened the playing field for rampant speculation. Here’s a look at a series of myths that have developed around the upcoming release. The fifth myth of Snow Leopard:
Apple is killing Carbon so all apps will be Cocoa only.
Pop quiz: which of the following are true:
- There’s not room for both Carbon and Cocoa in Mac OS X.
- Carbon and Cocoa don’t compete, they complement each other.
- The best way to drop legacy is to rip it out.
- Good apps are Cocoa, bad apps are Carbon.
Congratulations, you’re right on every one. But no matter how you answered each, you’re also wrong on every one. Depending on how you look at things, all of those ideas could be both true and false. Is there room in Mac OS X for both Carbon and Cocoa? Certainly, but at the same time, supporting both in parallel into the future would result in major tradeoffs, particularly in terms of opportunity costs. By freezing Carbon and taking it out of the picture, Apple could deliver more a cohesive, consistent, and potentially more stable user experience while focusing its development efforts around a single strategy.
Do Carbon and Cocoa compete or complement? If you’re a procedural classic Mac OS developer, you will insist they complement each other, as Carbon is not only more familiar, but also more complete and allows you to do things that can’t be done in Cocoa. If you’re a Cocoa developer, Carbon competes for your attention and could best be removed from view so that Apple can focus its efforts in polishing its objective oriented frameworks.
Is the best way to remove legacy to rip it out? That worked pretty well on the 1998 iMac to decisively push USB and kill the floppy. However, Apple has also benefitted greatly from extending backwards support for legacy technologies, from the 68k emulation that helped to sell the first PowerPC Macs in 1994 to the Rosetta translate technology that helped users to migrate to Intel in 2006. Even Boot Camp, Parallels, and Fusion demonstrate how valuable the safety blanket of old legacy support can be.
And finally, are all the good apps developed in Cocoa? That would exclude iTunes, Final Cut Pro, Photoshop, and huge assortment of other important apps (I won’t mention the Carbon Finder). Many apps are not really Carbon or Cocoa but rather a mix of both. And yet at the same time, Cocoa apps can offer a more consistent user interface using less code, and benefit from other features that make it hard not to argue that pure, modern Cocoa apps simply represent better technology.
Beyond the Philosophy.
Cocoa, of course, is the modern incarnation of the object-oriented NeXTSTEP Objective-C frameworks. Carbon is the extension of the classic Mac OS Toolbox; it was developed by Apple in order to pacify the complaints of existing Mac OS software authors during the development of Mac OS X after they rejected the move to Rhapsody, which would have essentially shifted Mac development to Cocoa in one great leap forward.
However, given Apple’s shaky outlook back in 1997, it was impossible to convince existing developers to write all their software over largely from scratch using a new approach and tools that demanded a significant investment in mastering new concepts. On top of that, NeXTSTEP’s desktop development tools and frameworks had been sitting in cold storage from around 1994 through 1997 as NeXT worked to repurpose its core technologies into developing web server applications in WebObjects.
Apple needed to overhaul and modernize NeXT’s frameworks just as it needed to bring NEXTSTEP’s core OS foundation up to date with the latest software technology that had been delivered by the BSD development community over that period.
Existing Mac developers obligated Apple to spend much of its efforts getting Carbon up to speed first before prioritizing updates to the new Cocoa frameworks. A large amount of functional overlap between the two APIs resulted in a hybrid model where most of the shared foundational core of Mac OS X was written in Carbon-like C/C++ libraries, and exposed as modern, object-oriented APIs using a layer of Cocoa frosting.
Eyes Without A Face: the Mac OS X Software that is Neither Cocoa Nor Carbon.
In addition to software that had originated on the classic Mac OS and had been ported to native Carbon libraries, Mac OS X can also run POSIX software developed for Unix or Linux. Some of that software has an X Window System user interface (aka X11), which looks rather ugly and out of place on the Mac desktop, but can run just as it does on Linux thanks to integrated X11 support.
Unix software without any graphical user interface can be given one using Cocoa. That includes huge libraries of highly regarded code from OpenGL routines to the GNU FFmpeg media decoding libraries to BSD firewalls. When Apple developed Safari, it used an off-the-shelf, open source HTML rendering engine from KDE to produce WebKit, which it then wrapped in a Cocoa interface to deliver Safari as a Mac application. That modular design has enabled third parties to port WebKit to Windows, Linux, and even Nokia’s smartphones.
Apple has also hinted at technology that would allow developers to access Windows DLLs to rapidly port device drivers or other specialized software to the Mac with little effort. The ability to take foreign software, whether open or proprietary, for use in creating native Mac OS X apps offers a look at how Carbon apps can migrate their user interfaces to Cocoa, resulting in user interface consistency and other benefits for users while resulting in less code for developers to maintain.
64-bit Face Off: Carbon vs Cocoa.
That also makes it more clear why Apple changed its tune on providing new 64-bit interface APIs in both Carbon and Cocoa. The original story was that Apple would advance both. Last year, however, Apple announced it would not be implementing a 64-bit Carbon interface.
Developers who need a 64-bit user interface will need to use Cocoa. This line in the sand enables Apple to focus its resources on developing a single object-oriented user interface API for the 64-bit future. Developers such as Adobe and Microsoft will need to either stay in the past or move decisively into the future.
This is good for users because they won’t be guaranteed another half decade of mediocrity as Adobe and Microsoft aspire to spend their assets as frugally as they possibly can, just short of actually losing any easy sales. Instead, they’ll be induced to jump on the modern Cocoa bandwagon or leave a vacuum that will be exploited by competitors who can.
Apple’s withholding of 64-bit Carbon user interface APIs does not portend the removal of existing Carbon APIs however. The company clearly plans to support and maintain the 32-bit Carbon Human Interface Toolbox well into the future, although it will not be adding any significant new features to those APIs.
Instead of breaking existing Carbon apps, Snow Leopard will continue the existing policy of leading Carbon developers to Cocoa with carrots rather than sticks. New in Leopard, HICocoaView enables Carbon apps to add Cocoa features as an incremental step. As Carbon apps move toward 64-bit, Apple requires that they adopt a Cocoa user interface entirely. As they do, Apple also encourages developers to consider adopting the Cocoa frameworks for other parts of their apps as well.
That’s what Apple itself is doing. The Leopard Finder is largely a Carbon app, but makes use of HICocoaView to embed Cocoa NSViews, such as when displaying CoverFlow. Moving the Finder to 64-bits would apparently require building the entire user interface in Cocoa. Apple has indicated that will be happening in Snow Leopard. Therefore, the company is well aware of the effort needed to move to Cocoa.
Again, Carbon will not be removed from Snow Leopard, and such a removal wouldn’t make sense anyway. Apple is clearly pushing developers toward Cocoa, because the purpose of developing Carbon has now been accomplished. As applications move forward, they’ll need to adopt certain Cocoa conventions to stay up to date.
It’s a Cocoa World.
At the same time, the definition of Carbon is getting a bit slippery. Some elements are obvious remnants of the classic Mac OS, such as the Control Manager, Menu Manager, Window Manager, and QuickDraw. Other Carbon-like procedural C APIs have been developed specifically for Mac OS X. For these, Cocoa often serves as a higher level abstraction framework, making it easier for applications to take advantage of lower level features without extensive coding.
Apple is shifting its attention away from the core of Mac OS X, which is largely complete, and now working to make it ridiculous easy for developers to harness very specialized technologies. Frameworks such as the QTKit, PDFKit, Core Text, and Core Animation add an object-oriented layer on top of very sophisticated code so developers don’t have to invent their own wheel; they can simply use Apple’s.
Meanwhile, Apple continues to support legacy code. Office 2004 was written as a PowerPC CFM app, which requires Apple to host it on top of CFMApp, which itself runs on top of Rosetta on Intel Macs. It will continue to work as expected in Snow Leopard. Anyone who likes to say that Apple “doesn’t support legacy” hasn’t looked too hard at what Apple has done to jump through hoops so Adobe and Microsoft wouldn’t have to bring their old code into the modern world.
The next myth of Snow Leopard suggests that Apple is simply out of ideas or is otherwise just offering a “snow job” with its new “featureless” operating system. The next article will examine the Reality Distortion Field.
WWDC 2008: New in Mac OS X Snow Leopard
Myths of Snow Leopard 1: PowerPC Support — RoughlyDrafted Magazine
Myths of Snow Leopard 2: 32-bit Support
Myths of Snow Leopard 3: Mac Sidelined for iPhone
Myths of Snow Leopard 4: Exchange is the Only New Feature!
Myths of Snow Leopard 5: No Carbon!
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!