Programming on Mac OS X

Technorati Tags: Operating System

Mac OS X is a fertile field for all kinds of programming endeavors, especially if you have a *nix frame of reference. Life is still much better for a developer on Windows than on Mac OS X - no matter what one might think of the usability, etc. of Windows.

Apple has been trying to improve things for developers lately, which is a good sign. This page discusses some programming facilities, frameworks and tools available on Mac OS X.

Application Environments

Since Mac OS X is derived from various sources, it has a multitude of Application Environments.

Carbon

This is a set of procedural C-based APIs for Mac OS X that is based on the old Mac OS 9 API (actually dating back as far back as Mac OS 8.1). Carbon was originally designed to provide an easy development migration path from Mac OS 9 to Mac OS X. The Carbon APIs are all-encompassing (they include legacy interfaces), covering most things that you are likely to do programmatically on Mac OS X. Carbon specific code is not portable to other platforms.

Classic

Mac OS X includes a Classic (Mac OS 9) emulator that executes in a protected memory environment so as to let users run programs written for Mac OS 9. Apple does not encourage to actually develop for this environment.

Cocoa

This is an object-oriented Objective-C based API and that's the preferred way of doing things in Mac OS X (if what you want to do can be done through Cocoa); particularly because of how well it is supported by Apple's Rapid Development tools. However, there are many parts of Mac OS X, and applications from 3rd party vendors, that have not converted to Cocoa completely, or at all. A Cocoa application can call the Carbon API when necessary. Cocoa is largely based on the Open Step frameworks, and consists of primarily two parts: the Foundation (fundamental classes) and the Application Kit (classes for GUI elements).

Java

Mac OS X includes a complete J2SE implementation. The Swing implementation generates native OS X GUI elements for a uniform look and feel. JAR files are treated as shared libraries. Note that Cocoa includes Java packages that let you create a Cocoa application using Java as the programming language.

Bundles and Frameworks

Mac OS X uses a few concepts not found on many traditional BSD, Linux, Solaris etc. systems.

Bundle

Bundle is a directory that stores executable code and the software resources (icons, splash images, sounds, localized character strings, interface builder "nib" files, .rsrc resource files, etc.) related to that code. Although a bundle is a directory containing potentially numerous subdirectories and files, it is treated as a single entity for various purposes.

Mac OS X can have different kinds of bundles:

• An "Application" bundle (such as Foo.app) contains everything (except frameworks/libraries coming from elsewhere) needed to run the Foo application. It is possible to simply drag Foo.app to any location and it will work as expected (you do not even have to do anything to its Dock icon, if any - courtesy the fact that "aliases" on HFS+ do not break if you move a file without replacing it). The /Applications directory contains many such bundles.
• A "Framework" (such as Bar.framework) is a versioned bundle containing resources such as headers, documentation, etc. The /System/Library/Frameworks directory contains numerous frameworks (such as for Kerberos, Python, QuickTime, ScreenSaver, and so on).
• A "Loadable" bundle can be a kernel extension (a .kext, similar to a loadable kernel module on Linux, say), many of which exist in /System/Library/Extensions, a Plug-in or a Palette.

One of the Finder flags is kHasBundle, which, if set, makes the bundle appear as a file package (a single opaque entity), with exceptions and specific behavior for different bundle types.

The various bundle extensions referred to above are only conventions - a bundle can have any extension. For example, instead of a .app, you can have a .debug or .profile to imply debug or profile code, respectively.

Framework

Framework, as stated above, is a type of a bundle that contains shared resources such as dynamic shared libraries, header files, icons and images, documentation, etc. Moreover, frameworks are versioned. Major versions are incompatible while minor versions are compatible. One framework can have multiple major versions.

Consider an example:

# ls -lF /System/Library/Frameworks/OpenGL.framework

total 32

lrwxr-xr-x ... Headers@ -> Versions/Current/Headers

lrwxr-xr-x ... Libraries@ -> Versions/Current/Libraries

lrwxr-xr-x ... OpenGL@ -> Versions/Current/OpenGL

lrwxr-xr-x ... Resources@ -> Versions/Current/Resources

drwxr-xr-x ... Versions/

Except Versions/, everything else is a symbolic link (to entities from the current major version). The fileOpenGL is the dynamic shared library:

# file -L OpenGL

OpenGL: Mach-O dynamically linked shared library ppc

The default path for searching frameworks (as used by the dynamic link editor) is:

$(HOME)/Library/Frameworks

/Library/Frameworks

/Network/Library/Frameworks

/System/Library/Frameworks

As we have seen, Mac OS X has complex entities (like a .app directory tree) exposed as a single, click-able entity through the Finder. The same effect as double-clicking on an entity's icon can be achieved on the command line through the open utility. It opens a file, folder, or a URL, in an appropriate manner. For example, opening a .app folder would launch that application, opening a URL would launch an instance of the default web browser with that URL, opening an MP3 file would open it in the default MP3 player, etc.