WWDC 2008: Is Mac OS X 10.6 the Death of Carbon?
June 7th, 2008
Daniel Eran Dilger
Just as pundits have worked to incite drama about the death of PowerPC, Apple’s two key development APIs in Mac OS X, Carbon and Cocoa, have been frequently personified as rivals dueling to the death. Will OS X 10.6 finally mark the end of Carbon?
Why Mac OS X has Two Main APIs.
In 1997, Steve Jobs returned to Apple and gained control over the largest desktop software platform outside of Windows. For the previous ten years, Jobs had been promoting a new platform at NeXT, which advanced upon Apple’s graphical interface with a UNIX underpinning underneath and an advanced set of development frameworks on top. That product, known as NEXTSTEP, was suffocated in the market in the early 90s between Apple’s consumer and creative stronghold and the increasing ubiquity of Microsoft’s Windows.
Apple sued NeXT to prevent it from entering the consumer market, and Microsoft worked hard to prevent it from gaining any exposure, worried that its own tepid undertakings with OS/2 then Windows NT would be blown out of the water by NeXT’s far superior, already existing technology built on top of UNIX. DOS vendor Bill Gates famously fumed that rather than developing for NeXTSTEP, he’d “piss on it,” and he personally delivered the vaporware “vision” of Cairo in 1991 with the direct intent of neutralizing any interest in the excellent technology that already existed in NEXTSTEP in favor of promises that Microsoft would deliver the same thing at some point. It never did.
Despite limited sales, NEXTSTEP powered a number of significant developments in the early 90s, including work by Tim Berners-Lee to develop the web, pioneering development efforts in video games by John Carmack of id software, and custom application development among clients in securities banking and intelligence services, each of whom had needs unaddressed by DOS and the rest of the market.
With the fusion of Apple’s market position and NeXT’s technology in 1996, Jobs’ development team hoped to quickly migrate Mac users and developers to the NEXTSTEP tools. Advanced under the name Rhapsody, the plan intended to essentially modify the look of NEXTSTEP to be more familiar to Mac users and update its core OS to roll in recent advances. Large Mac developers rejected the move, as it would have forced them to rewrite their apps from scratch or else have them run in a second tier compatibility box.
At the time, Apple’s fortunes weren’t exactly inspiring confidence, so developers were hesitant to jump on the company’s latest strategy and invest significant resources in an unproven plan by a vendor that had repeatedly dropped, sidelined, and materially changed its development roadmap too many times over the last half decade already.
Introducing Carbon and Cocoa.
To pacify its existing developer base, Apple announced two sets of “Application Programming Interfaces,” describing independent approaches to creating applications that would run on Mac OS X. The existing Classic Mac OS APIs would be cleaned up and modernized under the name Carbon. Existing Mac OS apps could be “carbonized” by making relatively minor changes that would allow them to run cleanly against the Carbon API in development on Mac OS X, while also running on the existing Classic Mac OS 8/9 with the CarbonLib plugin.
For developers who wanted to target both existing Mac users and future users of Mac OS X, Carbon was the only choice available. Apps that were not carbonized would only work on existing versions of the Classic Mac OS or in a specialized compatibility environment under Mac OS X called Classic or the Blue Box.
The minority of developers already familiar with NEXTSTEP could continue to develop using the NeXT frameworks APIs, now called Cocoa and briefly referred to as Yellow Box. Between 1997 and 2002, when the first mainstream version of Mac OS X was released, Apple had to focus on maintaining support for existing Classic Mac OS users. That required getting Carbon up and ready so that existing applications could run on the Macs Apple was selling, and so that those apps could be migrated to the upcoming Mac OS X as smoothly as possible.
Between 2002 and 2005, Apple worked hard to push out regular references releases and frequent updates that brought Mac OS X from a brand new system into the realm of being a reliable, secure, and well performing operating system. During that period, users began seeing a difference between applications built from Cocoa and those developed in Carbon. For example, there were differences in appearance and consistency, because Carbon let and/or forced developers do their own thing, while Cocoa provided more given functionality for free.
Carbon vs Cocoa: Hype Wars.
However, the actual differences between Carbon and Cocoa were often overblown by pundits who made sweeping generalizations based entirely upon abstracted marketing names. Cocoa and Carbon did not develop as completely independent toolsets. Because so much of the Classic Mac OS and NEXTSTEP functionally overlapped, Apple made a number of major changes in Mac OS X that pulled from both.
The power of NEXTSTEP’s frameworks came from object oriented development, where code objects are treated as units of behavior and data that can be organized into a class hierarchy with inherited features, easily modified into a similar but distinct subclass, and reused frequently. Classic Mac OS programming followed a more procedural model, where everything is written by hand in custom code that can be relatively harder to reuse or repurpose.
In order to preserve the benefits of NeXT’s object oriented Cocoa while bringing forward support for classic procedural development, Apple defined a large number of core system functions as procedural APIs, and built object oriented frameworks on top. Rather than being opposite toolsets, Cocoa is in many respects an alternative, object oriented way of accessing the procedural core of Mac OS X. That means Carbon can’t really go away entirely, because Cocoa relies on it.
At the same time however, it makes increasingly less sense for Apple to promote Carbon development to third party developers, as doing so requires Apple to build both procedural and object oriented interfaces for each new framework created. Apple has been focusing attention on Cocoa for several years now, and clearly wants developers to migrate toward it. When they do, developers can get a lot of functionality for free as Apple updates and refines Cocoa.
Applications often use a mixture of both APIs. Historically, developers have had to rely on Carbon because Cocoa didn’t always address their every need. In part, that was originally because Apple was focusing on getting Carbon finished, and so did not have the resources to complete everything in Cocoa. Since Mac OS X 10.4 Tiger, the emphasis has very obviously swung to Cocoa because the effort needed to advance Carbon was complete; there were no more apps to transition from the old Mac OS. In the future, Apple will continue to promote development in Cocoa.
That’s already the case on the iPhone, which only offers a Cocoa interface. There’s no need to shoehorn in old Classic Mac OS apps, so there’s no need for Carbon. The iPhone therefore marks the return of Jobs’ clean NEXTSTEP, unadulterated by two decades of Mac OS legacy. What the iPhone offers today is what the desktop will offer in the future. That doesn’t mean Carbon’s procedural programming will be yanked from the body of Mac OS X, but it will be put to pasture rather than being incrementally maintained in lockstep with Cocoa.
The Return of Rhapsody.
At some point, Mac OS X will begin to look a lot like Rhapsody: applications will all be Cocoa apps. That will take some time, but the writing is on the wall and has been for years. The most obvious evidence of this was the announcement last year that 64-bit graphical interface APIs would not be exposed in Carbon, but only in Cocoa. That means any developers wanting to make use of 64-bit applications in Leopard will need to at least build their interface using Cocoa.
Apple is pushing a Rhapsody-like strategy now because it finally can. In the late 90s, Apple desperately needed Adobe, Microsoft, and other big developers to support its plans just to get Mac OS X off the ground. Now the tables are turned. Apple can dictate what developers need to do, and push them to use more modern tools because the company has a far stronger user base and forward momentum. In the case of the iPhone, Apple is starting from a clean slate.
The immediate advantage of pushing developers to Cocoa will be a more consistent user interface, better support for resolution independence, faster development, cleaner code, and less code, because Cocoa does more heavy lifting itself. Another benefit to moving decisively to Cocoa is the prospect that Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows. Such an effort would pull wind from the sails of Microsoft’s .NET while focusing more attention on Cocoa just as developers are expressing a lot of interest in the iPhone.
Mac OS X 10.6 Snow Leopard, Carbon, and the Future.
While Apple clearly wants developers to use Cocoa, it simply can’t remove Carbon, and has no compelling reason to attempt to do so. The upcoming version of 10.6 will continue to run Carbon code, and support ongoing Carbon development.
As noted in WWDC 2008: Is Mac OS X 10.6 the Death of PowerPC?, Snow Leopard has been confirmed by multiple, independent sources as not introducing any new marketing features. One source noted “What this release does is clean up some stuff that needed it badly over the years and position Apple to focus on a single platform and get rolling with a faster leaner release cycle.”
In addition to continuing work under the hood in the areas of resolution independence and kernel level security, sources report that 10.6 Snow Leopard will also introduce the new concept of blocks, which will be covered in more depth at WWDC.
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!