A developer’s-eye view of Leopard, part III

Mac users have high expectations. A newcomer to the platform quickly discovers that all Mac applications share consistent appearance and behavior, are incomparably fast, and come with “Wouldn’t it be great if I could …?” user interface experiments that tend to just work.

Mac developers are a remarkable lot, it’s true, but they’re not rolling all of this rich functionality, suite-like cross-app integration, and consistent behavior by hand. It’s in the OS X frameworks. Rich text document and HTML editing, ubiquitous drag-and-drop, spelling- and grammar-checking, dictionary lookups, search, PDF export, hyperlinks, video and audio playback and recording, complex 2-D and 3-D rendering with CPU/GPU optimization, and so much more is integrated into the frameworks such that just picking a framework class to add a feature makes it Mac platform standardized and compatible.

Even when Apple supplies several approaches to achieving the same end in order to accommodate developers’ various preferences, the company ensures that all those tactics result in a completely consistent user experience. No matter what software you add to a Mac, the whole system feels like an integrated suite.

Delicious Cocoa Cocoa is the root framework, the primary API, for all native Mac applications written in Objective-C. There are wrappers and bridges that allow using some Cocoa facilities in other languages, including C, C++, Python, and Java, but the only way to suck all of the goodness out of Cocoa and the Mac’s other object-oriented frameworks is to use Objective-C.

Now that Apple is using Objective-C for all of its application development, visual and functional elements that Apple builds into its programs are finding their way into Mac frameworks so that developers can evolve their apps into Leopard’s updated look, feel, and feature set. It’s surprisingly easy to do, and in some cases, developers don’t have to lift a finger — not even recompile their code to add the features that weren’t present in the Tiger release of their application.

The most accessible examples of the zero-effort Tiger-to-Leopard transformation are Text Services and unified window styles. In Tiger, all Cocoa applications that incorporate text-entry fields inherit OS X’s spelling checker. The Cocoa framework that ships with Leopard adds a grammar checker that tries to flag awkward or improper sentence construction and various barriers to readability. Its smart quote support converts open and close quote pairs to tails-up, tails-down style in formatted documents and flat, HTML-friendly quotes for plain text. Hyperlinks found in a Cocoa text-editing field are automatically detected and rendered in a familiar standout underlined style that launches the browser by default. Multiple regions of selected text can be copied and pasted with the same ease as contiguous sentences and paragraphs. With Leopard, text attachments can also be edited inside a document being viewed without the need to pop up a text-editor window.

These might seem like small changes, but they add up to key functionality that developers previously had to code into their applications. As with all features that Apple adds to revisions of its frameworks, everything is optional, and everything can be superclassed to add functionality and make objects that implement an application-unique feature set without sacrificing consistency or compatibility.

Compelling scripts Cocoa provides hooks for making applications scriptable, that is, usable as services by other Mac platform apps. The scripting interface to Mail, for example, is not merely capable of invoking a message composition window. A script that interacts with Mail can extract messages from the inbox, perform searches, and create rules to govern the handling of incoming mail. OS X incorporates an elaborate but thoroughly abstracted dynamic remote procedure invocation mechanism for native applications. It’s based on messages, as is all of Cocoa, and is therefore far more robust than one would expect from interpreted scripts.

While Cocoa’s scripting support exceeds other platforms’ capabilities, it has been practically limited to script-to-application interaction, that is, invoking calls into Cocoa applications from external scripts. Oddly, as useful as it would be to do so, it’s extremely difficult to invoke calls to Cocoa applications from other Cocoa apps.

In Leopard, Cocoa addresses this. A new facility, Scripting Bridge, generates Objective-C code that effectively turns scriptable Cocoa applications into objects whose methods can be invoked from other Cocoa applications; hooking two or more applications together requires no middleware. One inherits this capability simply by adopting Cocoa.

For native applications, adopting Cocoa means adopting Objective-C. C++ lacks Objective-C’s runtime dynamic linking capabilities, while Objective-C is both dynamic and fully compiled. However, there are fully dynamic (interpreted) object-oriented languages, and Apple has chosen to raise two to first-class status: Ruby and Python. By first-class, I mean that Ruby and Python code can share objects with and call into Cocoa and Objective-C, and Cocoa and Objective-C can share with and call Ruby and Python.

