How to completely uninstall an app on Mac

Dragging an app to the Trash only removes the app bundle — the single .app file. It does not touch the app's preferences, caches, saved state, license data, or any background helper it installed. For a simple utility that's rarely a problem: a few kilobytes of orphaned settings never hurt anyone. For anything that syncs data, runs a background agent, or installs a helper tool — think backup software, VPN clients, virtual machines, or old antivirus apps — the leftovers can run into hundreds of megabytes, and in a few cases (orphaned launch agents, stuck background helpers) they can keep doing things after you think the app is gone.

This guide walks through every Library location apps actually write to, in the order worth checking, with the exact paths. It also covers the one detail most quick-tip articles skip: how to tell which files are genuinely safe to remove versus which just happen to share a name with the app you're deleting.

Why Trash-only removal leaves files behind

macOS doesn't have a built-in "uninstall" command the way Windows does. An app is just a folder — the .app bundle — that Finder displays as a single icon. When you install an app, it's free to write files anywhere it has permission to write, and nearly every well-behaved app does, because that's where your settings, license, cache, and history are supposed to live. When you delete the bundle, none of that gets cleaned up automatically, because macOS has no record that a given preferences file belongs to that one app and nothing else. The file system doesn't track "owned by this app" the way it tracks "owned by this user."

What the file system does track — and what makes reliable cleanup possible at all — is the bundle identifier: a reverse-DNS string like com.adobe.Photoshop or com.spotify.client, baked into the app's Info.plist at build time. Developers are supposed to name their support files, caches, and preferences after this identifier specifically so tools (and users) can find everything that belongs to one app without guessing. It's the closest thing macOS has to a package manifest — the difference between "I found a folder with a similar name" and "I found the exact file this app wrote."

You can check any installed app's bundle ID in Terminal without opening it:

mdls -name kMDItemCFBundleIdentifier /Applications/Slack.app

That single string is what you'll be matching against in every Library folder below.

The manual walkthrough: where apps leave files

All of these live under your user Library, which is hidden by default. The fastest way in: open Finder, press Shift+Command+G, and type the path. You can also hold Option while clicking Finder's Go menu to reveal Library as a visible menu item for the rest of the session.

~/Library/Application Support/

This is where most apps keep their real data: settings that don't fit in a simple preferences file, downloaded resources, local databases, license files, plugins. Look for a folder named after the app or its developer — for example ~/Library/Application Support/Spotify. This is usually the single largest leftover for apps that store any real content locally: Slack's cached message history, a video editor's project cache, that kind of thing.

~/Library/Caches/<bundle-id>

Temporary, regenerable data — thumbnails, downloaded assets, compiled shaders, web caches for Electron-based apps. Folders here are almost always named exactly after the bundle ID, such as ~/Library/Caches/com.spotify.client, which makes this one of the easiest locations to match with confidence. Safe to delete for any app you're removing, and safe to clear periodically even for apps you're keeping, since caches rebuild themselves.

~/Library/Preferences/<bundle-id>.plist

A single small file holding the app's settings — window positions, toggles, your last-used options. Usually a few kilobytes to a few hundred kilobytes. This is the one location where it's genuinely fine to leave things behind if you're not sure: a stray .plist costs you nothing in disk space and can't run any code on its own. Delete it if you want a completely clean reinstall (some apps misbehave after an update until their old prefs are cleared); leave it if you're just being thorough.

~/Library/Containers/<bundle-id>

Apps distributed through the Mac App Store — and increasingly, direct-download apps too — run inside a sandbox. Everything the app is allowed to touch lives inside one self-contained folder here, including its own private copies of Application Support, Caches, and Preferences. This is the good case: removing one folder removes essentially everything that app ever wrote, because sandboxing forces the developer to keep it contained. If ls -la ~/Library/Containers/ shows a folder matching the app's bundle ID, that one folder is close to a complete uninstall by itself.

~/Library/Group Containers/ — the shared-folder caveat

