---

Software Development Overview

There are many ways to create an application in Mac OS X. There are also many types of software that you can create besides applications. The following sections introduce the types of software you can create in Mac OS X and when you might consider doing so.

In this section:

Applications
Frameworks
Plug-ins
Dashboard Widgets
Agent Applications
Screen Savers
Services
Preference Panes
Web Content
Mail Stationery
Command-Line Tools
Launch Items, Startup Items, and Daemons
Scripts
Scripting Additions for AppleScript
Kernel Extensions
Device Drivers

Applications

Applications are by far the predominant type of software created for Mac OS X, or for any platform. Mac OS X provides numerous environments for developing applications, each of which is suited for specific types of development. For information about these environments and the technologies you can use to build your applications, see “Application Technologies.”

Frameworks

A framework is a special type of bundle used to distribute shared resources, including library code, resource files, header files, and reference documentation. Frameworks offer a more flexible way to distribute shared code that you might otherwise put into a dynamic shared library. Whereas image files and localized strings for a dynamic shared library would normally be installed in a separate location from the library itself, in a framework they are integral to the framework bundle. Frameworks also have a version control mechanism that makes it possible to distribute multiple versions of a framework in the same framework bundle.

Apple uses frameworks to distribute the public interfaces of Mac OS X. You can use frameworks to distribute public code and interfaces created by your company. You can also use frameworks to develop private shared libraries that you can then embed in your applications.

You can develop frameworks using any programming language you choose; however, it is best to choose a language that makes it easy to update the framework later. Apple frameworks generally export programmatic interfaces in either ANSI C or Objective-C. Both of these languages have a well-defined export structure that makes it easy to maintain compatibility between different revisions of the framework. Although it is possible to use other languages when creating frameworks, you may run into binary compatibility problems later when you update your framework code.

For information on the structure and composition of frameworks, see Framework Programming Guide. That document also contains details on how to create public and private frameworks with Xcode.

Plug-ins

Plug-ins are the standard way to extend many applications and system behaviors. Plug-ins are bundles whose code is loaded dynamically into the runtime of an application. Because they are loaded dynamically, they can be added and removed by the user.

There are many opportunities for developing plug-ins for Mac OS X. Developers can create plug-ins for third-party applications or for Mac OS X itself. Some parts of Mac OS X define plug-in interfaces for extending the basic system behavior. The following sections list many of these opportunities for developers, although other software types may also use the plug-in model.

Address Book Action Plug-Ins

An Address Book action plug-in lets you populate the pop-up menus of the Address Book application with custom menu items that use Address Book data to trigger a specific event. For example, you could add an action to a phone number field to trigger the dialing of the number using a Bluetooth-enabled phone.

Address Book action plug-ins are best suited for developers who want to extend the behavior of the Address Book application to support third-party hardware or software. For more information on creating an Address Book action plug-in, see the documentation for the ABActionDelegate class.

Application Plug-Ins

Several applications, including iTunes, Final Cut Pro, and Final Cut Express, use plug-ins to extend the features available from the application. You can create plug-ins to implement new effects for these applications or for other applications that support a plug-in model. For information about developing plug-ins for Apple applications, visit the ADC website at http://developer.apple.com/.

Automator Plug-Ins

Introduced in Mac OS X version 10.4, Automator is a workflow-based application that lets users assemble complex scripts graphically using a palette of available actions. You can extend the default set of actions by creating Automator plug-ins to support new actions. Because they can be written in AppleScript or Objective-C, you can write plug-ins for your own application’s features or for the features of other scriptable applications.

If you are developing an application, you should think about providing Automator plug-ins for your application’s most common tasks. AppleScript is one of the easiest ways for you to create Automator plug-ins because it can take advantage of existing code in your application. If you are an Objective-C developer, you can also use that language to create plug-ins.

For information on how to write an Automator plug-in, see Automator Programming Guide.

Contextual Menu Plug-Ins

The Finder associates contextual menus with file-system items to give users a way to access frequently used commands quickly. Third-party developers can extend the list of commands found on these menus by defining their own contextual menu plug-ins. You might use this technique to make frequently used features available to users without requiring them to launch your application. For example, an archiving program might provide commands to compress a file or directory.

