Uninstall Mac Apps Without Losing Shared Data

Apps & MaintenancePublished Updated 5 min read

Dragging a self-contained app to Trash may be a complete enough uninstall. Other apps install helpers, drivers, system extensions, login items, shared containers, or large user databases. The goal is not to remove every filename that resembles the vendor; it is to retire the software without deleting documents or shared data that another app still owns.

Here is where they hide, how to clear them by hand, and the faster way to catch them all without guessing.

Why dragging to the Trash leaves leftovers

A Mac app is a bundle (the .app file), but most apps also write data outside that bundle the first time they run: preferences, cached data, support files, and sometimes a login item or background agent. Deleting the .app removes the program, not the trail it left across your Library folders. That trail is what people mean by app leftovers or remnants.

A Bundle ID connects the app bundle to support data, caches, preferences, containers, and launch agents before review and removal.
A complete uninstall follows the bundle identity across the app and its Library footprint, then reviews the whole set before moving it to the Trash.

For a small app the remainder may be a few harmless preferences. A browser, game, developer tool, or media app can leave gigabytes of user-controlled data. Size alone does not distinguish disposable cache from profiles, projects, messages, plug-ins, or downloaded content.

Use the vendor uninstaller first when the app changes the system

VPN clients, antivirus tools, audio drivers, virtualization software, cloud-sync clients, input-device tools, and apps with system extensions should be removed through their built-in or vendor-provided uninstaller. That workflow can deactivate extensions, unload privileged services, and remove receipts in an order that Finder cannot infer. Export settings or local data before starting, and check whether a subscription or device authorization must be released separately. Apple's uninstall guide likewise prefers an app's own uninstaller when it has one, and notes that deleting an app does not cancel its subscription or remove documents created with it.

Where app leftovers hide

Many ordinary per-user leftovers live inside your user Library folder, which is hidden by default. System-integrated software can also install items under /Library, which is one reason to use its uninstaller instead of searching system-wide. In Finder, hold Option and open the Go menu to reveal Library. The usual user locations are:

  • ~/Library/Application Support/: the app's main support data, often the largest leftover.
  • ~/Library/Caches/: cached files the app created for speed.
  • ~/Library/Preferences/: the app's settings (.plist) files.
  • ~/Library/Containers/ and ~/Library/Group Containers/: sandboxed app data.
  • ~/Library/Logs/: the app's log files.
  • ~/Library/Saved Application State/: window and session state.
  • ~/Library/LaunchAgents/: background helpers that relaunch the app or its services at login.

Sandboxed apps may keep data in a container and share it through group containers. Never remove a group container until you have identified every app and extension that uses it. Deleting it for one retired app can erase data for another app from the same developer.

Find them by bundle identifier

Leftovers are hard to match by eye because macOS names them by an app's bundle identifier, a reverse-DNS string like com.spotify.client, not by the app's display name. Get the identifier first:

osascript -e 'id of app "Spotify"'
mdls -name kMDItemCFBundleIdentifier -r /Applications/Spotify.app

Then use the identifier and vendor name as search clues:

find ~/Library -maxdepth 4 \( -iname "*spotify*" -o -iname "*com.spotify*" \) -print 2>/dev/null

Search results are candidates, not proof. Inspect each path's contents, owning app, and role. Preferences can be queried with defaults, but deleting a preference domain is optional and removes the ability to reinstall with old settings. Leave it when the space is trivial or a future reinstall is plausible.

How to remove them by hand

  1. Export unique data and confirm a current backup.
  2. Check the vendor's uninstall instructions and use them for software with helpers, extensions, drivers, or licensing state.
  3. Quit the app and its visible helper through the app or Activity Monitor.
  4. Move a simple .app to Trash, then review exact bundle and vendor matches in the Library. Separate cache from profiles, projects, databases, and shared containers.
  5. Disable remaining vendor login items through System Settings > General > Login Items & Extensions. Do not guess a launchd label from a plist filename.
  6. Restart only when a vendor extension or uninstaller requests it. Test related apps, file types, devices, and sync before emptying Trash.

This works, but it is slow and error-prone. App and developer names do not always match the folder names, sandboxed data is buried, and it is easy to delete the wrong file or miss the one that matters.

The faster, safer way

An uninstall review screen with an app expanded to show its bundle plus leftover items in ~/Library/Application Support and ~/Library/HTTPStorages, each with a size and a checkbox, and a Remove button at the bottom.
Every file an uninstall would remove, the app plus its Library leftovers, listed with sizes and checkboxes so you confirm before anything is deleted. This is Mole's uninstall review.

A dedicated uninstaller can resolve the bundle identifier and gather likely Library matches. Mole shows those candidates and sizes before removal, validates paths, and uses Trash for ordinary files. That reduces search work but does not override a vendor uninstaller or make a shared container disposable. Review remains part of the uninstall, not a decorative confirmation screen.

Under the hood: how a safe uninstaller works

Skippable, but it shows why order and validation matter here. The CLI and native app use separate implementations, but both divide the job into discovery, review, and confirmed execution. The sequence below follows the native app's path.

A safe uninstaller resolves app identity, discovers remnants, presents a review plan, waits for confirmation, stops the app and helpers, validates every path, unloads approved jobs, moves allowed items to the Trash, and records skipped or removed results
Discovery cannot delete anything. Execution starts only after confirmation, then every launch item and file path crosses the safety guard again before it is unloaded or moved to the Trash.

The bundle identifier is accepted only in reverse-DNS form before it can drive bundle-derived matching, so malformed input cannot broaden a search pattern. The scanner also reads embedded login-item identifiers from their Info.plist files instead of guessing from filenames. After you approve the complete plan, the app quits the target and stops its exact helpers. A launch item is unloaded only after PathGuard approves it, and DeletionExecutor validates every URL again before calling the Trash layer. Missing, protected, or rejected paths become explicit skips rather than partial silent deletion.

A safe uninstall rule

Use the vendor uninstaller for system-integrated software. For a simple app, remove the bundle, then review exact remnants by identity and data type. Preserve documents, profiles, databases, and group containers until ownership is proven. Leave removals in Trash while you verify related apps and services, and empty it only after the Mac still behaves as expected.