The Preference System of macOS

macOS uses sophisticated technology to handle preference settings for all applications natively developed for this operating system. The programs don’t need to care about reading or saving their preference settings to files. This is completely handled by macOS in an automatic and transparent way. Applications even don’t even “know” how or where their settings are being stored.

When an application likes to define a preference setting for a user, e.g. the default position on screen where the user has placed the main window of a certain application, it just sends a request to macOS “I am application A. Store the value B of the setting named C for the user D”. The operating system automatically ensures that it will remember this setting later when application A (run by user D) should ask for it, no matter if the application or the computer had been shut down in the meantime and had been restarted later.

So when the application likes to position its main window to the very same location the window has been placed the last time the user had closed that window, the application will send a request to macOS “I am application A. Give me the preferred value for the setting named C for user D”. macOS will then return the previously stored value (B) to the application and the program can use it to position the window. That way, the application has basically “remembered” the settings preferred by the user, but it doesn’t need to know how macOS did this trick.

Preference domains

Every application running on the graphical user interface of macOS must have a unique identification. The preferences subsystem uses this identification to remember “this list of settings belongs to the application with that identification”. According to Apple’s software design guidelines, the identification names must be built based on a hierarchical list of descriptive names, written from left to right in top-down order, separated by dots. The first part of the hierarchy must be the Internet domain name (DNS name) of the application’s vendor, so two different software companies can never create the same identification for a program, even if their products should happen to have identical names.

Example: The unique identifier for Apple’s web browser Safari is com.apple.Safari, because it is published by the company with the Internet domain name apple.com and Safari is the descriptive name to identify this program in Apple’s software portfolio. Note how com.apple.Safari is written in top-down order, with the most important part at the beginning, while Internet domain names like www.apple.com are written in reverse order, with the most significant part at the end.

When working with the preferences subsystem, the application identification becomes the name of the set of preference settings for this application and is called preference domain name, or just domain name in that context. Depending on the type of file system where macOS internally stores parts of the preferences database, the names may or may not be handled in a case-sensitive way. For this reason, preference domain names should always be seen as being case-sensitive, so com.apple.Finder and com.apple.finder represent two different preference domains.

Software companies are free to use more than one descriptive name components to identify a particular application or aspect of an application. Examples for this are com.apple.airport.airportutility and com.apple.airport.clientmonitor to identify two different applications which are both part of the subject area “Airport”.

The domain applicable to all applications

macOS uses a special domain to identify settings which should apply to all applications started by the same user. For example, the user default for the preferred page size for print outputs should have the same value, regardless which program is being used. A user can define different page layouts in different applications if she explicitly chooses to do so, but there should be one single default being applied to all applications before the user has made such a distinction. This domain is called NSGlobalDomain.

Other domain aspects for preference settings

So far, we have mainly focused on the aspect “to which application does a certain preference setting belong”. But there are other kinds of areas or territories where preferences apply or should not apply. Each user of a computer should have the choice to use his or her own preferred settings. If user A likes to have a red desktop background, he should be able to set it, completely independent of user B who prefers a blue background when working with macOS. This means the preference system also has to know the concept of per-user preference domains.

In professional networks, this should become more complex: If user A is a university student who works on a large campus network, his preference for a red desktop background should become active automatically for each and every macOS computer in the network. So no matter if user A logs into a Mac in building P, or uses a different Mac in a lab of building Q, his preference settings and user profile should automatically “roam” with him. macOS will automatically take care of that, too, if the network is configured to use central home folders for all users. Other settings however, e.g. the preferred output quality for a certain printer, should be computer-specific. Perhaps one computer has a black-and-white printer, while another system uses a color printer with very different printing settings. These particular settings should not move between computers, although macOS should still remember them.

This means there are three different aspects of preference domains in practice:

• the application: settings which apply to a specific application or to all applications
• the user: settings which apply to a specific user or to all users of a computer
• the computer: settings which apply to a specific computer or to all computers of a network

