---

The Mac OS X Environment

This chapter covers relevant features of Mac OS X that can influence the design of your software. These features are not always associated with a single technology or developer type but sometimes apply to development in general. You should be familiar with these guidelines before developing your software.

In this section:

The Always-On Environment
Displays
The Dock
The Finder
File Formats and Filename Extensions
Internationalization
Multiple User Issues
Resource Management
Threads

The Always-On Environment

As the center of the user’s digital hub, Mac OS X is designed to be always ready to use. Because of energy saving systems, it’s common for a user to leave a computer on most of the time. To allow for the fact that a computer may be on for hours, days, weeks, or even months at a time, you should consider the following guidelines:

• Avoid relying on a restart to get rid of cached or temporary files that may use up disk space. Be prepared to remove these files yourself when they are no longer needed.

• Avoid relying on startup or login items to initiate user-level processes. If the user quits a process initiated only at boot time, that process will be unavailable until the machine restarts.

• Avoid requiring users to reboot as a part of an installation or software update unless absolutely necessary. Your application is probably not the only one they have open, so a restart can come as a rude interruption.

Displays

Avoid making assumptions about display size. Mac OS X can run on systems with a screen size as small as 800 x 600, but a user may have multiple high-resolution displays. Unless you know that your users will be using a specific display size, it is best to optimize your applications for display at 1024 x 768 pixels.

Be aware that users may have the ability to rotate their displays, so you should also avoid making assumptions about the aspect ratio. Display rotation reverses the aspect ratio of the screen. For example, if a user's display is set to a screen resolution of 800 x 600 (an aspect ratio of 1.33:1), after rotation the screen resolution is 600 x 800 (an aspect ratio of .75:1).

An application can get notified of some types of screen-update events by registering for a callback, such as CGDisplayReconfigurationCallBack. For more information on this and other callbacks, see Quartz Display Services Reference.

The Dock

The Dock is more than just a tool for users of Mac OS X. Developers need to be aware of the Dock and account for its presence in their applications.

When creating new windows or resizing existing windows, make sure you take the Dock position into account. New windows should not overlap the boundaries of the Dock. Similarly, you should prevent users from moving or resizing windows so that they are behind the Dock. (Carbon developers can use the GetAvailableWindowPositioningBounds function and Cocoa developers can use the methods of NSScreen to get the screen area without the Dock or menu bar.)

Conveying Information in the Dock

Developers may also find some features of the Dock useful for conveying information.

• Use badging to convey status information in an unobtrusive manner. Badging is the process of superimposing a small image on an application’s Dock tile icon. For example, Mail uses a badge to show the number of unread messages. This is a good example of providing appropriate feedback and communication. For more information on this principle of user interface design, see “Feedback and Communication.”

• Use the Notification Manager to convey more serious information, such as error conditions. Notifications cause your Dock tile icon to bounce. Make sure you disable this effect once the user has addressed the problem. (Note that error-related classes in a Cocoa application initiate Dock notifications automatically.)

Clicking in the Dock

Clicking an application icon in the Dock should always result in a window becoming active.

• If the application is not open, a new window should open. In a document-based application, the application should open a new, untitled window. In an application that is not document-based, the main application window should open.

• When a user clicks an open application’s icon in the Dock, the application becomes active and all open unminimized windows are brought to the front; minimized document windows remain in the Dock. If there are no unminimized windows when the user clicks the Dock icon, the last minimized window should be expanded and made active. If no windows are open, the application should open a new window—a new untitled window for document-based applications, otherwise the main application window.

Control-clicking an application icon in the Dock displays a menu that allows users to perform tasks such as quitting the application, hiding it, or showing its location in the file system. (Users can also press the application icon to get this menu.) You can modify this menu to make features of your application available from your Dock tile. See “Dock Menus” for more information on Dock menus.

The Finder

Here are some tips to help your application integrate well with the Finder:

• Make sure your application bundle has a .app extension. The Finder looks for this extension and treats your application appropriately when it finds it. The Finder also shows or hides this extension, depending on the state of the "Show all file extensions" preference in the Advanced pane of Finder preferences.

• Package CFM applications in a bundle. Even if you develop using the CFM runtime, you can still take advantage of the bundle mechanism in Mac OS X.

• Use an information property list to communicate information to the Finder. The information property list is the standard place to store information about your application and document types. For information on what to put in this file, see Runtime Configuration Guidelines.

• When saving files of your own document types, be sure to give them appropriate filename extensions to ensure platform interoperability and to support the Mac OS X user experience. You can also set a file type and optionally a creator type for a file. The file and creator type codes are not strictly necessary, but they do ensure interoperability with applications in the Classic environment. See File System Overview for more information about filename extensions, file types, and creator types.

