Guide
How to uninstall apps completely on a Mac
By Maulik Dave · Updated
Dragging an app to the Trash removes the app, not the files it created. Usually that’s fine: leftovers are small. Sometimes they hold gigabytes, or a background job that keeps running. Here is how to find them by hand, and what to leave alone.
Step 1: Use the app’s own uninstaller if it has one
Apps that install drivers, system extensions, VPNs, security software or background services often ship an uninstaller. Look in the app’s menu, in its installer disk image, or on the developer’s support pages. It knows exactly what it installed, including parts outside your Library folder. Use it before anything else.
For App Store apps on macOS 14 and 15, Apple’s guide says to use Launchpad: hold an icon until it jiggles and click the delete button. macOS 26 Tahoe and later have no Launchpad; Apple’s guide for those versions opens apps from the Apps icon in the Dock, and its uninstall steps are to look for an uninstaller in the app’s folder, or drag the app from Applications to the Trash, as in step 2.
Step 2: Quit the app, then move it to the Trash
Quit the app first, including any menu bar part of it. Then drag it from Applications to the Trash. If macOS says the app is in use, check the menu bar and Activity Monitor.
Before you delete it, note its bundle identifier: the reverse-domain name, such as com.example.Notes, that most of its leftovers are named after. In Terminal:
mdls -name kMDItemCFBundleIdentifier -raw "/Applications/Example.app"or
osascript -e 'id of app "Example"'Both only read; they change nothing.
Step 3: Know where leftovers live
Your user Library folder is hidden. In Finder, choose Go › Go to Folder… (⇧⌘G) and type ~/Library. The usual places:
| Folder | What it holds |
|---|---|
Application Support/ | The app’s data: databases, downloaded content, plug-ins. Often the largest. Named after the app, the developer or the bundle ID. |
Caches/ | Regenerable data, usually named after the bundle ID. |
Preferences/ | Settings, as <bundle ID>.plist. Tiny. |
Containers/ | The whole data folder of a sandboxed app (most App Store apps), named after the bundle ID. |
Group Containers/ | Data shared between apps from the same developer, named like TEAMID.com.example.shared. |
LaunchAgents/ | Background jobs that start when you log in, as .plist files. |
Saved Application State/ | Window positions for reopening, as <bundle ID>.savedState. |
Logs/, HTTPStorages/, WebKit/ | Logs, cookies and web data. Small, usually. |
Apps installed for all users can also leave files in /Library/Application Support, /Library/LaunchAgents and /Library/LaunchDaemons. Removing those needs an administrator password; prefer the app’s uninstaller for them.
Step 4: Search by bundle ID
This read-only command lists matching items in your Library folder, using the bundle ID from step 2:
find ~/Library -maxdepth 3 -iname "*com.example.notes*" 2>/dev/nullSearching by the app’s name catches folders named after it, but also unrelated things with similar names, so check each result. If the app came from an installer package, macOS keeps a receipt listing what it installed:
pkgutil --pkgs | grep -i example
pkgutil --files com.example.pkg.ExampleMove what you’re sure about to the Trash in Finder rather than deleting it in Terminal. If something breaks, you can put it back.
Step 5: Check login items
Open System Settings › General › Login Items on macOS 14, or Login Items & Extensions on macOS 15 and later (Apple’s guide). Remove the app from Open at Login and turn off its entry under Allow in the Background, called App Background Activity on macOS 26 and later. A leftover .plist in LaunchAgents pointing to an app that no longer exists does nothing useful, but it can show errors in the logs.
Be careful with shared folders
Some leftovers aren’t only the deleted app’s. Removing them can break, or wipe the data of, apps you still use.
- Group Containers are shared by design. If you still have another app from the same developer, leave its group container alone.
- Developer-named folders in Application Support, such as one named after the company, often serve several of its apps.
- Containers hold everything a sandboxed app saved, sometimes including documents. If you might reinstall the app, keep it or back it up.
- Similar names mislead. A folder called “Notes” may belong to a different notes app than the one you removed.
- Never remove anything inside
/System, and leave items starting withcom.apple.alone.
How Tidlark’s Uninstaller matches leftovers
Tidlark does the steps above for you, but only links a file to an app when there is evidence. Each match shows its reason:
- the file is named after the app’s bundle identifier;
- it is an app group declared in the app’s signed entitlements, or a container whose metadata names the app;
- it was installed by the same installer package, according to the macOS receipt;
- it is a background job that declares it belongs to the app, or runs a program from inside the app;
- it is a crash report of the app.
A file that only looks related by name is labelled “Unverified: only the name resembles…”. It is never pre-selected and can’t be selected in bulk; you can still tick it yourself after checking. A group container that another installed app also declares is marked as protected and can’t be selected. Apple’s own apps can’t be removed, and a running app has to be quit first.
Tidlark also finds leftovers of apps you already deleted. It only reports a bundle-ID-named item when no app with that ID is installed on any mounted drive and Spotlight can’t find one either, and nothing is pre-selected. Old installers (.dmg, .pkg, .zip) are linked to apps by the bundle ID inside them. A Reset option clears an app’s preferences, saved state and caches without uninstalling it.
Removed files go to the Trash; items that need administrator rights go to the Holding Area for 30 days. See pricing or download Tidlark.