< Previous PageNext Page >

The Cocoa Environment

Cocoa applications are gradually becoming the norm for Mac OS X. iPhoto is a Cocoa application, as are the Safari and Mail applications. These applications have received a fair measure of critical acclaim for their clever designs, rich feature sets, and appealing user interfaces. But what is not apparent to the average user is how quickly (compared to typical development cycles) these applications were brought from design stage to deployment. What is it about Cocoa that makes it a viable and even compelling alternative to Carbon as an application and development environment?

In this section:

Introducing Cocoa
How Cocoa Fits Into Mac OS X


Introducing Cocoa

As with all application environments, Cocoa presents two faces; it has a runtime aspect and a development aspect. In its runtime aspect, Cocoa applications present the Aqua user interface and are tightly integrated with the other visible portions of the operating system: the Finder, the Dock, and other applications from all environments. In fitting in, in becoming a seamless part of the user experience, Cocoa in its runtime aspect exhibits excellence.

But it is the development aspect that is the more interesting one to programmers. Cocoa is an integrated suite of object-oriented software components—classes—that enables one to rapidly create robust, full-featured Mac OS X applications. These classes are reusable and adaptable software building blocks; developers can use them as-is or can extend them for their specific requirements. Cocoa classes exist for just about every conceivable development necessity, from user-interface objects to Bonjour networking, and where a need hasn’t been anticipated, you can easily create a subclass of an existing class that answers that need.

Cocoa has one of the most distinguished pedigrees of any object-oriented development environment. From its introduction as NeXTSTEP in 1989 to the present day, it has been continually refined and tested (see “A Bit of History”). Its elegant and powerful design is ideally suited for the rapid development of software of all kinds, not only applications but command-line tools, plug-ins, and various types of bundles. Cocoa gives your application much of its behavior and appearance “for free,” freeing up more of your time to work on those features that are distinctive. (For details on what Cocoa offers, see “Features of a Cocoa Application”.)

You may use several programming languages when developing Cocoa software. The primary language is Objective-C, which has its own runtime for Cocoa. Objective-C is a superset of ANSI C that has been extended with certain syntactical and semantic features (derived from Smalltalk) to support object-oriented programming. The few added conventions are simple and easy to learn and use. Because Objective-C rests on a foundation of ANSI C, you can freely intermix straight C code with Objective-C code. Moreover, your code can call functions defined in non-Cocoa programmatic interfaces, such as Carbon and BSD. You can even mix C++ code with your Cocoa code and link them into the same executable. Finally, Cocoa supports the Java language through a parallel set of Java classes and a mechanism that bridges the Java interfaces to their corresponding Objective-C implementations. The Java flavor of Cocoa allows you to mix (within limits) native Java objects with Cocoa objects.

Important: Cocoa-Java is a learning environment for developers familiar with the Java language. It is not recommended for production work. The Cocoa-Java API is no longer maintained in parallel with the Objective-C API as the latter evolves.

You can even program for Cocoa using PyObjC, the Python/Objective-C bridge. PyObjC lets you to write Cocoa applications in Python, which is an interpreted, interactive, and object-oriented programming language. PyObjC makes it possible for Python objects to message Objective-C objects as if they're Python objects, and also for Objective-C objects to message Python objects. For more information, see "Using PyObjC for Developing Cocoa Applications With Python" on the Apple Developer Connection website.

The core Cocoa class libraries come packaged in two frameworks, Foundation and Application Kit. As with all frameworks, these contain not only a dynamically sharable library (or sometimes several compatibility versions of libraries), but header files, API documentation, and related resources. The duo of Application Kit and Foundation reflect the division of the Cocoa programmatic interfaces into those classes that have some bearing on a graphical user interface and those that don’t. These two frameworks are essential to any Cocoa project whose end product is an application. Mac OS X also ships with several smaller frameworks that vend Cocoa programmatic interfaces, such as the Screen Saver and Address Book frameworks, and more will be added to the operating system over time. See “The Cocoa Frameworks” for further information.

How Cocoa Fits Into Mac OS X

Figure 1-1 shows a simplified diagram of the Mac OS X system architecture.


Figure 1-1  Mac OS X architecture—simplified perspective

Mac OS X architecture—simplified perspective

This diagram is simple for a purpose: to depict unambiguously to those unfamiliar with Mac OS X some of its major components and dependencies. But in its simplicity it omits important details and blurs others. These details fill in an important part of the picture showing how Cocoa fits into the rest of Mac OS X.

Figure 1-2 situates Cocoa more accurately in an architectural setting. This diagram shows Mac OS X as a series of software layers going from the foundation of Darwin to the various application environments; the intervening layers represent the system software contained in the two major umbrella frameworks, Core Services and Application Services. The diagram suggests that a component at one layer generally has dependencies on the layer beneath it.


Figure 1-2  Cocoa in the architecture of Mac OS X

Cocoa in the architecture of Mac OS X

In some ways, this diagram is similar to the previous diagram. For example, the system component that is largely responsible for rendering the Aqua user interface, Quartz (implemented in the Core Graphics framework), is part of the Application Services layer. And at the base of the architectural stack is Darwin; everything in Mac OS X, including Cocoa, ultimately depends on Darwin to function.

But if you look closer, at individual or groups of Cocoa classes and at the particular subframeworks of the umbrella frameworks, you begin to see where Cocoa either has specific dependencies on other parts of Mac OS X or where it exposes underlying technology with its interfaces. Figure 1-3 charts a few of these dependencies or exposures.

Note: Although Cocoa has dependencies on certain frameworks, it doesn’t just “sit” on top of them. In some cases, Cocoa is a peer to other frameworks (Carbon, for example) and can even do some things that those peer frameworks cannot do. Cocoa is not just an object-oriented layer over underlying technologies.


Figure 1-3  Zooming in on the Cocoa architecture—some major dependencies

Zooming in on the Cocoa architecture

Apple has carefully designed Cocoa so that some of its programmatic interfaces give access to the capabilities of underlying technologies that applications typically need. But if you require some capability that is not exposed through the programmatic interfaces of Cocoa, or if you need some finer control of what happens in your application, you may be able to use an underlying framework directly. (A prime example is Core Graphics; by calling its functions or those of OpenGL, your code can draw more complex and nuanced images than is possible with the Cocoa drawing methods.) Fortunately, using these lower-level frameworks is not a problem because the programmatic interfaces of most dependent frameworks are written in standard ANSI C, of which Objective-C language is a superset.

Note: The intent of this architectural overview is not to itemize every particular dependency or interface that Cocoa has on or to other parts of Mac OS X. Instead, it surveys the more interesting ones in order to give you a general idea of the architectural context of the framework.

The major underlying frameworks on which Cocoa depends or which it exposes through its classes and methods are Core Foundation, Carbon, Core Graphics (Quartz), Launch Services, and Print Core (the printing subsystem):

In addition, Cocoa uses the Carbon environment’s Text Encoding Converter service for some string-encoding conversions. Various Cocoa methods also expose parts of the I/O Kit framework for power management, the QuickDraw (QD) framework for QuickDraw drawing, the Apple event (AE) framework for Apple Event processing, and the ATS framework for font support.

Further Reading: Mac OS X Technology Overview gives an overview of the frameworks, services, technologies, and other components of Mac OS X. Apple Human Interface Guidelines specifies how the Aqua human interface should appear and behave.



< Previous PageNext Page >


© 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-12-20)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.