Whenever macOS stores or retrieves a preference setting with a given name, it will always take into account to which domain intersection of application, user, and computer area a certain setting applies. This decision is based on the current user session. There can be eight different combinations of aspects as shown in the picture below.

Typically, macOS will assume the domain intersection “specific application — current user — all computers” when setting a preference value and nothing else has been specified.

The pair “all users — all computers” would require a central network repository where macOS could store preference settings for all roaming users and all computers in a network. Although macOS is basically prepared to do so, Apple has currently not implemented this combination. This means the domain intersections

• all applications — all users — all computers and
• specific application — all users — all computers

won’t be used in macOS versions published so far.

The domain search path for preference settings

When an application is asking macOS to retrieve a certain preference setting, the current user session is taken as basis for the decision which setting in which domain intersection takes effect. When a particular setting is available in multiple domain intersections, settings with higher priority should override settings with lower priority.

For example, if a user has defined her individual preference for print output quality in a certain program running on a certain computer, this setting should take precedence over the more general areas. It should automatically override a setting with the same name which might have been defined for all computers and/or all users. macOS uses priorities based on the following list to decide which preference settings takes effect:

1. settings for the current application — specific to the current user — specific to the current computer
2. settings for the current application — specific to the current user — all computers
3. settings for all applications — specific to the current user — specific to the current computer
4. settings for all applications — specific to the current user — all computers
5. settings for the current application — all users — specific to the current computer
6. settings for the current application — all users — all computers
7. settings for all applications — all users — specific to the current computer
8. settings for all applications — all users — all computers
9. built-in fallback settings

This list is taken as a search path for preference settings, traversed in top-down order. The first entry in the list for which the setting in question is defined, will “win” and take effect. So this entry will override all entries of the same name which may come later in the list.

PrefEdit can evaluate and visualize this complex search procedure when desired. You don’t need to learn the priority list, PrefEdit will display automatically which preference settings take effect for a certain application you are using.

What is in a setting?

We have learned that a preference domain contains a list of named preference settings. But what exactly does the term “setting” mean in this context? A preference setting in macOS is characterized by three components:

• The name of the setting: This name uniquely identifies the meaning of the setting within its domain. Because the name is used to store a certain property which should be remembered by the application, this name is also called property key.
• The value of the setting: It represents the current content of the named property, the actual payload data stored in the preferences database.
• The type of the value: macOS needs to know how to interpret the value. The possible types are discussed below.

Each setting must contain a value of one of the following data types:

• Boolean: a logical “yes” or “no” value
• String: a sequence of characters, representing some text
• Integer Number: a numeric value without decimal places
• Real Number: a numeric value which can have decimal places
• Date / Time: specification of a certain date and time, stored in a way independent of the current time zone or calendar system
• Binary Data: an arbitrary sequence of bytes which can only be interpreted by the application the setting belongs to. The data cannot be interpreted by macOS or PrefEdit, so it is shown as a raw sequence of hexadecimal numbers.
• Array: an ordered sequence of elements of any of the valid types. The order is usually represented by numbers called indexes. The first element has the index 0, the following items have the indexes 1, 2, 3, and so on.
• Dictionary: an unordered sequence of key/value pairs. A dictionary basically maps some elements (the keys) to other ones (the values). Keys and values are elements of any of the valid types, with the restriction that keys must be unique and of the same type per dictionary, each key holding a single (scalar) item.

Note that it is possible to nest dictionaries and arrays in any order and unlimited depths. A setting could contain an array of arrays of dictionaries of strings, for example, or a dictionary of arrays of numbers. Arrays and dictionaries are also allowed to contain items of different types, for example an array with an integer number at index 0, a string at position 1 and a Boolean at position 2.

It is completely up to the different applications to interpret the property keys, types and values of the settings. Neither macOS nor PrefEdit can know how an application is using a given setting.