Prefs Tool

Preferences or defaults on macOS seem easy, but their subtleties can grow complex very quickly.

The main reason for confusion is that preferences can be stored in many places and on many levels. The defaults system composites all of the keys and values from all locations to a process or application.

In my book “Property Lists, Preferences and Profiles for Apple Administrators”, I list 17 possible domains or levels where preferences can be stored and read from. The most common domains are:

Domain Location
User/Application ~/Library/Preferences/identifier.plist
User/Application/Computer ~/Library/Preferences/ByHost/
Computer/Application /Library/Preferences/identifier.plist
Configuration Profile n/a

To add to this confusion, Apple’s documentation keeps mixing up terms like ‘domain’ and ‘identifier’. I use the term ‘domain’ to designate the level or location a setting is stored in, and ‘identifier’ for the name of the preference (i.e.

The defaults command, which is the proper tool to interact with preferences files, does not properly work with different levels or domains. When you run

$ defaults read

The output will be from the User/Application domain only, i.e. the data stored in the file ~/Library/Preferences/

But the ScreenSaver process stores more data in the ByHost domain. You can read this domain or location with defaults as well:

$ defaults -currentHost read

However, you must remember to check and read the ByHost domain as well as the standard domain. To access the computer level domain you have to use

$ defaults read /Library/Preferences/

(The ScreenSaver process does not use this domain, so you will get an error saying that it does not exist. However, you won’t know this domain is empty until you try.)

Defaults cannot tell you when a setting is set or overridden by a configuration profile, or what its value is in that case. You cannot get the full composited view of defaults with the defaults command.

Greg Neagle wrote a short python script a while back which could give you the effective result for an identifier and a specific key. His script will also show where the value is coming from.

I have found Greg’s script to be very useful, but I wanted it to do a bit more. My version, Prefs Tool, can now show you all keys set for a specific application identifier, including those managed by configuration profiles.

$ ./
idleTime <int>: 0L (User/ByHost)
CleanExit <string>: u'YES' (User/ByHost)
askForPassword <bool>: True (Managed)
askForPasswordDelay <int>: 0L (Managed)
moduleDict <dict>: {
    moduleName = iLifeSlideshows;
    path = "/System/Library/Frameworks/ScreenSaver.framework/Resources/iLifeSlideshows.saver";
    type = 0;
} (User/ByHost)
showClock <bool>: True (User/ByHost)
tokenRemovalAction <int>: 0L (User/ByHost)
PrefsVersion <int>: 100L (User/ByHost)

The script has a few more tricks up its sleeve. There is also still lots of work to be done. See the Github repository and its ReadMe for details.

Published by


Mac Admin, Consultant, and Author