Why Deleted Mac Apps Leave Files Behind — Crufti<br>llms.txt — structured site index for AI agents← BlogWhy Deleted Mac Apps Leave Files Behind<br>June 10, 2026 · macos, uninstall<br>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.

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/ 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/ for app-created data, Caches/ for files an app can regenerate, and Preferences for settings (retrieved June 2026).

The most common leftovers hide in these locations:

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