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.
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”.
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.
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:
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
won’t be used in macOS versions published so far.
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:
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.
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:
Each setting must contain a value of one of the following data types:
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. In selected cases however, the vendor of an application may have given additional hints by using a preference manifest.