A Yellow Box of Cocoa
Cocoa is Apple's marketing name for one of the two prominent application development environments in Mac OS X. It derives from the object oriented development tools that originated at NeXT, acquired by Apple in 1996.
During the development of Mac OS X, NeXT's technology was first referred to as the Yellow Box, in contrast with the Blue Box of classic Mac development tools, and then was later renamed Cocoa to suggest an association with Sun's Java, which was at its apex of hype as a popular buzzword at the time. Java itself had borrowed concepts from NeXT.
Apple's existing procedural development tools for the Mac OS were renamed Classic, and portions were carried forward in a modernized environment called Carbon. This allowed existing code written in the 90s to be carried forward to the new Mac OS X and run natively, once relatively minor adaptations were made.
Carbon vs Cocoa
While Carbon and Cocoa are often portrayed as pitted against each other in dramatic rivalry as two opposing camps of development, Apple has actually worked to advance both to serve different needs. As Apple notes in its Mac OS X System Architecture documentation, Carbon has been positioned as a lower level framework that provides access to bare metal functionality. Cocoa is designed to help developers build robust, complete applications rapidly by providing easy to use frameworks that handle a lot of the background work for them.
At the same time, there is some overlap between the two, particularly in the realm of building user interfaces. Developing and promoting two separate development environments to do many of the same things has stretched the company's resources with increasingly less upside.
Once it delivered a fully functional Carbon environment, Apple could focus on promoting Cocoa as an easier to use, more consistent, and more flexible and portable set of Application Programming Interfaces. Last year, Apple made it easier for Carbon developers to add Cocoa to their apps. It then announced that, starting with Leopard, portions of the APIs used to build 64-bit graphical apps would only be delivered for Cocoa.
That meant that while both Carbon and Cocoa could continue to be used to build 32-bit apps or 64-bit servers and other faceless apps, any efforts to deploy 64-bit apps with a graphical front end would need to have their user interfaces built in Cocoa.
After signaling the intention at this year's WWDC to deliver all bundled apps in Snow Leopard with 64-bit capabilities (and the ability to run as 32-bit in order to support existing Macs without 64-bit processors), the writing was clearly on the wall that Apple would need to port the graphical portions of all its bundled apps to Cocoa.
Apple's Cocoamotion
The move to Cocoa benefits Apple because it can devote its limited resources into a single set of APIs for developing graphical apps. By tying the move to 64-bits with a transition to Cocoa, Apple is also pushing developers of legacy Carbon apps to make both jumps together rather than stringing things along for years.
This is less than ideal for companies such as Adobe and Microsoft, which have built cross-platform tools based on the lower level Carbon. Their move to a Cocoa user interface will take additional effort, something that Adobe noted as the cause for its failure to ship 64-bit Photoshop CS4 for the Mac. When they do deliver their 64-bit apps however, those apps will benefit from being developed in Cocoa. Apple faces the same challenges in building a Cocoa face for its own Carbon apps, including Final Cut and Logic.
Developers benefit from the move to Cocoa because it gives them a consistent user interface, more of which comes for "free." Rather than custom coding large parts of their user interface, Cocoa makes it easier to adopt the new widgets and interface conventions Apple has pioneered in its iLife, iWork, and other apps, and subsequently made available to third parties. Using Cocoa also gives developers a leg up in supporting the resolution independence built into Mac OS X.
What Cocoa does for users
For users, the move to Cocoa means that applications will have more consistent appearance and behavior. Apps that make use of standardized interface controls rather than building their own will not only be more familiar, but users will also benefit from the code exercise and reuse, which removes bugs and allows for centralized optimizations. In other words, Apple can address user interface problems that in turn impact all apps.
This doesn't mean Apple is abandoning Carbon or a variety of other new APIs that are similarly procedural, C language APIs. The new (in Leopard) Core Text is defined as part of Carbon, and Cocoa provides an object oriented wrapper for it in the Cocoa Text System. Core Video, QuickTime, and Quartz lie outside the definitions of Carbon and Cocoa, and Apple presents dual Cocoa and Carbon interfaces for working with these.
Rather than the removal of Carbon, Apple's move to Cocoa in Snow Leopard is a consolidation of future efforts, starting with the user interface. More effort has gone recently into making new Cocoa 'kits' than in building entirely new Carbon APIs. The QTKit, PDFKit, and Core Animation are all examples of new, recommended Cocoa tools for doing things that are easier and more powerful than building from scratch in Carbon.
The Cocoa iPhone
The iPhone has already become 'fully Cocoa' in its user interface, highlighting why Apple is investing its efforts into one environment with the portability to stretch beyond conventional desktop computing. As Apple evaluates new product directions, from netbooks to tablets to TV boxes, having consolidation behind a single, modern application framework will make it easier to both create new products and to gain third party developer support behind them.
As mobile developers rush to get up to speed with the iPhone's Cocoa Touch to participate in the wild success of the Apps Store, they'll gain crossover skills in developing for the Mac, too. In just a year, Apple's smartphone has effectively increased the installed base of its Cocoa systems from the roughly 20 million Macs running Mac OS X to more than 30 million devices in total. Apple expects this installed base to grow rapidly.
By decisively pushing developers to implement their user interface using Cocoa, Apple will end up with less code maintenance, more focused development efforts, and a broad, flexible platform that's easier to pilot into the future.
69 Comments
This won't stop Adobe from completely bypassing any benefits a Cocoa GUI would bring to their development processes and the user by creating a custom interface that nobody likes and that steals time away from developing new features that are actually worth 500+ dollars in upgrade price.
The WHOLE POINT of Cocoa is to make the interface as easy and painless to create as possible so that the developers can concentrate on developing features instead of reinventing the wheel in the 'interface department'.
Hey, Adobe, if you want to create your own interface paradigms, build your own effin' OS.
Hopefully, 10.6 will strip out support for developing Carbon apps but will still run legacy apps and 10.7 will completely strip out all run-time support for Carbon apps. That should have happened back about 10.3 or 10.4. It's time to move forward.
I've always found Cocoa applications like Safari and Mail much more stable than Carbon apps, such as iTunes or Finder. I don't know which one is better, or if one can ever reach such a conclusion, but I sincerly look forward to more Cocoa seeing as Multiclutch only works with Cocoa-apps.
Is there any developer or programmer on these boards that could join in with their opinions regarding this strategy?
Yeah, Appleinsider! What you said.
I've always found Cocoa applications like Safari and Mail much more stable than Carbon apps, such as iTunes or Finder.
Ha yes, Safari. The only program that gives my machines spinning beachballs... I hope those will disappaer with Safari 4 cause it's just rediculous imo.
Also, perhaps I misinterpret this but seems like Apple is only Pushing Cocoa for the GUI layer, lots of background stuff will still be Carbon.