With this, Leopard lets some steam out of .Net by extending the platform’s native object-oriented paradigm — not an interpreted layer on top of it — to two established dynamic languages. Cocoa is a runtime layer for object-oriented dynamic applications; there was no need to create one as was done for .Net.

Objects of affection OS X’s pervasive object-oriented paradigm is extensible, and Apple has done a lot of extending in the form of new and enhanced frameworks. Among the frameworks added to Leopard are Publish/Subscribe, which provides applications with classes that handle creating and consuming RSS and Atom feeds. Publish/Subscribe abstracts networks, formats, and protocols, wiping out hundreds of lines of code that applications would require to incorporate RSS functionality without relying on an external reader.

The Publish half of Publish/Subscribe lets applications generate content that the framework packages and sends to a server that supports the Atom Publishing Protocol, which will include Apple’s .Mac service and the Weblog server included in Leopard Server. File deposition via FTP and WebDAV is supported as well.

The Core Data framework embeds high-performance client database functionality into applications. Core Data doesn’t rely on a connection to an external database, but rather on a lightweight database engine embedded in OS X and used by system facilities such as Spotlight. With Leopard, Core Data 2.0 will implement transaction-safe handling of arbitrary file formats to reduce the need to format data expressly to fit in a fixed schema.

The structure of data that needs to be stored changes over time, and a perennial headache for database administrators and developers is managing multiple versions of database schema and nondestructively migrating data from one version of the schema to another. Core Data 2.0 framework handles this. It has also been updated for compatibility with garbage-collected and 64-bit Objective-C applications, and it will feature performance boosts in the form of prefetching and rapid retrieval of object identifiers for those circumstances where only a list of IDs is needed.

Spotlight on Time Machine Leopard’s application framework enhancements are too numerous to squeeze into even a series of stories, but one last standout deserves mention: Leopard incorporates changes to its file system to support enhancements to Spotlight and to enable Time Machine automated backup. Leopard supports metadata searches on remote systems, whereas Spotlight’s implementation in Tiger is limited to local disks. Leopard allows applications to replace the contents of files without overwriting their metadata. Files that take on minor changes don’t need to have potentially extensive metadata rewritten from scratch, which can be problematic when metadata is under the control of another application. This facility also allows the construction of default metadata sets that can be applied to newly created files.

Leopard’s Time Machine tracks changes to files and maintains time-stamped logs of those changes on external servers or media, creating real-time incremental backups. One of Time Machine’s foundations is lineage information, a structured means of establishing relationships between versions of a file. Developer access to lineage data allows them to navigate the file system and effectively open a file as it existed at a given point in time. Imagine adding “when” criteria alongside the file name in a call to open a file.

Cocoa and Objective-C equip developers with capabilities they could only create for themselves with tremendous effort, and for which they’d pay dearly to third parties on Windows. Just as Mac users grow accustomed to having the answer to “Can I …?” come back “yes,” Mac developers find they get the same answer when they ask whether something they need is already built into Leopard’s application frameworks.

Additional resources Review: Leopard Server: The people’s UNIX Mac OS X v10.5 is true UNIX on the inside, novice admin friendly on the outside, and born for collaboration, with turnkey-simple blog, wiki, IM, and calendar services Review: Mac OS X Leopard: A perfect 10 Apple’s new operating system and its massive new feature set challenge users and developers to explore new and better ways of working A developer’s-eye view of Leopard, part I Xray and Core Animation stand out among Apple’s immense bag of new Leopard tricks A developer’s-eye view of Leopard, part II Leopard’s Xcode3.0 integrated development environment and Objective-C 2.0 language help define the Mac platform A developer’s-eye view of Leopard, part III Cocoa and other sweet object-oriented frameworks magically make all Mac apps part of an integrated suite A developer’s-eye view of Leopard, part IV 64-bit Darwin, Dashcode, Time Machine, and Ruby on Rails call on developers to trade out established skills for new ones Tom Yager: Enterprise Mac