Dragging an app to the Trash feels like uninstalling it. It isn’t. It removes the .app bundle — the icon you dragged — and nothing else. Everything the app wrote outside that bundle stays exactly where it was written, and macOS has no mechanism that ever cleans it up. It accumulates for the life of the machine.
On a Mac that has been in use for a few years, this is usually measured in gigabytes, and almost all of it belongs to software that was removed long ago.
Where it goes
All eight locations live inside ~/Library — your user Library, not the system one. It is hidden by default, so you cannot browse to it in a normal Finder window.
- Application Support — the app’s working data. Usually the largest leftover.
- Caches — downloaded and generated files the app kept between launches.
- Containers — a sandboxed app’s entire data store.
- Group Containers — data shared between an app and its extensions.
- Preferences — settings, written as com.vendor.app.plist.
- Saved Application State — window positions and restored documents.
- Logs — diagnostic output.
- HTTPStorages — cookies and cached web requests.
To open any of them, use Finder’s Go > Go to Folder (Shift-Cmd-G) and paste the path — for example ~/Library/Application Support.
Why searching the app’s name doesn’t find it all
This is where most manual cleanups quietly fail. Leftovers are not reliably named after the app. They are named after its bundle identifier — a reverse-domain string like com.vendor.appname, which frequently bears no resemblance to the name on the icon. The vendor half is the company, not the product, so an app you know by one word is often filed under a company name you have never heard of, and apps that were renamed, acquired or rebranded keep the identifier they shipped with.
Search Finder for the app’s display name and you will find some of its files and silently miss the rest. Match on the bundle identifier instead. You can read it from the app itself: right-click the .app, choose Show Package Contents, open Contents/Info.plist, and look for CFBundleIdentifier.
The two things worth checking beyond the eight
Launch agents. Some apps install a background process that keeps running after the app is gone. Check ~/Library/LaunchAgents for a matching .plist. There are machine-wide equivalents in /Library/LaunchAgents and /Library/LaunchDaemons — the daemons need an admin password to remove, and are worth leaving alone unless you are certain what wrote them.
Anything you are unsure about. Move it to the Trash rather than deleting it outright, and leave the Trash unemptied for a few days. If something breaks, drag it back. Nothing about this process needs to be irreversible.
Doing it without the archaeology
Checking eight folders by hand, per app, against a bundle identifier you had to dig out of a plist, is tedious enough that most people do it once and never again. Tools exist to do the matching for you — the free and open-source AppCleaner handles one app at a time, and if you want to uninstall apps on a Mac in bulk, Broomkit lists installed apps with their bundle identifiers and sizes, grouped by what you have not opened in six months, and matches leftovers across all eight locations before anything moves.
Whatever you use, the test of a good uninstaller is simple: it should show you the full path of every file before it touches anything, and it should move files to the Trash rather than unlinking them. If it does neither, you are trusting it blind.
Disclosure: the author develops Broomkit, one of the tools mentioned.
