The Files Left Behind When You Delete a Mac App

Windows has a registry and an uninstaller convention that, imperfectly, tries to clean up after itself. macOS has neither. When you drag an app to the Trash, you remove exactly one thing: the .app bundle. Everything else it ever wrote to your disk — and a typical app writes to five or six different places — stays exactly where it was, permanently, unless you go find it yourself.

Where an app actually writes, beyond its own bundle

A single app can leave files in all of these locations, none of which get touched when you delete the app itself:

~/Library/Application Support/<AppName>    # settings, local databases, sometimes huge caches
~/Library/Caches/<bundle.id>               # rebuildable cache — see the dedicated guide below
~/Library/Containers/<bundle.id>           # sandboxed apps get a full private filesystem here
~/Library/Preferences/<bundle.id>.plist    # settings, tiny, but adds up across hundreds of apps
~/Library/Saved Application State/<bundle.id>.savedState   # window/tab restore state
~/Library/Logs/<AppName>                   # diagnostic logs, sometimes gigabytes for chatty apps

None of this is a bug or an app behaving badly — this is the documented, correct place for an app to put this data. The problem is entirely on the removal side: nothing in macOS is responsible for cleaning it up when the app itself goes away.

Finding what belongs to an app you already deleted

If you already dragged the app to the Trash and only now wonder what it left behind, its bundle identifier is the key — everything above is filed under it, but you no longer have the app around to tell you what that identifier was.

# Search Spotlight's metadata for a plausible bundle identifier match
mdfind "kMDItemCFBundleIdentifier == '*appname*'"

# Or just search by the app's name directly across the usual leftover locations
find ~/Library/Application\ Support ~/Library/Caches ~/Library/Containers \
     ~/Library/Preferences ~/Library/Saved\ Application\ State ~/Library/Logs \
     -iname "*appname*" -maxdepth 1 2>/dev/null

Bundle identifiers are reverse-DNS (com.company.AppName), so searching for the company or product name usually surfaces every relevant folder even when the exact identifier isn’t obvious.

Which leftovers are actually worth deleting

Not every leftover is worth chasing individually — a .plist preferences file is a few kilobytes, and hunting it down for every app you’ve ever removed is not a good use of an afternoon. The ones worth caring about are the large ones:

• ~/Library/Containers/<bundle.id> — for sandboxed apps (most modern App Store apps, and many others), this is effectively a private filesystem the app had full run of. Video editors, design tools, and anything that processes large media files routinely leave multi-gigabyte containers behind.
• ~/Library/Application Support/<AppName> — this is where an app’s actual local database lives, if it has one. Chat apps, note-taking apps, and anything with an offline cache commonly put several gigabytes here.
• ~/Library/Logs/<AppName> — usually small, but a small number of apps (video conferencing tools are a repeat offender) log verbosely enough to reach a gigabyte or more over time.

~/Library/Caches/<bundle.id> for a deleted app is unambiguously safe — it’s cache for an app that no longer exists to use it, so there’s no rebuild cost to worry about at all, unlike clearing the cache for an app you still use.

# Once you've confirmed the app is really gone and identified its folders:
rm -rf ~/Library/Application\ Support/AppName
rm -rf ~/Library/Containers/com.company.AppName
rm -rf ~/Library/Caches/com.company.AppName

The one thing worth checking before deleting a Container

A sandboxed app’s Container can, in rare cases, hold the only copy of something you created inside that app and never exported — some note-taking apps and drawing apps store your actual content this way rather than in a regular Documents folder. Before deleting a Container for an app you’re on the fence about, open the app one more time (if you still can) and check whether there’s anything inside it you’d want to export first. Once you’re sure, deleting is immediate and irreversible in the sense that there’s nothing to regenerate — same as any file deletion, just without an app around to warn you.

Why this is worse than it sounds, at scale

Nobody uninstalls one app and worries about 200 MB of leftovers. The real cost is cumulative: a Mac that’s had a hundred apps installed and removed over several years — trial versions, one-off utilities, apps you tried and didn’t keep — can easily be carrying 10–20 GB of orphaned data from software that isn’t even on the machine anymore, invisible because there’s no icon in Finder to remind you it ever existed.

The commands above are free and they work, just slower for a hundred apps than for one. DevCruft, a free Mac app for developers that we’re building, is being designed to run this hunt for you and find the leftovers of apps that are no longer installed. Join the waitlist to hear when it launches.

For the cache folders that apps you’re still using leave behind, see the ~/Library/Caches guide.