Where Do Mac Apps Store Files? Every Hidden Folder Explained

If you have ever deleted an app by dragging it to the Trash and later discovered its preferences or caches were still sitting on your drive, you have already met macOS's distributed storage model. Where do Mac apps store files? The short answer: dozens of folders spread across your home directory and system volumes — none of which the Trash knows about. This guide maps every location, explains what lives there, and tells you exactly what is safe to remove so you can reclaim real disk space without breaking anything.

Why macOS Scatters App Data Across Your Drive

Apple's sandboxing and file-system conventions separate app code (in /Applications) from the data that code writes at runtime. This keeps the app bundle clean and updatable, but it means that uninstalling by dragging the .app to Trash leaves behind a trail of support files, caches, preferences, and launch services. On a Mac you have used for several years, those leftovers can total several gigabytes across hundreds of apps.

Most of the interesting locations live inside ~/Library, which Finder hides by default. To open it in Finder, hold Option and click the Go menu — "Library" will appear.

The Complete Map: Mac App Support Files Location by Folder

Application Support Folder Mac: The Biggest Offender

The Application Support folder (~/Library/Application Support) is where most apps park their heaviest data: local databases, downloaded content, offline maps, email indices, and more. Slack alone can store several gigabytes of message cache here. Adobe Creative Cloud keeps gigabytes of fonts, libraries, and presets. After you delete those apps, their subfolders stay behind indefinitely.

To inspect it in Terminal:

du -sh ~/Library/Application\ Support/* | sort -rh | head -20

This lists the 20 largest subdirectories sorted by size, so you can immediately see which former apps are the biggest squatters.

Caches: Usually Safe, Occasionally Large

~/Library/Caches holds derived data — thumbnails, compiled assets, downloaded resources — that apps can reconstruct. You can safely delete the contents of this folder while the owning app is not running. The most common large tenants are browsers (Chrome, Firefox), Xcode's derived data, and Homebrew.

# See your largest user caches
du -sh ~/Library/Caches/* | sort -rh | head -20

# System-level caches (macOS manages these; less reason to touch manually)
du -sh /Library/Caches/* 2>/dev/null | sort -rh | head -10

Caution: Do not delete ~/Library/Caches/com.apple.* folders for system services while that service is active. macOS recreates them, but doing so mid-operation can cause transient errors.

Preferences: Tiny but Persistent

~/Library/Preferences contains one .plist file per app, recording every preference the app has ever saved — window size, chosen theme, licence state. These files are tiny (usually under 100 KB each) but accumulate into hundreds of orphans over time. Deleting a .plist for an app that is still installed simply resets it to factory defaults on next launch, which is sometimes intentional (force a fresh start) but usually not what you want.

To see all plists belonging to a specific app's bundle ID (e.g. com.apple.safari):

ls ~/Library/Preferences/ | grep com.example.appname

Containers and Group Containers: The Sandbox Vaults

Since macOS 10.7, Mac App Store apps must run inside a sandbox. Each sandboxed app gets a private directory at ~/Library/Containers/<bundle-id>/ that acts as a miniature home folder — it contains its own Application Support, Caches, Preferences, and tmp subdirectories. This is why uninstalling a sandboxed app via Finder's Trash leaves a Containers subfolder that is often as large as the app's entire data footprint.

Group Containers (~/Library/Group Containers/) hold data shared across a developer's family of apps — think iWork sharing data between Pages and Numbers, or Microsoft sharing fonts across all Office apps. Be conservative here: deleting a Group Container folder while any member app is installed can corrupt shared state or break iCloud sync.

LaunchAgents and LaunchDaemons: Background Ghosts

Many apps register a background service to enable auto-updates, helper processes, or menu-bar agents. These live as .plist launchers in:

• ~/Library/LaunchAgents — per-user, loaded at login
• /Library/LaunchAgents — system-wide, loaded at login for all users
• /Library/LaunchDaemons — system-wide, loaded at boot (runs as root)

When you remove an app without properly uninstalling it, its launcher plist stays. macOS will attempt to start the referenced binary every login and log an error when it is missing. To list all user launch agents:

launchctl list | grep -v com.apple

Entries showing a PID of - and a non-zero exit code usually indicate a ghost — the binary is gone but the plist remains.

Saved Application State: Easy Wins

~/Library/Saved Application State stores each app's window arrangement so macOS can restore it after a relaunch. Each app gets a bundle-ID-named folder here. These are safe to delete entirely; apps recreate them on next launch. The folder rarely exceeds a few hundred megabytes even on a heavily used system, but cleaning it resolves the occasional "app opens with wrong windows" quirk.

App Leftover Files Mac Location: Putting It All Together

When you manually hunt for app leftover files after uninstalling an app, you need to check all of these paths for the app's bundle ID (e.g. com.spotify.client):

1. ~/Library/Application Support/<AppName or BundleID>
2. ~/Library/Caches/<BundleID>
3. ~/Library/Preferences/<BundleID>.plist (and variants)
4. ~/Library/Containers/<BundleID>
5. ~/Library/Group Containers/<Group prefix>
6. ~/Library/LaunchAgents/<BundleID>*.plist
7. ~/Library/Saved Application State/<BundleID>.savedState
8. /Library/Application Support/<AppName> (system-wide)
9. /Library/LaunchAgents and /Library/LaunchDaemons (system-wide)

That is nine locations per app, multiplied by however many apps you have uninstalled over the years. Doing this by hand for a single app takes five to ten minutes; for a dozen apps it becomes a research project.

This is exactly what Crumb automates: its Uninstall tab looks up an app's bundle ID and scans all these paths simultaneously, presenting every leftover as a checklist so you can review and remove them in one pass rather than Terminal-hopping across nine folders. If you are unsure whether a particular subfolder is safe to remove, Crumb's built-in "Is this safe to delete?" check explains the folder's purpose and risk level in plain language.

What Is Never Safe to Delete

• Containers or Application Support for apps you still use. You will lose local data — documents, offline databases, licence state — that may not be recoverable.
• Active LaunchDaemons. System services like VPN clients, cloud sync agents, and printer drivers depend on these. Removing them without a proper uninstaller breaks the service.
• Group Containers for Apple apps (group.com.apple.*). These back iCloud Drive, iMessage, Photos, and other system features.
• Anything inside /System/Library. This is protected by System Integrity Protection (SIP) on macOS 11+ and should never be touched manually.

Cleaning is permanent. If you are not certain what a folder is, check before you delete — not after.

Conclusion

macOS's modular storage model is well-designed for security and updatability, but it makes manual cleanup genuinely tedious. Now that you have a complete map — Application Support, Caches, Preferences, Containers, Group Containers, LaunchAgents, Saved Application State — you can approach any cleanup with confidence, knowing what each location holds and what risk a deletion carries. For the cases where you want all nine paths checked in seconds rather than minutes, download Crumb and let its Uninstall scanner do the bundle-ID matching for you.