← Blog

Why Deleted Mac Apps Leave Files Behind

· macos, uninstall

Why Deleted Mac Apps Leave Files Behind

Drag an app to the Trash, empty it, done. That's the entire uninstall story macOS tells you, and it's about a third of the truth. Deleting an app removes the .app bundle and nothing else. The caches it wrote, the preferences it saved, the sandbox container macOS built for it on first launch: all of it stays on your disk, indefinitely. That's not an oversight. Apple's own developer documentation requires apps to store their working data outside the bundle, in ~/Library, where deleting the app can't reach it. This article covers what actually gets removed when you trash an app, where the rest lives, why Apple designed it this way on purpose, and how to clean up leftovers without breaking something you still use.

Key Takeaways

  • Trashing an app deletes only the .app bundle, never its data in ~/Library.
  • Apple's own documentation says macOS never removes group containers, even after uninstall.
  • Every Mac App Store app submitted since June 2012 is sandboxed and creates a container.
  • Leftovers are usually harmless, but they pile up. Review first, then delete.

What actually happens when you drag a Mac app to the Trash?

Trashing an app deletes exactly one thing: the .app bundle, usually in /Applications. Apple's File System Programming Guide directs apps to write their data to ~/Library folders like Application Support and Caches, outside that bundle. Deleting the bundle never touches those folders, so everything the app created while running survives.

A Mac app bundle is a folder dressed up as a single file. Right-click any app, choose Show Package Contents, and you'll see the executable, resources, and frameworks inside. That self-contained design is why installing most Mac apps is a single drag to /Applications, and it's why uninstalling feels equally simple.

The catch: from the app's perspective, the bundle is read-only territory. The moment an app runs, it writes elsewhere. Settings go to ~/Library/Preferences, working data to ~/Library/Application Support, disposable files to ~/Library/Caches. Sandboxed apps go further. On first launch, macOS creates a private container at ~/Library/Containers/<bundle id> and gives the app exclusive access to it (Apple Developer, retrieved June 2026).

Trash the app and every one of those locations keeps its files. The Finder doesn't warn you, and as of June 2026, Apple's own uninstall instructions don't mention them either. More on that below.

Where macOS stores app data

Almost everything lives under ~/Library, your user Library folder, which the Finder hides by default. Apple's File System Programming Guide names the core trio explicitly: Application Support/<bundle id> for app-created data, Caches/<bundle id> for files an app can regenerate, and Preferences for settings (retrieved June 2026).

The most common leftovers hide in these locations:

LocationWhat lives thereExample path
Application SupportDatabases, downloads, license files~/Library/Application Support/<bundle id>/
CachesFiles the app can re-download or rebuild~/Library/Caches/<bundle id>/
PreferencesSettings stored as property lists~/Library/Preferences/com.apple.TextEdit.plist
ContainersA sandboxed app's entire private file tree~/Library/Containers/<bundle id>/
Group ContainersData shared between an app and its extensions~/Library/Group Containers/<group id>/
Saved Application StateWindow positions for the Resume feature~/Library/Saved Application State/
LogsDiagnostic output~/Library/Logs/

Preferences follow a strict naming convention: the app's bundle identifier plus .plist. TextEdit's settings, for example, live in com.apple.TextEdit.plist (Apple, The Preferences System, retrieved June 2026). That convention is what makes leftover hunting tractable at all. Know the bundle ID, and you know what to look for.

The table above isn't even complete. When we mapped this out for Crufti, we counted 11 distinct ~/Library locations where mainstream apps routinely leave files, including less obvious ones like WebKit, HTTPStorages, and LaunchAgents. The four or five folders everyone remembers are rarely the whole story.

Why doesn't Apple delete these files for you?

Because macOS can't tell "I'm done with this app forever" apart from "I'm reinstalling next week." Apple resolves that ambiguity by never guessing. Its documentation for group containers states that the system creates the directory automatically and "never removes it" (Apple Developer, retrieved June 2026). Persistence is the documented default, not an accident.

This design has a genuine upside. Reinstall an app, and its old preferences and support files are sitting exactly where it expects them. Your settings, window layouts, and license keys come back without a single click. From Apple's perspective, silently deleting user data on uninstall is a far worse failure mode than leaving stray files behind. Data loss is unrecoverable; clutter is merely untidy.

The sandbox era multiplied the leftovers. In February 2012, Apple set June 1, 2012 as the deadline for App Sandbox adoption in the Mac App Store (Apple Developer News, 2012), and sandboxing remains mandatory for App Store distribution today (App Sandbox documentation). Every sandboxed app gets its container on first launch. Fourteen years of that policy means effectively every App Store app you've tried, including the ones you opened once and deleted the same afternoon, created a container that macOS will not clean up.

