Reading and writing macOS preferences: defaults, plutil, and why cfprefsd hides a direct edit

What it is

defaults reads and writes values inside a preference domain — normally a property list at ~/Library/Preferences/<domain>.plist or /Library/Preferences/<domain>.plist — by key path, rather than requiring you to parse XML or binary plist syntax: defaults read com.apple.dock, defaults write com.apple.dock autohide -bool true, defaults delete com.apple.dock autohide. plutil -convert xml1 -o - file.plist converts between the binary, XML and JSON plist encodings, and plutil -lint file.plist reports whether a file parses at all before you trust it or ship it. /usr/libexec/PlistBuddy -c "Print :SomeKey" file.plist edits or reads a single entry inside an arbitrary plist without going through defaults' domain model at all.

Why it matters

macOS does not read a preference file directly at the moment an app asks for a setting. A per-user daemon, cfprefsd, caches preference values in memory and mediates every read and write made through the CoreFoundation preferences API that both defaults and most apps use. Overwriting or replacing a plist file on disk with a text editor, cp, or a restored backup does not invalidate that cache: a running app keeps whatever cfprefsd last handed it, so the edit appears to have no effect until the app relaunches or the cached domain is reloaded.

How to apply

• Prefer defaults write/delete over hand-editing the plist file directly; going through the same API cfprefsd mediates avoids the stale-cache problem for that change.
• If a file must be edited directly (bulk migration, restoring from backup), quit the owning app first, or run killall cfprefsd afterwards to force a reload from disk — this affects other processes' cached preferences too, so do it when little else is running.
• Validate any plist about to be shipped or restored with plutil -lint first; a corrupt file makes some apps fall back to defaults silently and others fail hard.
• Use plutil -p file.plist for a quick human-readable dump when only inspecting, not editing.

Pitfalls

• Diffing two plist files and predicting the running app's behaviour from that; the app may still be serving an old cached value.
• Writing with defaults while the target app is running and expecting it to notice without a restart; some apps subscribe to change notifications, most do not.
• Forgetting binary plists are not text: cat, sed or grep on one directly shows garbage — always go through plutil -convert or -p first.