I wrote a tool that sniffs changes to macOS defaults as they change and autogenerates the
defaults incantation to set those preferences. I have a post in the wings about this. For that to be useful, though, I need to establish a bit more groundwork about defaults. In particular, the various locations where the backing plist files can exist. Most are intuitive, but many are not.
Here’s a rundown of places where
defaults plist files can exist if they’re not in
A default may be “host-specific,” meaning it only applies to a specific machine. I believe the idea is to allow per-machine configuration in situations where a user’s preferences are loaded from a synchronized folder or network share (such as an LDAP directory or NFS home directory). In this case the preference will be under a UUID that is specific to the given machine. Looking under
~/Library/Preferences/ByHost, you should see a number of plist files each with a UUID in its name. Using
defaults to apply a setting to the local machine, use the
-currentHost option. Further, the UUID in the plist file name is omitted from the defaults domain. The screen saver preference is an example. A change to:
…could be accomplished with:
$ defaults -currentHost write 'com.apple.screensaver' 'moduleDict' -dict-add 'path' '<string>/System/Library/Frameworks/ScreenSaver.framework/Resources/Computer Name.saver</string>' $ defaults -currentHost write 'com.apple.screensaver' 'moduleDict' -dict-add 'moduleName' '<string>Computer Name</string>'
When the preference domain is the
NSGlobalDomain, the default isn’t stored in a domain specific to an application or preference pane. These defaults are visible to all applications, regardless of their own preference domains. Locations where global preferences may be recorded include:
If it isn’t clear where a preference is being recorded, try one of these locations.
Multiple plist files
In some cases, a single setting in a user interface may actually manifest across multiple plist files. An example of this is the Trackpad preference pane.
The “Tap to click” setting is stored across the following three domains:
On a MacBook, settings in all three of these domains are required to configure tap-to-click.
Apps that are containerized (such as any app from the Mac App Store) can only write files inside their own containers. App containers are located in
~/Library/Containers. For example, TextEdit.app’s container is
/Library/Containers/com.apple.TextEdit, and it’s preferences are written in
Data/Library/Preferences/com.apple.TextEdit.plist inside that directory.
This can get confusing; in some cases a previous, non-containerized version of the app may have written its preferences to
~/Library/Preferences. So there may be a plist file there that is no longer in use.
So that’s a summary of preference locations on the filesystem that may be less than obvious. In the next post, I’ll describe a tool that will work out for you what the defaults incantation is to configure a specific setting. For that tool, you’ll need the foundation established in this and the previous