Here's the part that bothers us. As of June 2026, Apple's consumer support page, Delete or uninstall apps on Mac, last updated June 8, 2026, walks users through dragging an app to the Trash and never mentions ~/Library, caches, preferences, or containers. Its only acknowledgment that more data exists is a note that a bundled uninstaller is the best way to remove data "stored in other locations." So Apple's developer documentation mandates that apps scatter files across your system, while Apple's user documentation stays silent about it. The gap between those two pages is the reason this article exists.

How much space do leftovers actually take?

Honest answer: nobody knows, because no credible independent measurement exists. Cleanup vendors publish dramatic averages, but none disclose a methodology, so we won't repeat their numbers. Qualitatively, one app's leftovers run from a few megabytes to a few gigabytes, depending on the app. Multiply by years of installs across the 25.6 million Macs Apple shipped in 2025 (IDC data reported by MacRumors, 2026), and the aggregate is real.

Caches drive most of the variance. An app that streams media, syncs libraries, or renders web content can quietly hold hundreds of megabytes of rebuildable data, while a small utility might leave behind a single preferences file measured in kilobytes. There's no way to know which kind you have without looking.

Should you ever just leave leftovers alone? Often, yes. If there's any chance you'll reinstall the app, its preferences and support files will restore your setup instantly. Some apps sold outside the App Store also keep license files in Application Support, and deleting those means hunting through old email for a serial number later. Leftovers from apps you still might use aren't junk. They're a convenience waiting to be redeemed.

The real question isn't "how do I delete everything?" It's "how do I delete the right things?"

How do you remove app leftovers safely?

You have two routes: hunt through ~/Library by hand, or use a tool that matches files against the deleted app's bundle identifier. Manual removal works, but Apple itself flags the sharpest edge. Its UserDefaults documentation warns that modifying the preferences system's files directly on disk can cause data loss or an app crash (retrieved June 2026).

The manual route looks like this:

  1. Quit the app, then move it from /Applications to the Trash.
  2. In the Finder, hold Option, open the Go menu, and choose Library.
  3. Search Application Support, Caches, Preferences, Containers, and Group Containers for the app's bundle identifier, such as com.spotify.client.
  4. Move the matches to the Trash, and don't empty it for a few days in case you grabbed something another app needed.

That last step hides the real danger: matching by name. Search ~/Library for "Spark" and you'll also surface files belonging to any app whose name contains those letters. When we built Crufti's matcher, the test case we obsessed over was a hypothetical app called Sparkify, because naive substring matching happily flags Sparkify's files while you're removing Spark. That's exactly how manual cleanup, and some careless cleanup tools, end up deleting a different app's data.

Crufti handles this with a three-tier confidence model. Every candidate file gets rated: an exact match on the full bundle ID (like com.spotify.client.plist), a prefix match, or a word-boundary component match, which lets "Spotify Helper" match Spotify while "Sparkify" can never match "Spark". Generic words like "app" and "service" are never matched at all, and anything risky arrives deselected by default. You review the full list before a single file moves, deletions go to the Trash rather than vanishing, and a local deletion manifest is written first as an audit trail. You can see the full list of what Crufti scans on the homepage.

If you'd rather not spelunk through ~/Library yourself, Crufti is on the Mac App Store for $9.99, one time, no subscription. It's sandboxed, it makes no network connections, and it shows you everything before anything moves.

Frequently asked questions

Quick answers to the questions we hear most. There are more on the Crufti FAQ.

Does emptying the Trash remove an app's leftover files?

No. Emptying the Trash permanently deletes only what's inside the Trash, which for a dragged-out app is just the .app bundle. Files in ~/Library/Application Support, Caches, Preferences, and Containers were never in the Trash to begin with, so they remain untouched no matter how often you empty it.

Is it safe to delete everything in ~/Library/Caches?

Mostly, but it's rarely worth it. Apple's file-system guide treats caches as data an app can recreate, so deleting them isn't destructive. But running apps may misbehave, and everything gets rebuilt on next launch at the cost of time and bandwidth. Quit your apps first, and never apply the same broad brush to ~/Library/Preferences.

Do Mac App Store apps leave files behind too?

Yes, reliably. App Store apps must be sandboxed (Apple Developer), and every sandboxed app gets a container at ~/Library/Containers/<bundle id> on first launch. Deleting the app leaves that container behind, and Apple's documentation says the system never removes group containers at all.

Why didn't my free space increase right after emptying the Trash?

Probably Time Machine local snapshots. When Time Machine is enabled, macOS stores hourly APFS snapshots of your disk and keeps them for about 24 hours (Apple Support, 2025). Deleted files stay referenced by those snapshots until they expire, so check again tomorrow. The space usually appears on its own.

Will leftovers slow down my Mac?

Usually not. Most leftovers are inert files that occupy disk space without consuming CPU or memory. The exception worth knowing: entries in ~/Library/LaunchAgents ask macOS to run something at login, so an orphaned agent can keep firing for an app that no longer exists. Beyond that, leftovers only matter as your drive fills up.

More macOS housekeeping guides are on the way at the Crufti blog.

Sources