Which Frameworks Are Part of Cocoa?

Cocoa is really a combination of classes from more than one framework. Classically speaking, it's the combination of the Foundation and AppKit frameworks. That's how it was in the NeXT days, and is maybe is even the way it's still described in the official docs. From a functional perspective, though, there's more to it.

Starting with Tiger, anybody sitting down to write a new Cocoa application is probably going to use Core Data in some capacity, or at least give serious consideration to doing so. In my opinion, there's very little reason not to. It's the result of a decade or more of evolution and feels very solid for 1.0 release. It's also integrated into Interface Builder. You can use Core Data from a Carbon application, but I don't think anyone actually does this.

If there are any remaining doubts, we can look at Cocoa.h:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#import <CoreData/CoreData.h>

So in day-to-day terms, Cocoa is at least three parts: Foundation, AppKit and Core Data. But is that it? What about CoreFoundation?

From a public API perspective, CoreFoundation is not part of Cocoa and has to be explicitly added to a project. It's a procedural C-based API, but acts like Cocoa in that you have reference counting and methods that act on "objects." They're not objects in the Objective-C sense, but they are pointers to structs which is ultimately all an Objective-C object is anyway. None of this makes CoreFoundation part of Cocoa, though.

In fact, CoreFoundation was originally invented as a way to support the Carbon world. It took a lot of design cues from Objective-C and Foundation, but ultimately was designed as a way to support a C environment.

The one interesting bit of information here is that a number of Foundation classes share a common implementation with their CoreFoundation counterparts. For example, CFArray and NSArray are interchangeable (which is why you might see references to NSCFArray in runtime exceptions). The same goes for things like CFString, CFData, CFDictionary, CFNumber, CFSet and so on.

Since you can't really use Cocoa without using NSStrings and NSArrays, this makes the case that the code in CoreFoundation is at least heavily related to Cocoa. One nice side benefit of this is a good part of CoreFoundation is open source, so if you're curious how the internals of NSArray and such work, you can try digging into some of the source.

So offically, it looks like Cocoa is split between Foundation, AppKit and CoreData, though I'd actually include CoreFoundation as at least a sidekick if not a full-fledged member.
Design Element
Which Frameworks Are Part of Cocoa?
Posted Dec 23, 2005 — 7 comments below


Stephen C. Johnson — Dec 23, 05 629

Mr. Stevenson,

You write VERY interesting stuff. Thanks.

Brad — Dec 23, 05 630

I've always thought of it as being based on the language. If it's obj-c it's Cocoa. (Not counting java since who uses it? =) Take for example the address book APIs. You have the straight c version and an obj-c version. I always think of the obj-c version as the Cocoa address book api.

mls — Dec 24, 05 632

If one likes to dig a bit deeper into CFArray look here: ridiculousfish.com/blog/ (you will also find an interesting post on nil in Objc there btw).

Daniel Price — Jan 01, 06 637

I would love to use Core Data, but my Mac Mini does not support it. What's with that?

Scott Stevenson — Jan 02, 06 638 Scotty the Leopard

Your mini does support it -- Core Data is not limited to certain hardware. What gives you the impression that it doesn't work?

Dan Price — Jan 03, 06 639

Sorry I misread it - that's Core image. My bad.

Ashish — Sep 19, 08 6391

Stevenson your articles are very nice and easy to understand. Thanks for it.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015