Group containers are shared storage a developer sets up so their own family of apps — or an app and its extensions and widgets — can exchange data. The folder name is usually a team-ID-prefixed group identifier, not a single app's bundle ID (something like ABCDE12345.com.developer.shared). This is the one location where deleting on sight is a mistake. If a developer ships three apps that all read and write the same group container, removing one app and deleting the shared container breaks the other two. Only remove a group container if you're removing every app from that developer that could plausibly be using it — and if you're not certain, leave it. A few hundred MB in an unused group container is a much smaller problem than an app you meant to keep suddenly losing its data.

~/Library/Saved Application State/<bundle-id>.savedState

This is what lets an app reopen its windows exactly as you left them after a restart. Purely cosmetic, safe to delete, and it regenerates the next time you use the app if you keep it installed. Named directly after the bundle ID, so matching is unambiguous.

Launch agents and daemons — the parts that keep running

Some apps install a small background helper that starts independently of the main app: an updater, a menu-bar helper, a sync agent. These are declared in small XML files (.plist) in one of three places, and this is the leftover category most likely to actually do something after you think you've uninstalled the app:

• ~/Library/LaunchAgents/ — runs as your user, started on login. User-writable, so most third-party helpers land here.
• /Library/LaunchAgents/ — also runs as your user, but installed system-wide, affecting every account on the Mac. Requires admin rights to install, which is a sign the app used an installer package rather than a drag-and-drop copy.
• /Library/LaunchDaemons/ — runs as root, with no user logged in required. Real background services live here: VPN clients, backup tools, virtualization software. If an app you're removing had a "helper" or asked for a password during install, check here.

File names in all three follow the same bundle-ID convention, such as com.developer.appname.helper.plist, so once you know the bundle ID you're matching a specific file, not guessing from a list. You can check what's actually loaded before touching anything:

launchctl list | grep com.developer.appname

If something shows up, unload it before deleting the file — launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.developer.appname.plist for a user agent; daemons need sudo and the system-wide path. Deleting the plist file without unloading the running process first just means it keeps running until the next login or reboot.

~/Library/Logs/<bundle-id or app name>

Diagnostic text logs. Harmless, occasionally sizeable for apps that log verbosely (build tools, VPN clients), always safe to remove.

Login Items & Extensions: the part people forget after the app is already gone

Even after you've deleted the app bundle and every file above, macOS can still show an entry for it in System Settings > General > Login Items & Extensions. Two things live here that outlast the app itself:

• Login items — things set to open automatically when you log in. A yellow warning triangle next to an entry means the app it points to no longer exists; that's a dead login item, safe to remove with the Remove button.
• "Allow in the Background" toggles — permissions the app was granted to run tasks even when it isn't open. Removing the app bundle doesn't always revoke this immediately; you may still see the app's name listed with the toggle enabled for a while. It's inert once the app's files are gone — there's nothing left for the permission to apply to — but if it bothers you, it's a one-click toggle to turn off from the same screen.

Apple's own instructions for this screen: Change Login Items & Extensions settings on Mac.

Does it matter how you installed the app?

Yes — the install method predicts where the leftovers will be.

App Store apps are sandboxed by definition, so nearly everything lives inside one Container folder — usually the cleanest case: delete from Launchpad or Trash, then remove the matching Container folder by bundle ID for a fully clean sweep.

Direct-download apps (a .dmg you drag to Applications) are a mixed bag. Many sandbox themselves voluntarily and behave like App Store apps; others — especially cross-platform apps built with Electron — scatter files using a plain folder name instead of the bundle ID, which makes them slightly more annoying to track down, though the locations are the same ones above.

Apps with their own uninstaller are worth checking for before doing anything manually. Look inside the original .dmg or installer package for an app named "Uninstall [App Name]," or check the developer's support site — Adobe, Microsoft Office, VMware Fusion, and most antivirus tools ship one because their installers put files in places a Trash drag won't reach. Run the vendor's uninstaller first, then check the Library locations above for stragglers.

