How to uninstall apps on Mac completely — including the leftovers

Why dragging to the Trash is not enough

A macOS application is a bundle: Photoshop.app is a folder pretending to be a file, and moving it to the Trash removes the executable and its resources. What it does not remove is everything the app wrote outside itself while you used it — preferences, caches, application support data, logs, saved window state, and for sandboxed apps a whole container.

For a small utility the leftovers are a few megabytes and nobody cares. For Adobe apps, Docker, Xcode, Parallels, virtual machine software or anything with a bundled helper daemon, the leftovers routinely outweigh the app itself by an order of magnitude. Docker Desktop is about 2 GB installed and can leave 30 GB or more behind in its container.

There is a second reason to be thorough: some apps track their trial period in a preference file, and some install launch agents that keep running after the app is gone.

Check for a real uninstaller first

Some applications ship a proper uninstaller and you should use it. Adobe apps must be removed with the Creative Cloud app. Microsoft Office has a support tool. Antivirus software, VPN clients, printer drivers and anything with a kernel or system extension almost always requires the vendor uninstaller — those install components outside your home folder that a manual sweep will not find and that you should not remove by hand.

Apps installed with Homebrew should be removed with Homebrew, which knows exactly what it put where.

brew uninstall --zap <formula>
brew uninstall --cask <app>

--zap also removes configuration files the cask knows about. Without it, brew leaves the same leftovers a manual drag would.

The nine places leftovers live

When there is no uninstaller, the files are in a predictable set of directories, all keyed by the app's bundle identifier (com.vendor.appname). Find the identifier first — it is the reliable search key, because folder names rarely match the app's display name.

Then look in each of these:

• ~/Library/Application Support/<name or bundle id> — the big one. App data and often a private cache.
• ~/Library/Caches/<bundle id> — regenerable cache.
• ~/Library/Preferences/<bundle id>.plist — settings.
• ~/Library/Containers/<bundle id> — everything for a sandboxed app, including its documents.
• ~/Library/Group Containers/<team id>.<group> — data shared between an app and its extensions.
• ~/Library/Saved Application State/<bundle id>.savedState — restored windows.
• ~/Library/Logs/<name> — logs.
• ~/Library/HTTPStorages/<bundle id> — cookies and local storage for apps that embed a web view.
• ~/Library/WebKit/<bundle id> — web view caches.

# Read the bundle identifier out of the app itself
mdls -name kMDItemCFBundleIdentifier -r /Applications/Example.app

# Then find what it left behind (read-only)
find ~/Library -maxdepth 2 -iname "*com.example.app*" 2>/dev/null

The safe manual procedure

Quit the app, and check Activity Monitor for helper processes with the same name — some apps run an updater or a sync agent that will rewrite its preferences the moment you delete them. Then move the .app to the Trash, run the find command above, and move each match to the Trash as well.

Check ~/Library/LaunchAgents and /Library/LaunchAgents for .plist files belonging to the app; those are what keep a background helper starting at login. If you find one, unload it before deleting so it does not respawn.

Log out and back in, then empty the Trash. Logging out is what releases file handles held by helpers you may have missed.

launchctl unload ~/Library/LaunchAgents/com.example.helper.plist
ls ~/Library/LaunchAgents /Library/LaunchAgents

Never delete anything from /System/Library/LaunchDaemons. Those belong to macOS.

Two things people get wrong

The first is deleting by app name instead of bundle identifier. Searching for "Zoom" in ~/Library will also match "zoom.us", "ZoomPhone" and unrelated folders from other vendors; searching for us.zoom.xos will not. When in doubt, match the identifier.

The second is deleting shared frameworks. If two apps from the same vendor are installed, the Group Container and any /Library/Application Support/<vendor> folder may serve both. Removing one app should not take the other's data with it — check what else is installed from that vendor before clearing a shared directory.

What is left after a thorough uninstall

Two categories survive even a careful sweep, and it is worth knowing they exist rather than hunting for them fruitlessly.

The first is licence and receipt data that some vendors deliberately store outside the obvious locations — in the keychain, or in a file with a deliberately unrelated name — so that reinstalling does not reset a trial. This is by design and it is generally a few kilobytes. It is not worth chasing for space, and removing keychain entries by hand risks breaking apps you still use.

The second is system-level components: privileged helper tools in /Library/PrivilegedHelperTools, launch daemons in /Library/LaunchDaemons, and system extensions registered with macOS. These require administrator rights to install and to remove, and they are exactly the case where the vendor uninstaller is not optional. You can list what is registered with `systemextensionsctl list`, but removing an extension should be done through the app that installed it.

Finally, check Login Items in System Settings → General → Login Items after any uninstall. An entry left there for a deleted app is harmless but produces a confusing error at every login, and removing it takes one click.

systemextensionsctl list
ls /Library/PrivilegedHelperTools

Doing it in one pass

This is the kind of chore that is genuinely better automated, because the work is entirely mechanical: read the bundle identifier, search nine directories, present the matches. Dropit's Applications tab lists every app in /Applications and ~/Applications with the total size of its leftovers computed alongside it, so you can see that a 40 MB app is holding 6 GB of support data before deciding. Seeing the list and the sizes costs nothing. Performing the uninstall — moving the bundle and every matched leftover to the Trash in one action, after a running-process check — is a paid feature. It always uses the Trash, so Finder's Put Back reverses it.