Home › Blog

Dragging an app to the Trash does not uninstall it

14 August 20269 min read

You deleted a 400 MB app and got back 400 MB. The other 3 GB it created over two years is still sitting in your Library, and macOS has no intention of mentioning it.

What actually happens when you drag an app to the Trash

A Mac app is a folder wearing a costume. What looks like a single file called Photoshop.app is really a directory with a specific internal layout, and Finder politely pretends it is one object so you do not have to think about it.

When you drag it to the Trash, you move that one folder. That is the whole operation. Everything the app created while it was running lives somewhere else entirely, because macOS deliberately keeps programs and their data apart. The app goes in /Applications. The data goes in your Library. Nothing connects the two except a naming convention, and naming conventions do not delete things.

This is not a bug or an oversight. It is what lets you delete an app, reinstall it, and find all your settings exactly as you left them. The same design that makes reinstalling painless is the one that makes uninstalling incomplete. You cannot have one without the other, and Apple picked the side that annoys you less often.

The cost shows up slowly. An app you used every day for two years may have written a cache database that dwarfs the app itself. A video editor with a 900 MB bundle can easily leave 14 GB of render cache. A chat client leaves every image anyone ever sent you. None of it goes anywhere when the app does.

The nine places the leftovers live

Almost everything an app leaves behind is in one of these. Eight are inside your home Library folder, which Finder hides by default. Hold Option while clicking the Go menu and Library appears in the list.

The size column is the part people get wrong. Preferences and saved state are rounding errors. Application Support and Caches are where the actual space went, and they are the two nobody looks in, because they have boring names.

Why searching for the app's name finds almost nothing

Here is the trap. You uninstall an app called Fusion, so you search your Library for "Fusion" and find one small folder. You conclude it was tidy. It was not. You searched for the wrong thing.

Apps do not identify themselves by their display name. They use a bundle identifier, a reverse domain string that looks like this:

com.blackmagic-design.DaVinciResolve
com.tinyspeck.slackmacgap
com.google.Chrome

Notice that none of those are what the app is called in your Dock. Slack's identifier still contains "tinyspeck", the name of the company that made it before Slack was Slack. Searching your Library for "Slack" misses every folder named after a company that stopped existing under that name in 2014.

You can read any app's identifier before you delete it. Right click the app, choose Show Package Contents, open Contents/Info.plist, and look for CFBundleIdentifier. Or ask the command line, which is faster:

osascript -e 'id of app "Slack"'

Do this before you drag the app to the Trash. Once the bundle is gone, the identifier is gone with it, and you are back to guessing which of the folders in your Library belonged to what. This is the single most common way people end up with orphaned data they can no longer confidently identify.

Launch agents: the leftovers that keep running

Everything above is inert. It sits there taking up room and does nothing. Launch agents are different, and they are the reason this article is not purely about disk space.

A launch agent is a small .plist file that tells macOS "start this program at login, and restart it if it stops". Updaters use them. Sync clients use them. So does anything with a menu bar icon that appears before you open the app.

The file lives in ~/Library/LaunchAgents, entirely separate from the app. Delete the app and the instruction stays. macOS dutifully tries to launch something that no longer exists, fails, waits, and tries again. It will do this at every login for as long as you own the Mac, quietly, without ever telling you.

Individually this costs almost nothing. Collectively, on a machine that has had forty apps come and go, it is a measurable part of why logging in feels slower than it did when the Mac was new. If that is the symptom you actually came here to fix, the mechanics are worth reading properly in what is really starting when your Mac boots.

To see what is currently there:

ls -la ~/Library/LaunchAgents

Every file is named after the thing it starts. If you recognise none of them, that is normal and slightly alarming in equal measure.

The two things that will actually break something

Most leftovers are safe to remove, which is why so much advice online amounts to "delete anything with the app's name on it". That advice works right up until it doesn't, and the two cases where it doesn't are both predictable.

Shared group containers

A group container is data one vendor shares between several of its apps. Microsoft Office uses one across Word, Excel, PowerPoint and Outlook. Delete the group container because you removed PowerPoint, and you have also removed the licensing state for the three apps you kept. They will start asking you to sign in again, and you will not connect that to the thing you did last Tuesday.

The rule: before deleting anything in Group Containers, check whether any other app from the same vendor is still installed. If one is, leave it.

Folders named after a company, not a product

Some vendors give every app its own folder. Others use one folder per company and put everything inside. A folder called Adobe in Application Support is not Photoshop's folder. It is the folder for every Adobe product you have ever installed, and it may still be in use by three of them.

Doing it by hand, if you want to

The manual process is genuinely straightforward, just tedious. In order:

1. Get the bundle identifier while the app still exists, using the osascript command above.
2. Quit the app. Check the menu bar for a lingering icon, because helper processes survive quitting the main window.
3. Open each of the nine locations in the table and look for that identifier, plus the vendor prefix before the last dot.
4. Check ~/Library/LaunchAgents before anything else, since that one has ongoing effects.
5. Move what you find to the Trash. Do not empty it yet.
6. Restart, use the Mac normally for a day, then empty the Trash.

Step six is the one people skip, and it is the one that matters. The Trash is a free undo button that lasts as long as you leave it alone. Emptying it immediately after a cleanup converts a reversible mistake into a permanent one, in exchange for getting your disk space back several hours earlier than you needed it.

How Strata handles this

Strata reads the bundle identifier out of every installed app, then searches all nine locations for anything matching that identifier or its vendor prefix. It shows you what it found, how large each item is, and, importantly, how confident it is.

That confidence rating is the part worth explaining, because it is where these tools usually go wrong. An exact identifier match in a sandboxed container is not the same kind of evidence as a folder whose name shares a word with the app. Presenting both as "found: delete this" is how people lose data. Strata separates them, tells you which is which, and leaves the ambiguous ones unticked by default.

Anything it removes goes to the Trash, not to oblivion, and there is a one-step undo that puts every file back exactly where it came from. There is no version of this where software should be more confident about your files than you are.

Common questions