Much of the time we set an app’s preferences and they just work, but sometimes they lead to all sorts of problems. One traditional way of dealing with those is to trash that app’s preferences file, and force it to build a new one. Try it now with many apps, particularly the Finder, and it’s doomed to fail. This is because trashing preferences is trying to work against macOS, and more often than not, you’ll come out the loser, having wasted time and got nowhere.

The reason that directly manipulating preferences files is so frustratingly unsuccessful now is that macOS manages them using a service, cfprefsd, which will always work against your direct actions. It’s far better instead to work with cfprefsd, using the command tool defaults.

There are exceptions to this. Some apps manage their own preference settings rather than leaving them to cfprefsd. For a developer, it’s tempting, but only creates more work. So all Apple apps, as far as I’m aware, and the great majority of those from third-parties, should be approached through the two official channels: change their Preferences, or use defaults. If you want a GUI app which has an impeccable track-record, look at Thomas Tempelmann’s free Prefs Editor, which works through the defaults command. There are several other apps which edit general preference settings, those of the Finder and other common apps.

Another good reason for working with cfprefsd rather than trying to beat it into submission is that it knows where all the preferences files are. By the time you’ve migrated across a few Macs and versions of Apple’s Mail app, your Home folder’s Library probably contains several different property list files containing the settings for different versions. Can you find which is the active one? Use defaults and it should save you that trouble and confusion.

The Finder is an excellent example of an app whose preferences should only ever be manipulated using the right tools. Because it’s running all the time, cfprefsd is sure to defeat you if you try to do anything direct.

To change preference settings using defaults, there are three bits of information which you need:

• The ID of the app, such as com.apple.Finder. For many, this is obvious, or can be checked using a tool such as Taccy. In most cases, if you can’t find out you can specify the name of the app instead of its ID using the option -app AppName, where AppName is the regular app name as shown, without the .app extension.
• If you want to set or change a setting, the key for that individual setting.
• If you want to set or change a setting, the value to pass for that key.

The latter two aren’t something you can readily guess. Commonly-used settings are often given in articles and Q&A items on the internet. Beware that older keys and values may have changed in more recent versions of that app, though. One way to confirm the current keys and values is to dump the app’s settings into a property list using a command like
defaults read com.vendor.appname > ~/Documents/appnamePrefs.plist
where com.vendor.appname is the app ID and the file path specifies a new file into which to dump them. This is a task which Prefs Editor does for you, in effect.

Changing or setting some preferences can be straightforward. For example, the Finder has a key in its preferences which determines the folder to open in a new Finder window, named NewWindowTargetPath. To inspect its current value, enter the command
defaults read com.apple.Finder NewWindowTargetPath
which should return the path as a URL string, such as
file:///Volumes/External1/Documents/0newDownloads/

To change that, enter a command such as
defaults write com.apple.Finder NewWindowTargetPath 'file:///Volumes/External1/Documents'
which changes that setting to open the folder specified by that URL. As you’re passing the URL as a string, to be saved as the value for the NewWindowTargetPath key, you put it in single quotes. If you then try opening a new window in the Finder, you’ll be frustrated to see that nothing has changed. To bring that change into effect, you need to restart the Finder from the Force Quit dialog, which makes it load its preferences again when it starts up.

This works fine when the key you’re setting appears at the top level of the dictionary in the property list, and when the value is a string. defaults does have options which you can use to set values of other types, include integers and floating point numbers. But it gets complicated when you want to change the value for a key which is embedded in another dictionary within the property list, or the value is something more complicated such as data.

If you merely want to reset part or all of an app’s preferences, then defaults is more straightforward. Removing a single setting runs like
defaults delete com.apple.Finder NewWindowTargetPath
When you restart or open that app next, that setting should be returned to its default so that you can get its value straight again. The equivalent of putting the whole preferences file into the Trash is even simpler, with
defaults delete com.apple.Finder

Before you do that, though, you might like to make notes on any important or tricky settings which you wish to restore once the app’s using its default settings again.

There are two common problems which seem to occur with preference files: they can become corrupt, or acquire the wrong permissions. Deleting the file using defaults should address both of those, as the replacement written by the app shouldn’t be corrupted, and should have the correct permissions again. However, having to delete the whole file to fix it isn’t an ideal solution. Some apps let you reset your preferences to their ‘factory’ defaults, but unless that’s preceded by deleting the existing property list, it can leave the problem unfixed. I’m not aware of any app which offers to delete its preferences and create a new property list.

The TL;DR thus reads: don’t trash preference files; instead use commands like
defaults delete com.vendor.appname
or
defaults delete -app AppName
as it’s far more likely to work.