How to Customize macOS with Terminal and the defaults Command

Many macOS settings have no corresponding checkbox in System Settings at all — they’re only reachable through the defaults command, which reads and writes the same property-list preference files covered elsewhere on this blog. This walks through practical, safe customizations and how to structure your approach so nothing is ever a one-way change.

Step 1: understand what defaults actually does

defaults reads and writes values directly into an application’s (or the system’s) preferences plist — the exact same files ~/Library/Preferences/ holds, and the exact same underlying mechanism NSUserDefaults uses. There’s no special magic here; you’re just setting a preference key a GUI checkbox doesn’t happen to exist for.

defaults read com.apple.dock

This dumps every currently-set preference for the Dock — useful both for finding a specific key’s current value before changing it, and for understanding what’s actually available to configure.

Step 2: back up before changing anything

defaults read com.apple.dock > ~/dock-backup-$(date +%Y%m%d).plist

This is your undo mechanism — if a change doesn’t behave as expected, you have the exact prior state recorded.

Step 3: a practical, safe customization — faster Dock auto-hide animation

defaults write com.apple.dock autohide-time-modifier -float 0.2
defaults write com.apple.dock autohide -bool true
killall Dock

Most defaults changes require restarting the affected application (killall Dock, killall Finder, killall SystemUIServer) to take effect — the process reads its preferences at launch, not continuously.

Step 4: show hidden files in Finder

defaults write com.apple.finder AppleShowAllFiles -bool true
killall Finder

Step 5: disable the “are you sure you want to open this application” Gatekeeper prompt for locally-built apps you trust

defaults write com.apple.LaunchServices LSQuarantine -bool false

Be deliberate about this one specifically — it affects Gatekeeper’s quarantine-based first-launch prompt broadly, not just one app, so only disable it if you understand and accept that trade-off, and prefer xattr -d com.apple.quarantine on a specific file instead if you only want to bypass it for one known-safe binary.

Step 6: reverting any change

defaults delete com.apple.dock autohide-time-modifier
killall Dock

defaults delete removes a key entirely, reverting to that application’s built-in default — the clean, correct way to undo a customization, rather than trying to remember and re-set the original value manually.

Step 7: finding more settings to customize

defaults read com.apple.finder
defaults read -g    # global/system-wide preferences

Comparing defaults read’s output before and after toggling a setting through the normal System Settings UI (for something you can already change through the GUI) is a reliable way to discover the underlying key name and value type for something you’re curious about extending or scripting.

Why treat this as “editing preferences,” not “hacking macOS”

Every defaults command here is doing exactly what the GUI does when you toggle a setting — writing a value into a plist file that the relevant application reads at launch. There’s no special risk beyond “a poorly chosen value might make an app behave unexpectedly until reverted,” which is precisely why backing up the current value first (step 2) and knowing the exact defaults delete command to undo any change (step 6) is worth doing before experimenting with anything beyond the well-documented, commonly-shared examples above.

Step 8: understand the type flags, since getting them wrong is the most common mistake

defaults write com.example.app SomeKey -bool true
defaults write com.example.app SomeKey -int 42
defaults write com.example.app SomeKey -float 1.5
defaults write com.example.app SomeKey -string "value"
defaults write com.example.app SomeKey -array item1 item2

Property lists are typed, and defaults write needs to be told explicitly what type a value should be stored as — -bool, -int, -float, -string, -array, and -dict each produce a genuinely different underlying plist data type, not just a different text representation of the same thing. Writing a boolean-expecting key as a string (omitting -bool and just writing true as bare text) is a common, quiet source of “I set the value but the app ignores it” confusion, since the application’s own code is checking for an actual boolean type, not a string that happens to read as “true.” Checking a key’s existing type with defaults read-type before writing to it avoids this entire class of mistake:

defaults read-type com.apple.dock autohide

Step 9: distinguish per-machine settings from per-user ones

sudo defaults write /Library/Preferences/com.apple.something GlobalKey -bool true
defaults write -currentHost com.apple.something HostKey -bool true

Most defaults commands shown so far write to a preference domain scoped to your specific user account — but some settings are meant to apply system-wide (requiring sudo and a path under /Library/Preferences/ rather than ~/Library/Preferences/), and others are meant to be specific to the current machine but shared across every user account on it (-currentHost, which writes to a ByHost preferences location keyed to the Mac’s own hardware identifier). Confirming which scope a specific setting you’re trying to change actually lives in — user-specific, machine-specific-but-shared, or genuinely system-wide — before writing to the wrong one is worth doing deliberately rather than guessing, since a per-user change and a system-wide change can look identical in a copied command but behave completely differently once applied, particularly on a shared or managed Mac with more than one distinct user account actually logging in and using it day to day.

Related:

Sources: