A list of preference settings for a given domain intersection is internally represented by a special type of data structure which is used throughout all parts of macOS, a so-called property list. To be exact, the settings of the domain are represented by a dictionary, where the property keys of the domain settings become the dictionary keys, and the values for each setting become the respective dictionary values. For this reason, it is only natural that macOS also uses its standard file format, the so-called property list files with the name extension .plist to save its copies of the preference domains internally. This way, the domain intersections contained in the preferences database can be stored into persistent files. The preference settings will keep their values and survive, even if the applications or the operating system are shut down.
macOS happens to use property list files to save the different domain intersections of the preference database. In theory, it could use any other file format to do so, and predecessors versions of macOS (e.g. NeXT OPENSTEP for Mach) in fact used other file types. As mentioned before, applications don’t need to care how macOS handles this, because they never access preference files directly. When an application asks for the value of a specified preference setting, macOS makes sure to search and retrieve the value on behalf of the application. Although the application’s process wil open some of the plist files associated with the preference setting in question at that moment, the application doesn’t really “know” this. macOS lets the process indirectly call some of its internal features which perform the actual operations.
Depending on what domain intersection takes effect, macOS will automatically generate the correct file name and folder name to search for available preference settings. For example, system-wide (all user) settings for the current computer will be stored in the folder /Library/Preferences with the application domain name as file name. Settings for the current user for all computers will be stored in the Library/Preferences subfolder of the user’s private home folder, also with the application domain name taken as file name.
This means the persistent copy of the preferences database is stored into several hundred property list files, distributed among specific Library/Preferences folders. Remember that a preference domain is represented by a special type of property list, namely a list which has a dictionary with property keys at its top level. This means not all valid property list files will be valid preference files. Preference files are a special case of property list files and underlie certain restrictions. macOS uses property list files for many other purposes as well. Property list files containing persistent parts of the distributed preference database are just a special utilization where a specific class of plist files plays a role.
NOTE: When editing a property list file directly, PrefEdit will display if that file has the correct structure to be used as part of the preferences database or not. You can use PrefEdit to edit any property list file, not only preference files.
Applications use preference settings very often. For example, when you work with an application which opens a window containing some data arranged in a table, the application typically looks up
and perhaps many other settings to silently let the application behave in the way you are preferring, reusing the remembered settings from the last time you used that window. This means there can be dozens of access operations to the preference database per minute. To handle this as efficiently as possible, each application keeps its own view of all domains it works with in its private memory space. Changes to the preference database will at first affect this in-memory copy only. As soon as macOS has enough time to handle this in the background, or when the application explicitly requests to save its preference settings to persistent storage, macOS will save the settings to all affected property list files.
This efficient approach has the following consequences:
Note that neither item (1), nor item (2) will affect applications under normal circumstances. If an application works with its own preference settings only, it does not matter if the in-memory database was synchronized with persistent storage yet. As mentioned before, the application does not need to know anything about persistent storage. Item (2) only becomes important if an application tries to re-read preference settings not owned by itself, but settings which are part of a different domain that had been modified.
However, both items are important for PrefEdit because PrefEdit is editing preference settings which it doesn’t own itself, but which come from other domains.
For this reason you should always keep in mind that the preference settings you see in PrefEdit may not be fully identical to the state of the database currently seen by other running applications. PrefEdit will however track all modifications correctly as soon as they take place in the preference files.
Whenever you like to change the preference setting of an application, it is recommended to quit the affected application before. On the one hand, this will make sure that the affected application will take all modifications into account you may have done, on the other hand, this will prevent you and the affected program to work on the same file at the same time, which could lead to conflicts otherwise. Note that the Dock cannot be used to check whether an application is running or not. You’ll have to use a process viewer like Activity Monitor (from the Utilities folder of macOS) to verify whether an application is actually not active.
macOS currently knows three different ways a property list can be physically represented in a file:
The last file type is considered deprecated. It should not be used to create new plist files. For this reason, macOS and PrefEdit can read but will never write such files.
Today’s property list files should usually have names with the file name extension .plist, no matter what format variant was used to store the list. However, PrefEdit will also accept files with any other name extensions. The application keeps customized file name extensions when saving changes.
The current property list file format variations can be used fully interchangeably when storing preference settings and most other property lists. Mac OS X preferred XML lists to store preference settings in operating system versions prior to Tiger (10.4). As of Mac OS X 10.4 and later, the system has begun to store preference files in binary format, which saves storage space. As mentioned before, applications don’t know anything about the plist files, so it doesn’t matter which file format variation the current version of macOS is using.
If property list files are used for other purposes, it will depend on the specific case which file format is permitted. Please note that macOS won’t accept property list files in binary format for some use cases. For certain purposes usually documented by Apple in the reference manuals, XML has to be used.