• Avoid changing the creator type of existing documents. The creator type implies a distinct sense of ownership over a file. Your application can assign a creator type for files it creates but it is not appropriate to change creator types for documents created by other applications without the user's explicit consent. The user can still associate files with a specific application through the Info window.

File Formats and Filename Extensions

Whenever possible, include support for industry-standard file formats in your documents. Supporting standard file formats makes it easier to exchange data between your application and other applications. Users might also be more inclined to use your application if they know they can get their data into and out of it easily.

When saving user-configurable data, make sure you store it in a plain-text file that the user can modify. Mac OS X applications traditionally store configuration data using XML. You can write out XML data using the preferences system and the XML support found in Core Foundation and Cocoa. For information about user preferences, see Runtime Configuration Guidelines.

Many platforms rely on the existence of filename extensions to identify the type of a file. Although many longtime Mac OS X developers may decry their use, filename extensions make it easier for users to exchange files with users of those other platforms. Applications that save documents should be sure to include a filename extension appropriate to the contents of the document. At the same time, however, applications should take care to respect the user's filename extension preferences when displaying the names of files and documents.

For more information and guidelines about supporting filename extensions, see File System Overview.

Internationalization

The Mac OS X application bundling scheme is designed to support localized strings, images, nib files, and other resources. However, there is more to designing an application for use in different markets than just including the right translated strings. “Worldwide Compatibility” provides some general design considerations for building internationalization into your application.

At a minimum, your internationalization checklist should include the following items:

• Implement your program as a bundle so that you can take advantage of the built-in internationalization support for bundles.

• Support Unicode text. Mac OS X provides full support for Unicode, and so should your application.

• Modify your code to get user-visible strings from .strings files. Use Core Foundation and Cocoa interfaces to load strings from resource files in your bundle.

• Use nib files to store your user interface data.

For further guidelines and information about how to internationalize your applications, see Internationalization Programming Topics.

Multiple User Issues

Remember that Mac OS X is a multiple-user system. Not only does the system support multiple user accounts, it supports multiple users sharing the same computer simultaneously. This feature employs a technique known as fast user switching, in which users trade use of the computer without logging out. With multiple users accessing the computer, conflicts can arise if applications are not careful about how they use shared resources. Shared memory, cache files, semaphores, and named pipes must be carefully labeled to prevent corruption by users running the same application in different sessions. Applications cannot assume that they have exclusive access to any system resources, such as a CD or DVD drive.

When considering access by multiple users, there are some specific things to keep in mind for your program design:

• Named resources that might potentially be accessible to an application from multiple user sessions should incorporate the session ID into the name of the resource. This applies to cache files, shared memory, semaphores, and named pipes, among others.

• Not all users have the same privileges. For example, only administrator users can write files in /Applications. Some users may be working under limited privileges and have limited access to some parts of the system. In particular, they may not be able to do the following:

  • Access all panes in System Preferences

  • Modify the Dock

  • Change their password

  • Burn DVDs and CDs

  • Open certain applications

• Users on a computer can include both local and network users, so do not assume a user’s home directory is on a local volume. You may be accessing a network volume instead.

The document Multiple User Environments describes issues that arise from the existence of multiple users on a system. It also covers programmatic techniques for identifying users and protecting your application data from external corruption.

Resource Management

Application bundles simplify installation and are easy for the user to move around in the Finder. Application bundles are the preferred mechanism for software distribution. Here are some tips to help you manage your application bundle’s resource files:

• Include all required resources inside your application bundle. Your application bundle should always have everything it needs in order to run.

• Include only the specific subset of files that require localization in your application bundle’s language-specific resource directories. If a resource does not require localization, there is no need to create extra copies of it. The bundle-loading code checks for global resources as well as localized resources and returns the one that is most appropriate.

• Use an installer to place optional resources in the appropriate Library subdirectory of the user’s system. Optional resources are things like document templates or other resources that are useful to an application but not required for it to launch. Most application-related files should go in an application-specific subdirectory of ~/Library/Application Support or /Library/Application Support. See File System Overview for information on where to install files.

• Avoid storing data in the resource fork of your application executable. Resource forks are not an appropriate way to store application-related resources. Instead, store your resources as individual files inside your application bundle. See Bundle Programming Guide for more information on where resources belong in the bundle structure.

Threads

As you design your application, think about the operations that could be performed in parallel. Multithreading your application improves the responsiveness of your user interface by moving long calculations into separate threads and away from your main event loop. Multithreading can also improve the speed of performing some tasks, especially on multiprocessor systems. Of course, threading also requires great care during implementation to ensure that shared data structures are not corrupted by different threads. For more information on threading technologies, see Threading Programming Guide.

---