The process for creating a contextual menu plug-in is similar to that for creating a regular plug-in. You start by defining the code for registering and loading your plug-in, which might involve creating a factory object or explicitly specifying entry points. To implement the contextual menu behavior, you must then implement several callback functions defined by the Carbon Menu Manager for that purpose. Once complete, you install your plug-in in the Library/Contextual Menu Items directory at the appropriate level of the system, usually the local or user level.

For information on how to create a plug-in, see Plug-ins. For information on the Carbon Menu Manager functions you need to implement, see Menu Manager Reference.

Core Audio Plug-Ins

The Core Audio system supports plug-ins for manipulating audio streams during most processing stages. You can use plug-ins to generate, process, receive, or otherwise manipulate an audio stream. You can also create plug-ins to interact with new types of audio-related hardware devices.

For an introduction to the Core Audio environment, download the Core Audio SDK from http://developer.apple.com/sdk/ and read the documentation that comes with it. Information is also available in Reference Library > Audio > Core Audio.

Image Units

In Mac OS X version 10.4 and later, you can create image units for the Core Image and Core Video technologies. An image unit is a collection of filters packaged together in a single bundle. Each filter implements a specific manipulation for image data. For example, you could write a set of filters that perform different kinds of edge detection and package them as one image unit.

For more information about Core Image, see Core Image Programming Guide.

Input Method Components

An input method component is a code module that processes incoming data and returns an adjusted version of that data. A common example of an input method is an interface for typing Japanese or Chinese characters using multiple keystrokes. The input method processes the user keystrokes and returns the complex character that was intended. Other examples of input methods include spelling checkers and pen-based gesture recognition systems.

Input method components are implemented using the Carbon Component Manager. An input method component provides the connection between Mac OS X and any other programs your input method uses to process the input data. For example, you might use a background application to record the input keystrokes and compute the list of potential complex characters that those keystrokes can create.

In Mac OS X v10.5 and later, you can create input methods using the Input Method Kit (InputMethodKit.framework). For information on how to use this framework, see Input Method Kit Framework Reference. For information on how to create an input method in earlier versions of Mac OS X, see the BasicInputMethod sample code and the Component Manager Reference.

Interface Builder Plug-Ins

If you create any custom controls for your application, you can create an Interface Builder plug-in to make those controls available in the Interface Builder design environment. Creating plug-ins for your controls lets you go back and redesign your application’s user interface using your actual controls, as opposed to generic custom views. For controls that are used frequently in your application, being able to see and manipulate your controls directly can eliminate the need to build your application to see how your design looks.

In Mac OS X v10.5, you should include plug-ins for any of your custom controls inside the framework bundle that implements those controls. Bundling your plug-in with your framework is not required but does make it easier for users. When the user adds your framework to their Xcode project, Interface Builder automatically scans the framework and loads the corresponding plug-in if it is present. If you did not use a framework for the implementation of your controls, you must distribute the plug-in yourself and instruct users to load it using the Interface Builder preferences window.

For information on how to create plug-ins that support Interface Builder 3.0 and later, see Interface Builder Plug-In Programming Guide and Interface Builder Kit Framework Reference. For information on how to create plug-ins for earlier versions of Interface Builder, see the header files for Interface Builder framework (InterfaceBuilder.framework) or the examples in <Xcode>/Examples/Interface Builder.

Metadata Importers

In Mac OS X version 10.4 and later, you can create a metadata importer for your application’s file formats. Metadata importers are used by Spotlight to gather information about the user’s files and build a systemwide index. This index is then used for advanced searching based on more user-friendly information.

If your application defines a custom file format, you should always provide a metadata importer for that file format. If your application relies on commonly used file formats, such as JPEG, RTF, or PDF, the system provides a metadata importer for you.

For information on creating metadata importers, see Spotlight Importer Programming Guide.

QuickTime Components

A QuickTime component is a plug-in that provides services to QuickTime-savvy applications. The component architecture of QuickTime makes it possible to extend the support for new media formats, codecs, and hardware. Using this architecture, you can implement components for the following types of operations:

• Compressing/decompressing media data

• Importing/exporting media data

• Capturing media data

• Generating timing signals

• Controlling movie playback

• Implementing custom video effects, filters, and transitions

• Streaming custom media formats

For an overview of QuickTime components, see QuickTime Overview. For information on creating specific component types, see the subcategories in Reference Library > QuickTime.

