Making the move to the Mac

AppKit and Foundation Kit Frameworks

Hand in hand with Obj-C go the classes that are available to an Obj-C programmer. There are two main class libraries, Foundation Kit and AppKit. In general, the Foundation Kit (usually just Foundation) implements relatively low level objects such as arrays, strings, keyed dictionaries – a very "key" (sorry) part of Cocoa programming – and the like while the higher level AppKit brings GUI-related classes such as windows and panels, buttons, and scrollbars to the party.

Both these class libraries are implemented as frameworks. In Windows-land, examples of application frameworks include the Delphi VCL, MFC, .NET WinForms, and more. In Cocoa programming, framework has a more precise technical meaning. A framework is, basically, a directory which contains a shared library (like a DLL under Windows) as well as any resources (images, strings, sound files, etc) needed by the class library.

Importantly, the framework also contains any header files corresponding to the class libraries contained therein. This makes a framework pretty much self-contained apart from the obvious comment that it might itself depend on other frameworks. The upshot is that, when working with XCode (which we'll be looking at in Part 2) you can just drag an existing framework onto your project and XCode will immediately have access to all needed info.

Incidentally, while talking about frameworks, this would be a good point to mention "bundles". A framework is a specific type of bundle, but not all bundles are frameworks. A bundle is essentially a directory with a special suffix which causes the Finder to support the illusion that it's a single, indivisible file.

The most common type of bundle is an application bundle with a suffix of .app (Hint: try creating a new folder on your desktop, rename it to fred.app and you'll see the default application icon appear). An application bundle might contain numerous resources, support for multiple languages, and even one or more private frameworks. But the end-user sees only a single file which can be installed by simply dragging to the Applications folder or de-installed by dragging to the trash. Ah, if only Windows worked like that.

What Is Cocoa?

I've referred to Cocoa a few times in this introductory piece. What exactly is Cocoa? Well, opinions differ. If you check out the Wikipedia article on Cocoa (API) you'll be told that a Cocoa application is one written using the Cocoa programming environment.

Unfortunately, the article earlier contradicts itself by saying you can also use command-line tools and the gcc compiler to create a Cocoa app. The same article also suggests that Cocoa applications have a distinctive feel. I'd also disagree with this because you can get much the same distinctive feel using Carbon (the distinctive look and feel of OS X comes from the Aqua GUI which is available to Carbon and Cocoa). So what's my take?

Basically, a Cocoa application is one that makes use of the AppKit and Foundation frameworks. It's typically written in Objective-C, but could be written using any language which has bindings capable of accessing these Objective-C frameworks. It's typically created using the XCode development system but – again – you can use command-line tools if you wish.

The Carbon API, on the other hand, has been around for longer than Cocoa. Arguably, it's a lineal descendant of the original Mac toolbox APIs. Carbon is procedural, so it can be called more easily from C, Pascal, and so on. There is some debate at the moment regarding how much of Carbon is going to be ported to the 64-bit programming environment under Leopard. In this mini-series, I'm going to concentrate exclusively on Cocoa.

Next time round we'll look at XCode and Interface Builder, the primary Mac development tools. Again, I'll try to do it from the perspective of a Win32 RAD programmer. ®