Trace Library state by scope

The same application may use ~/Library, /Library, and sandbox container directories for different state. Scope matters before deletion or migration: ~/Library is one user’s state, /Library applies to every user on the Mac, and /System/Library belongs to macOS itself and is off limits.

Sandboxed apps add a twist. Their writable world lives in ~/Library/Containers/<bundle-id>, which mirrors a private Library inside, and app families share data through ~/Library/Group Containers.

Search narrowly by bundle identifier

Get the app’s bundle ID first, then look for it:

osascript -e 'id of app "Notes"'
# com.apple.Notes

ls ~/Library/Preferences | grep -i com.apple.Notes
ls ~/Library/Containers | grep -i com.apple.Notes
ls ~/Library/Application\ Support | grep -i Notes

Search narrowly by bundle identifier in the current user Library. Inspect Preferences, Application Support, Caches, Logs, Containers, and Group Containers without assuming each is present. A non-sandboxed tool may only have a single plist in Preferences; a sandboxed app may keep everything under its container.

What each location tells you: Preferences holds settings, Application Support holds documents and databases the app depends on, Caches holds regenerable data, Logs holds the app’s own log files.

Change state carefully

Back up valuable data and quit the app before changing state. Quitting matters more than it looks: preferences are cached by the cfprefsd daemon, so if you delete a plist while the app runs, the old values can be written straight back and you will conclude, wrongly, that the file was not the problem.

Then reset one proven file or container, not the entire Library folder. Move the candidate aside instead of deleting it:

mv ~/Library/Preferences/com.example.editor.plist ~/Desktop/

Relaunch and retest. If the symptom survives, move the file back. That single-file discipline keeps the experiment reversible and tells you precisely which piece of state carried the fault.