Safari Plug-ins

Beginning with Mac OS X version 10.4, Safari supports a new plug-in model for tying in additional types of content to the web browser. This new model is based on an Objective-C interface and offers significant flexibility to plug-in developers. In particular, the new model lets plug-in developers take advantage of the Tiger API for modifying DOM objects in an HTML page. It also offers hooks so that JavaScript code can interact with the plug-in at runtime.

Safari plug-in support is implemented through the new WebPlugIn object and related objects defined in Web Kit. For information about how to use these objects, see WebKit Plug-In Programming Topics and WebKit Objective-C Framework Reference.

Dashboard Widgets

Introduced in Mac OS X version 10.4 and later, Dashboard provides a lightweight desktop layer for running widgets. Widgets are lightweight web applications that display information a user might use occasionally. You could write widgets to track stock quotes, view the current time, or access key features of a frequently used application. Widgets reside in the Dashboard layer, which is activated by the user and comes into the foreground in a manner similar to Exposé. Mac OS X comes with several standard widgets, including a calculator, clock, and iTunes controller.

Creating widgets is simpler than creating most applications because widgets are effectively HTML-based applications with optional JavaScript code to provide dynamic behavior. Dashboard uses the Web Kit to provide the environment for displaying the HTML and running the JavaScript code. Your widgets can take advantage of several extensions provided by that environment, including a way to render content using Quartz-like JavaScript functions. In Mac OS X v10.5 and later, you can create widgets using the Dashcode application, which is described in “Dashcode.”

For information on how to create widgets, see Dashboard Programming Topics.

Agent Applications

An agent is a special type of application designed to help the user in an unobtrusive manner. Agents typically run in the background, providing information as needed to the user or to another application. Agents can display panels occasionally or come to the foreground to interact with the user if necessary. User interactions should always be brief and have a specific goal, such as setting preferences or requesting a piece of needed information.

An agent may be launched by the user but is more likely to be launched by the system or another application. As a result, agents do not show up in the Dock or the Force Quit window. Agents also do not have a menu bar for choosing commands. User manipulation of an agent typically occurs through dialogs or contextual menus in the agent user interface. For example, the iChat application uses an agent to communicate with the chat server and notify the user of incoming chat requests. The Dock is another agent program that is launched by the system for the benefit of the user.

The way to create an agent application is to create a bundled application and include the LSUIElement key in its Info.plist file. The LSUIElement key notifies the Dock that it should treat the application as an agent when double-clicked by the user. For more information on using this key, see Runtime Configuration Guidelines.

Screen Savers

Screen savers are small programs that take over the screen after a certain period of idle activity. Screen savers provide entertainment and also prevent the screen image from being burned into the surface of a screen permanently. Mac OS X supports both slideshows and programmatically generated screen-saver content.

Slideshows

A slideshow is a simple type of screen saver that does not require any code to implement. To create a slideshow, you create a bundle with an extension of .slideSaver. Inside this bundle, you place a Resources directory containing the images you want to display in your slideshow. Your bundle should also include an information property list that specifies basic information about the bundle, such as its name, identifier string, and version.

Mac OS X includes several slideshow screen savers you can use as templates for creating your own. These screen savers are located in /System/Library/Screen Savers. You should put your own slideshows in either /Library/Screen Savers or in the ~/Library/Screen Savers directory of a user.

Programmatic Screen Savers

A programmatic screen saver is one that continuously generates content to appear on the screen. You can use this type of screen saver to create animations or to create a screen saver with user-configurable options. The bundle for a programmatic screen saver ends with the .saver extension.

You create programmatic screen savers using Cocoa and the Objective-C language. Specifically, you create a custom subclass of ScreenSaverView that provides the interface for displaying the screen saver content and options. The information property list of your bundle provides the system with the name of your custom subclass.

For information on creating programmatic screen savers, see Screen Saver Framework Reference.

Services

Services are not separate programs that you write; instead, they are features exported by your application for the benefit of other applications. Services let you share the resources and capabilities of your application with other applications in the system.

Services typically act on the currently selected data. Upon initiation of a service, the application that holds the selected data places it on the pasteboard. The application whose service was selected then takes the data, processes it, and puts the results (if any) back on the pasteboard for the original application to retrieve. For example, a user might select a folder in the Finder and choose a service that compresses the folder contents and replaces them with the compressed version. Services can represent one-way actions as well. For example, a service could take the currently selected text in a window and use it to create the content of a new email message.

For information on how to implement services in your Cocoa application, see System Services. For information on how to implement services in a Carbon application, see Setting Up Your Carbon Application to Use the Services Menu.

Preference Panes

Preference panes are used primarily to modify system preferences for the current user. Preference panes are implemented as plug-ins and installed in /Library/PreferencePanes on the user’s system. Application developers can also take advantage of these plug-ins to manage per-user application preferences; however, most applications manage preferences using the code provided by the application environment.

You might need to create preference panes if you create:

• Hardware devices that are user-configurable

• Systemwide utilities, such as virus protection programs, that require user configuration

If you are an application developer, you might want to reuse preference panes intended for the System Preferences application or use the same model to implement your application preferences.

Because the interfaces are based on Objective-C, you write preference panes primarily using Cocoa. For more information, see Preference Panes.

Web Content

Mac OS X supports a variety of techniques and technologies for creating web content. Dynamic websites and web services offer web developers a way to deliver their content quickly and easily.

In addition to “WebObjects” and “Dashboard Widgets,” the following sections list ways to deliver web content in Mac OS X. For more information about developing web content, see Getting Started with Internet and Web.

Dynamic Websites

Mac OS X provides support for creating and testing dynamic content in web pages. If you are developing CGI-based web applications, you can create websites using a variety of scripting technologies, including Perl and PHP. A complete list of scripting technologies is provided in “Scripts.” You can also create and deploy more complex web applications using JBoss, Tomcat, and WebObjects. To deploy your webpages, use the built-in Apache web server.

Safari, Apple’s web browser, provides standards-compliant support for viewing pages that incorporate numerous technologies, including HTML, XML, XHTML, DOM, CSS, Java, and JavaScript. You can also use Safari to test pages that contain multimedia content created for QuickTime, Flash, and Shockwave.

SOAP and XML-RPC

The Simple Object Access Protocol (SOAP) is an object-oriented protocol that defines a way for programs to communicate over a network. XML-RPC is a protocol for performing remote procedure calls between programs. In Mac OS X, you can create clients that use these protocols to gather information from web services across the Internet. To create these clients, you use technologies such as PHP, JavaScript, AppleScript, and Cocoa.

If you want to provide your own web services in Mac OS X, you can use WebObjects or implement the service using the scripting language of your choice. You then post your script code to a web server, give clients a URL, and publish the message format your script supports.

For information on how to create client programs using AppleScript, see XML-RPC and SOAP Programming Guide. For information on how to create web services, see WebObjects Web Services Programming Guide.

Sherlock Channels

In Mac OS X v10.4 and earlier, the Sherlock application was a host for Sherlock channels. A Sherlock channel is a developer-created module that combines web services with an Aqua interface to provide a unique way for users to find information. Sherlock channels combined related, but different, types of information in one window.

Sherlock channels are not supported in Mac OS X v10.5 and later.

Mail Stationery

The Mail application in Mac OS X v10.5 and later supports the creation of email messages using templates. Templates provide the user with prebuilt email messages that can be customized quickly before being sent. Because templates are HTML-based, they can incorporate images and advanced formatting to give the user’s email a much more stylish and sophisticated appearance.

Developers and web designers can create custom template packages for external or internal users. Each template consists of an HTML page, property list file, and images packaged together in a bundle, which is then stored in the Mail application’s stationery directory. The HTML page and images define the content of the email message and can include drop zones for custom user content. The property list file provides Mail with information about the template, such as its name, ID, and the name of its thumbnail image.

For information about how to create new stationery templates, see Mail Programming Topics.

Command-Line Tools

Command-line tools are simple programs that manipulate data using a text-based interface. These tools do not use windows, menus, or other user interface elements traditionally associated with applications. Instead, they run from the command-line environment of the Terminal application. Command-line tools require less explicit knowledge of the system to develop and because of that are often simpler to write than many other types of applications. However, command-line tools usually serve a more technically savvy crowd who are familiar with the conventions and syntax of the command-line interface.

