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.

Comments Temporarily Disabled

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