# Mac Uninstall Leftovers: Review Before You Delete > Leftover scanners disagree because ownership rules differ. Use path review, separate sizes, and opt-in personal data before anything sensitive is removed. Published: 2026-09-09 Dragging an app to Trash removes the bundle you can see. It does not automatically settle the question of preferences, Application Support folders, group containers, helpers, or install receipts. Those leftovers are why two "uninstallers" can disagree: they are not measuring the same ownership rules. The safe habit is not "delete everything with a similar name." It is "show the candidates, separate sizes, and require a deliberate choice before anything sensitive goes away." For the broader leftover map after an app is already gone, see [how to remove leftover files after uninstalling Mac apps](https://mole.fit/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps). For the full remove-while-running sequence, see [how to completely uninstall apps on Mac](https://mole.fit/blog/how-to-completely-uninstall-apps-on-mac). This guide focuses on the review step itself. ## What a leftover list is actually claiming A remnant scanner is making three claims at once: 1. **Attribution:** these paths belong to the app you removed (usually by bundle identifier, not by folder name). 2. **Safety:** deleting them will not take down another app that still shares the path. 3. **Completeness:** interesting residue was considered, even if some of it must stay selected off by default. If any claim is weak, a longer list is worse than a shorter one. Size alone is a terrible ownership signal. A 12 GB folder under Application Support might be a disposable cache, a local photo library, or a shared media store. ## Layers you should expect to see | Layer | Examples | Default posture | |---|---|---| | App bundle | `/Applications/Example.app` | Remove with Trash or the package manager that owns it | | User support | `~/Library/Application Support`, Preferences, Caches, Containers, Group Containers | Review by bundle id; delete only what you accept | | Installer / updater residue | leftover pkg receipts, Sparkle leftovers, background updaters | Clear when they belong to the removed install | | Privileged helpers | LaunchDaemons, privileged helpers, kernel extensions, network extensions | Prefer the vendor uninstaller; do not force with a generic tool | | Shared media | photos, downloads, or documents referenced by more than one app | Show for review; never preselect | Apple still points people at vendor uninstallers when system-level pieces are involved ([Delete or uninstall apps](https://support.apple.com/102610)). A consumer leftover cleaner that quietly removes privileged helpers is not being thorough. It is being reckless.
An app bundle and its support files, caches, preferences and background items linked by bundle identifier
Identify which app owns each file, then review it before moving it to Trash. Shared and privileged components need separate checks.
## Review before delete: a checklist that survives bad tools Use this order whether you work by hand or with an uninstaller UI: 1. **Confirm the app is the one you meant.** Duplicate names are common; bundle identifier is the real key. 2. **Separate app size from leftover size.** Knowing that the bundle was 400 MB and the residue is 90 MB changes how carefully you read the list. 3. **Expand paths, do not trust labels alone.** Open the parent in Finder when a row is ambiguous. 4. **Leave browser profiles, chat databases, and license files unchecked unless you intend to erase them.** Personal data should be opt-in. 5. **Skip anything another running app still has open.** In-use files are a stop sign, not a challenge. 6. **Watch for "Empty" temporary folders.** They are low risk once attributed, but they are still a review item, not automatic deletion theater. 7. **If you reinstall or restore the app mid-cleanup, stop.** Continuing can delete the new install's support files. That last rule matters more than most marketing copy admits. An uninstaller that keeps going after the app reappears is optimizing for a demo, not for your disk. ## Manual review without a dedicated tool When you prefer Finder and Terminal: ```bash # List likely user-level residue by bundle-style name (example) ls ~/Library/Application\ Support | grep -i example ls ~/Library/Preferences | grep -i example ls ~/Library/Caches | grep -i example ``` Replace `example` with a distinctive piece of the vendor or bundle id. Then: - Prefer moving candidates to Trash over `rm -rf`. - Quit the related app and its helpers first. - Leave `/Library` and `/System` alone unless a vendor document names the exact path. - Do not delete a Group Container because one of two owners is gone. If Homebrew installed the app, uninstall with Homebrew so receipts and related cask artifacts stay consistent. Mixing Trash deletion with a live cask is how reinstalls get blocked later. ## Shared and sensitive data deserve slower clicks Some rows look like leftovers and are not: | Looks like junk | Often actually is | Safer action | |---|---|---| | Large "support" folder | Offline mail, notes, project packages | Keep unless you can name a rebuild source | | Browser folder under Containers | Profiles, cookies, payment methods | Opt-in only; never bulk-select | | Chat or IM media directory | Local history and attachments | Keep; clear inside the chat app if needed | | Unity or game data folder | Projects or downloaded assets you may still want | Review path-by-path | | License or certificate files | Activation state | Keep unless you are deliberately de-authorizing | A good leftover UI will show these, explain sizes, and refuse to remove sensitive or in-use items even if you try. A bad one will preselect them because they inflate the "reclaimed" number. ## Where Mole fits Mole's Uninstall flow is built around that review contract. Duplicate apps are not listed twice. Leftovers are listed by path, with app size and leftover size shown separately. Empty temporary folders are marked Empty. Browser personal data has to be selected by hand. Shared media can appear for review without being preselected. Sensitive data and files another app still uses are not removed. If an app is restored or reinstalled while leftovers are being cleared, Mole stops before touching the new installation. After you uninstall somewhere else, Mole can wait for leftovers to settle and then explain sizes and skips instead of guessing. That is the difference between a remnant scanner and a cleanup you can defend later. When you want the taxonomy of Library folders and command-line measurement, continue with [leftover files after uninstall](https://mole.fit/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps). When you are choosing tools, [AppCleaner alternatives](https://mole.fit/blog/appcleaner-alternative) covers the product landscape without pretending every scanner shares the same safety rules. ## FAQ ### Why do leftover scanners disagree? They use different ownership rules, refuse lists, and privilege boundaries. Disagreement is expected. Prefer the tool that explains skips over the one that always reports more deleted bytes. ### Should I delete everything under Application Support for an app name? No. Match bundle identifiers, open ambiguous paths, and keep shared or personal data unchecked unless you intend to erase it. ### Is Trash enough for App Store apps? Trash removes the bundle you dragged. Support files can remain. Launchpad or Move to Trash from Launchpad follows Apple's usual consumer path; deep residue still needs a review if you care about it. ### Can leftovers block a reinstall? Sometimes. Stale receipts, background updaters, or Homebrew metadata can interfere. Cleaning those with attribution is useful; deleting unrelated packages to "make room" is not. --- Canonical HTML page: https://mole.fit/blog/mac-uninstall-leftovers-review-before-delete Blog index for agents: https://mole.fit/blog/llms.txt Site index for agents: https://mole.fit/llms.txt