.pkg-installed apps are the case simple Trash-drag advice handles worst. A .pkg installer can write anywhere on the system — commonly /Library/Application Support/, /Library/LaunchDaemons/, and for command-line tools, /usr/local/ or /opt/. macOS keeps a receipt of exactly what it put where:

pkgutil --pkgs | grep -i appname
pkgutil --files com.developer.appname.pkg

That second command lists every file the installer placed — the most complete leftover map you can get for a .pkg-installed app without a third-party tool.

Two honest caveats before you start deleting

A stray preferences file is not worth the risk of guessing wrong. The most common mistake in manual uninstalling isn't leaving files behind — it's removing a folder because its name resembles the app, without confirming it's the right bundle ID. A generic developer-name folder can be shared by several of that developer's apps; deleting the whole thing to uninstall one of them can quietly break the others. When you're not sure a file belongs exclusively to the app you're removing, the correct move is to leave it. A few hundred KB of orphaned settings is a rounding error. A shared file removed by mistake is not.

Root-owned files from a .pkg install may refuse to move to Trash. If Finder gives you a permission error trying to trash something a .pkg installer placed in /Library/ or /usr/local/, that's usually because the file is owned by root, not your user account. You'll need admin authentication to move it — and if it's a LaunchDaemon that's currently loaded, you need to unload it with sudo launchctl bootout before removal will stick. This is exactly the situation SwoopByte Uninstaller's privileged-helper flow is built for: elevated removal stays Trash-only even when root ownership is involved, so a hard-to-move file doesn't tempt you into a permanent rm from Terminal instead.

The faster path: what SwoopByte Uninstaller checks for you

Everything above is the manual version — accurate, but a dozen folder trips and a few Terminal commands per app. SwoopByte Uninstaller's free tier automates the bundle-ID matching described in this guide: it lists your installed apps, and removing one shows a full leftover preview grouped by confidence — exact bundle-ID matches pre-checked, name-only matches (the shared-developer-folder problem above) shown but never pre-checked, so you make the judgment call on anything ambiguous instead of the app guessing for you. Everything moves to Trash, nothing is deleted outright, and a recently-removed list means an app you change your mind about is one click from back.

The free tier covers the case in this guide end to end. Pro ($12.99, one time, no subscription) adds two things beyond single-app removal: a Leftover Finder that scans for orphaned files from apps you already removed by hand or with a different tool, and removal of entire developer toolchains — Homebrew, Node.js, nvm, pyenv, Rust, Docker — that Trash-drag uninstalling was never going to touch, since those aren't single .app bundles at all.

FAQ

Does dragging an app to the Trash uninstall it completely?

No. It removes the app bundle only. Preferences, caches, application support files, and any background helper the app installed stay behind until you remove them separately.

Is it safe to delete every folder with the app's name in Library?

Not automatically. Match by the app's exact bundle identifier, such as com.developer.appname, not by a name that merely looks similar — some folders are shared by several apps from the same developer, and a name-only match can belong to something else entirely.

What is a Group Container, and can I delete it?

A Group Container is storage shared between several apps or extensions from the same developer. Only delete it if you're removing every app that developer makes on your Mac — otherwise you risk breaking an app you intend to keep.

Why does System Settings still show an app I already deleted?

Login Items & Extensions (System Settings > General) can keep a stale entry — a dead login item, shown with a warning triangle, or a leftover "Allow in the Background" toggle — after the app's files are gone. It's inert at that point; remove it from that screen if you want it off the list too.

Is AppCleaner enough to fully uninstall an app?

For simple, unsandboxed apps, often yes — it catches the common Application Support, Caches, and Preferences pattern. It doesn't group matches by confidence the way a bundle-ID-first tool does, so double-check any name-only match it finds before confirming, and it won't help with dev-toolchain removal (Homebrew, Node, Docker) since those were never single app bundles.

Related guides