When you run a command tool you invoke its options in the command you enter. Those options are supplied each time you run the tool, and don’t persist. Apps are different, in having a GUI that usually offers the user options, and in relying on information that persists until you next run that app. Those are its preferences, settings or defaults, depending on how you look at them.
In traditional Unix, persistent preferences may be implemented as configurations, defined in a plain text config file. In classic Mac OS window settings and a great deal more were saved as resources, in the resource fork of the app or its documents. This resulted in one neat feature that’s seldom seen in macOS today, saving a document’s window settings to its file, so they will be reused the next time that document is opened.
One of the innovations in NeXTSTEP was the human-readable property list used to store serialised objects such as preferences. These consist of designated variables used by the app that are converted into a representation that can be expressed in text. For example, if an app lets the user decide whether to use US or metric units of measurement, that could be stored in memory as a Boolean variable, true or false, and serialised as the word true or false in a property list used to store the app’s preferences.
Contents
Accommodating all the preferences needed by an app usually requires a dictionary of those serialised values, each given a key for identification, and having an explicit or implicit data type. Thus, that user option might become
key: metricUnits
value: true, a Boolean with two possible values.
Mac OS X replaced the old NeXTSTEP format for property lists with two formatting schemes, XML and JSON, with XML the standard for app preferences. This is a file containing dictionaries of key-value pairs representing the serialised data:
<dict>
<key>metricUnits</key>
<true/>
<key>filePrefix</key>
<string>MyFile</string>
</dict>
Initially, all property lists were stored as plain text, but that’s woefully inefficient, so between Mac OS X 10.2 and 10.4 a more compact binary format replaced that, and remains the standard today, as implemented in the UserDefaults API.
cfprefsd
Although developers can handle their app’s defaults/preferences with their own code if they wish, macOS provides the defaults server cfprefsd, and that convenient API that is used by the great majority of apps. Under that, early in an app’s initialisation cfprefsd automatically opens that app’s preferences, then loads its key-value pairs to make them available to the app as it’s setting itself up.
cfprefsd is transparent to the developer, whose code simply accesses key-value pairs as they are required. cfprefsd may opt to keep the whole preference file in memory, and manage it however it sees fit. Thus the property list’s contents on disk may not represent those held in memory for the app, and any changes to the property list file may be overwritten when cfprefsd saves changed values from memory.
For a simple app, working with cfprefsd should also be straightforward. The app’s preference property list is opened by cfprefsd shortly after the app is launched, and the app’s code works through UserDefaults to make any changes to key-value pairs while the app is running. As the app is shut down, cfprefsd updates the preference file, and the user is once again free to change or delete that property list as they wish. However, there’s ample scope for that to become more complicated, or to misuse it.
Problems
Many apps today aren’t that simple in their structure, and use helper apps and other executable code that may still be running with access to the app’s preferences even though the main app is shut down. When the user thinks it’s safe to modify the contents of that property list, it may still be in the care of cfprefsd. The preferred approach then is to use the defaults command tool, which should work with cfprefsd rather than competing with it.
In the past, UserDefaults and cfprefsd weren’t always reliable, and some developers worked around their problems with a combination of the official API and performing their own direct manipulation of preference files. Those dangerous practices should have died out now.
Because an app’s preferences are accessed early as it’s being launched, any bugs or incompatibilities in those key-value pairs can have fatal effects before the app is fully open. For example, if a new version of an app reuses an existing preference key with a different data type, if it reads an old version of its preferences, that will throw an error. If that’s not handled well, that can cause the new version of the app to crash when launched.
Fortunately, all apps have to be able to create their own preference file for when they’re first run. There’s scope for further bugs there, when the file created isn’t updated to work with changed key-value pairs in a newer version of the app. That may result in an app that crashes when launched even when there’s no existing preference file saved, a problem for which there’s no workaround.
Finally, many apps have multiple preference files. If they run in a sandbox, the copy they use normally is in the Data/Library/Preferences folder in their container, in ~/Library/Containers. But they may also have a different property list in ~/Library/Preferences, and sometimes a master copy in /Library/Preferences as well. While I’m sure cfprefsd knows which to access, you may need to check by inspecting each file’s timestamps.
UserDefaults have improved significantly with SwiftUI, further integrating persistent storage of preferences. Although they can still trip up the unwary, provided you understand how they work and don’t try fighting the system, they should seldom cause substantial problems.
For much of the last 25 years, macOS has had ill-defined and pervasive problems that have often been attributed to incorrect permissions in various parts of the file system. As a result, one of the common panaceas has been to repair those permissions, using procedures that have changed over those years.
Repair disk permissions
Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, these problems generally resulted from files within the system acquiring incorrect permissions. To address this, Disk Utility had a feature to check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in those older versions.
Although primarily intended to deliver better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files that were protected by SIP.
Reset user permissions
When macOS 10.12 Sierra was released, a different problem appeared, in which permissions were apparently set incorrectly not in system files generally, but in the user’s Home folder, specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that the cfprefsd service took on management of those preference files, and just one year after repairing disk permissions ceased.
At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:
changes to preference settings, particularly those for System Preferences, do not ‘stick’;
changes made to the Dock do not ‘stick’;
you are asked to authenticate when trying to move or alter some folders in your Home folder;
when trying to save, you are told that the file is locked, or that you don’t have permission;
Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
alerts appear warning that the startup disk has no more space available for app memory;
Safari or SafariDAVClient use large amounts of resources (memory);
the Mac runs very slowly;
iTunes cannot sync a device;
there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.
Most if not all of those could have been attributable to problems resulting from bugs in cfprefsd.
Repair Home permissions
Five years ago, Apple changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, when Big Sur was in beta in June 2020, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.
Running repairHomePermissions from Terminal in Recovery launches a GUI app to repair permissions on a selected Home folder on the Data volume. However, I strongly recommend that you don’t try using this, as you’ll end up with the user being locked out of every folder in their Home folder. I have tried it three times in virtual machines, and each time I have had to discard that VM because of the problems it caused.
Delete a corrupt preference file
Regardless of those, there are still occasions when preference files can cause problems. These typically occur when a corrupt or damaged preference file causes an app or other code to crash, usually when it’s being launched. Although these are now far less common, and the SSV ensures that system files can’t become corrupted as they did in the days before SIP, it’s useful to know how to deal with them.
On most occasions, a preference file can be deleted in the normal way, either in Finder or Terminal, and it won’t return until that app is run again, as it won’t currently be managed by cfprefsd. The alternative is to use defaults: defaults delete com.mycompany.appname
deletes all the key-value pairs within the preference file for com.mycompany.appname, leaving just the empty property list. This has the advantage that it can be used when cfprefsd is managing that file’s contents, so should always be reliable. Provided the app handles preferences correctly using UserDefaults, it should be able to repopulate the empty property list the next time that app is launched.
One significant caution is when working with files inside ~/Library/Containers,~/Library/Group Containers,~/Library/Daemon Containers and similar managed folders. Because these form sandboxes, macOS manages them differently and tampering with their contents is likely to have unintended effects, so is best avoided, although the defaults command should still be safe.
Summary
Repairing disk permissions on system files ceased with SIP in El Capitan.
Repairing permissions on Home folder preference files is no longer recommended by Apple, since Big Sur.
Safe and robust deletion of contents of a preference file can be performed using defaults delete.
Don’t tamper with files inside ~/Library/Containers, ~/Library/Group Containers and similar folders.
Never be tempted to run repairHomePermissions in Recovery mode.
Login
