Each User Preference Belongs to a Domain and a User

When you write a user preference to the user defaults system, it puts it in a domain that reflects the scope of the preference. For example, there’s a domain for application-specific defaults and another for defaults that apply to all applications (NSGlobalDomain). Although preferences in these domains are persistent across application launches, preferences in some domains exist only while an application is running.

User preferences are also associated with a particular user. Thus you can look at a preference “record” in the user-defaults repository as being structured in three levels: first user, then domain (usually global or per-application), and then key-value pairs within each domain. The root object for the combined preferences of a user is a dictionary in which, for application-specific domains, the keys are the bundle identifiers of applications.

Preferences are written to files named with the application’s bundle identifier and having an extension of plist. In iOS the files are located in a special location of an application’s sandbox; in OS X preference files are located in Library/Preferences in a user’s home directory.

Your Application Must Present a User Interface for the Selection of Preferences

Before your application can store user-configurable preferences in the user defaults system, it must present a user interface for selecting those preferences. On OS X, this entails designing a preference panel that a user displays by choosing Preferences from the application menu. The application is responsible for writing the settings that the user supplies to the user defaults system.

In iOS, the approach is more nuanced. Applications have two choices for displaying user preferences.

• In a separate preferences view. Applications that have only a few options or options that are likely to change frequently—for example, a sound-muting control for a game—would present those options in view that presents controls for changing option values.

• In the system-provided Settings application. Preference options that users are likely to set once and rarely change thereafter should appear instead in the Settings application provided by the operating system.

  To integrate your application preferences into the Settings application, you must include a specially formatted settings bundle in the top-level directory of your application bundle. This settings bundle provides information about your application preferences to the Settings application, which is then responsible for displaying those preferences and updating the user-defaults system with any user-supplied values.

At runtime, your application retrieves preferences in the user defaults system using the NSUserDefaults or CFPreference APIs.

Facilities in OS X for User Defaults

OS X gives you two facilities to help you integrate an application’s user preferences with the user defaults system:

• Cocoa bindings. NSUserDefaultsController objects are controller objects that allow you to bind user-interface elements of your application to key-value pairs in the user defaults system.

• Command-line access. In OS X you can run the defaults command-line program as a useful debugging tool. It allows you to read and write entries in the user defaults system, and it also lets you search for specific preference entries, rename them, and delete them.