Cocoa Vs. Carbon?by James Duncan Davidson
With Mac OS X, there are a number of frameworks that can access the functionality of the system. So many in fact, that a fair share of Monday's Apple Worldwide Developers Conference (WWDC) sessions were devoted to explaining the four primary frameworks of Java, BSD, Carbon, and Cocoa and how they fit together.
It's pretty obvious where Java and BSD fit into the system and when each should be used. And yes, as odd as it may sound, the BSD layer can be considered a framework because it gives access to all of the Unix underpinnings of the OS as well as tools such as
diff. But the distinction of how the other two APIs -- Carbon and Cocoa -- fit together has been confusing to many.
Competitors or teammates?
Part of the confusion stems from the way that Carbon has been positioned as the way for older apps to be "ported" to run on OS X, while Cocoa has been positioned as the next-generation method of creating OS X applications. The two frameworks have almost been positioned as competitors. And this leads developers to have debates over which is better. I have even heard conversations both in person and on mailing lists that sound the beginnings of the historic emacs vs. vi wars.
As I sat through the sessions that explained how all the pieces fit together, it became clear that these were not really competing APIs.
Cocoa uses quite a bit of Carbon functionality. For example, the Print dialogs are Carbon functionality. But this is really an impelementation detail from an application developer point of view.
As you're learning about the Mac OS X frameworks, including Java, how do you see things fitting together?
More Coverage of the Apple Worldwide Developers Conference Coverage:
As Scott Forstall, Apple's director of application frameworks, said, having two complete APIs with their own implementation would be wasteful, and it's important to maximize reuse in the system. In addition, Carbon is a growing API that is still under active development. Each release will bring more new APIs that expose even more functionality.
After Monday's presentations, it seemed to me that the right way to look at the two frameworks is not side by side as all of Apple's marketing material would indicate, but as Cocoa building on top of Carbon.
When looked at this way, it becomes apparent that Carbon is the procedural native framework, and that Cocoa is the object-oriented native framework of OS X building on Carbon.
Developers are free to choose the level they want to program at. Developers choosing to work within Cocoa have all of Carbon's goodies just waiting to be tapped.
James Duncan Davidson is a freelance author, software developer, and consultant focusing on Mac OS X, Java, XML, and open source technologies. He currently resides in San Francisco, California.
Return to the Mac DevCenter.
There is no master plan
2001-05-28 01:26:24 laird [View]
2001-05-28 01:22:11 laird [View]
It strange nobody mentioned it but carbon is the way to go for cross platform
2001-05-25 02:34:14 eredler [View]
OO vs. Procedural just might not cut the whole cake
2001-05-24 14:20:52 stefaanh [View]
Correction: Save dialogs are not Carbon, but Print Dialogs Are.
2001-05-23 22:42:21 James Duncan Davidson | [View]
Cocoa Vs. Carbon
2001-05-23 10:28:39 ali1 [View]
I thought carbon would be the interim API ..
2001-05-23 09:05:33 zenarcade [View]