Xcode supports the creation of command-line tools from several initial code bases. For example, you can create a simple and portable tool using standard C or C++ library calls, or a more Mac OS X–specific tool using frameworks such as Core Foundation, Core Services, or Cocoa Foundation.

Command-line tools are ideal for implementing simple programs quickly. You can use them to implement low-level system or administrative tools that do not need (or cannot have) a graphical user interface. For example, a system administrator might use command-line tools to gather status information from an Xserve system. You might also use them to test your program’s underlying code modules in a controlled environment.

Launch Items, Startup Items, and Daemons

Launch items and startup items are special programs that launch other programs or perform one-time operations during startup and login periods. Daemons are programs that run continuously and act as servers for processing client requests. You typically use launch items and startup items to launch daemons or perform periodic maintenance tasks, such as checking the hard drive for corrupted information. Launch items run under the launchd system process and are supported only in Mac OS X v10.4 and later. Startup items are also used to launch system and user-level processes but are deprecated in current versions of Mac OS X. They may be used to launch daemons and run scripts in Mac OS X v10.3.9 and earlier.

Launch items and startup items should not be confused with the login items found in the Accounts system preferences. Login items are typically agent applications that run within a given user’s session and can be configured by that user. Launch items and startup items are not user-configurable.

Few developers should ever need to create launch items or daemons. They are reserved for the special case where you need to guarantee the availability of a particular service. For example, Mac OS X provides a launch item to run the DNS daemon. Similarly, a virus-detection program might install a launch item to launch a daemon that monitors the system for virus-like activity. In both cases, the launch item would run its daemon in the root session, which provides services to all users of the system.

For more information about launch items, startup items, and daemons, see System Startup Programming Topics.

Scripts

A script is a set of text commands that are interpreted at runtime and turned into a sequence of actions. Most scripting languages provide high-level features that make it easy to implement complex workflows very quickly. Scripting languages are often very flexible, letting you call other programs and manipulate the data they return. Some scripting languages are also portable across platforms, so that you can use your scripts anywhere.

Table 6-1 lists many of the scripting languages supported by Mac OS X along with a description of the strengths of each language.

For introductory material on using the command line, see “Command Line Primer.”

Scripting Additions for AppleScript

A scripting addition is a way to deliver additional functionality for AppleScript scripts. It extends the basic AppleScript command set by adding systemwide support for new commands or data types. Developers who need features not available in the current command set can use scripting additions to implement those features and make them available to all programs. For example, one of the built-in scripting additions extends the basic file-handling commands to support the reading and writing of file contents from an AppleScript script.

For information on how to create a scripting addition, see Technical Note TN1164, “Native Scripting Additions.”

Kernel Extensions

Most developers have little need to create kernel extensions. Kernel extensions are code modules that load directly into the kernel process space and therefore bypass the protections offered by the Mac OS X core environment. The situations in which you might need a kernel extension are the following:

• Your code needs to handle a primary hardware interrupt.

• The client of your code is inside the kernel.

• A large number of applications require a resource your code provides. For example, you might implement a file-system stack using a kernel extension.

• Your code has special requirements or needs to access kernel interfaces that are not available in the user space.

Kernel extensions are typically used to implement new network stacks or file systems. You would not use kernel extensions to communicate with external devices such as digital cameras or printers. (For information on communicating with external devices, see “Device Drivers.”)

For information about writing kernel extensions, see Kernel Programming Guide.

Device Drivers

Device drivers are a special type of kernel extension that enable Mac OS X to communicate with all manner of hardware devices, including mice, keyboards, and FireWire drives. Device drivers communicate hardware status to the system and facilitate the transfer of device-specific data to and from the hardware. Mac OS X provides default drivers for many types of devices, but these may not meet the needs of all developers.

Although developers of mice and keyboards may be able to use the standard drivers, many other developers require custom drivers. Developers of hardware such as scanners, printers, AGP cards, and PCI cards typically have to create custom drivers for their devices. These devices require more sophisticated data handling than is usually needed for mice and keyboards. Hardware developers also tend to differentiate their hardware by adding custom features and behavior, which makes it difficult for Apple to provide generic drivers to handle all devices.

Apple provides code you can use as the basis for your custom drivers. The I/O Kit provides an object-oriented framework for developing device drivers using C++. For information on developing device drivers, see I/O Kit Fundamentals.

---