the app is gone. its eighteen folders are not.

the built-in way to uninstall an app on Mac

there is no uninstaller in macOS, and not on the command line either: nothing in /usr/bin or /usr/sbin has «uninstall» in its name, and the installer tool that puts packages on the disk has no option that takes them off again. Apple's own instruction is two lines — look inside the app's folder for an Uninstaller the developer supplied, and if there isn't one, drag the app to the trash. leftovers are not mentioned.

Apple's instruction, in full, is here: install and uninstall other apps — Mac User Guide

the easy case first. an app from the App Store is sandboxed, so nearly everything it has sits in one folder in ~/Library/Containers, and deleting the app plus that folder is the whole job. the same app downloaded from the developer's own site is not sandboxed and does not behave this way.

the two builds differ in more than this: the same app, two versions

everything else runs on a naming convention: most of what an app leaves behind is named after its bundle identifier — com.company.appname — and most of it is under your own Library. that turns «hunt through the system» into «look in eleven folders for one string».

find the bundle identifier

1. quit the app, and check it is not also a login item: System Settings → General → Login Items & Extensions.
2. right-click the app → Show Package Contents → Contents → Info.plist, and read CFBundleIdentifier. that string is what you will be searching for.
3. in Finder press ⇧⌘G and go to ~/Library.
4. check these eleven by name: Application Support, Containers, Group Containers, Caches, Logs, HTTPStorages, WebKit, Preferences, Saved Application State, Application Scripts, LaunchAgents.
5. then the system side, behind an admin password: Application Support, LaunchDaemons, LaunchAgents, PrivilegedHelperTools, Extensions and Frameworks under /Library — plus /var/db/receipts.
6. move what matches to the trash — with the app itself — and empty it once you are sure the removal was a good idea.

what the identifier is and why apps are named that way: CFBundleIdentifier — Apple developer documentation

pkgutil --forget does not delete anything

half the instructions on the web reach for pkgutil at this point, so here is exactly what it does. an installer package leaves a receipt in /var/db/receipts — a record of what it wrote and where. pkgutil --forget discards that record and does not touch a single file the package installed.

you can watch it happen: build a package that installs one file, install it, run --forget on its identifier, and the file is still there after macOS has stopped believing it was ever installed. that makes it the fix for one thing — an installer refusing to reinstall because it thinks a version is present. as a way to remove an app, it removes the bookkeeping and leaves the app.

the wording is «discard receipt data», and the manual page says so: pkgutil(1)

one caution before you empty anything: ~/Library/Application Support is also where apps keep the things you made — a licence key, a local database, years of notes. read the folder before you drag it.

why a manual uninstall misses things

when the folder is not named after the app

the convention is a convention, not a rule, and the biggest folders are the ones that break it. searching your Library for com.google.Chrome finds exactly one thing — a preferences file of about two kilobytes. the eleven gigabytes are in ~/Library/Application Support/Google/Chrome, named after the company, and Drive and the updater share that folder, so dragging «Google» to the trash takes them with it.

Zoom is the same story with more pieces. of twenty-two leftover items on a Mac that has it installed, six are named after us.zoom.xos and sixteen are not — ZoomUpdater, ZoomChat, ZoomPhone, a group container behind a team id, preference files for helpers with names of their own. search for the identifier and you find under a third of it.

the gigabytes a cleaner reports are not all the same kind of thing: what the space a cleaner finds is made of

what Terminal cannot see without full disk access

the shell scripts that promise to clear leftovers in one command have a problem they rarely mention. a Terminal without Full Disk Access cannot read ~/.Trash, ~/Library/Mail, ~/Library/Safari, the MobileSync folder holding iPhone backups, or Safari's container — each answers «operation not permitted», while Preferences, Caches and Containers in the same Library read normally. a script does not stop at that: it reports what it found, having never looked at the protected half.

which folders are protected and where the permission lives: control access to files and folders on Mac

• some of it needs an admin password — /Library/LaunchDaemons, /Library/PrivilegedHelperTools, kernel and system extensions. a helper left running there is why a deleted app still appears to be doing something, and its receipt in /var/db/receipts keeps macOS believing a version is installed.
• apps you removed years ago left folders you will never think to search for, because you have forgotten they existed. that is where the surprising number of gigabytes usually is.

so: an App Store app is two drags, and there is nothing here worth a tool. the simple case ends the moment the app came from the developer's site — from there the identifier stops naming the folders, the Terminal stops seeing all of them, and «did I get it all» is a question you cannot answer by looking.

and if the disk filled up with something other than apps: what system data is using

how hop uninstalls an app with its leftovers

drop an app on hop's uninstall row, or pick it from the list of everything installed, and it goes together with what it left in about thirty places — application support, caches, preferences, containers, launch agents, plug-ins, receipts and the rest. every app in the list shows what it weighs, the bundle and its data apart, so «what will this free» is answered before you decide.

• nothing is deleted. everything moves to the Trash, so a mistake costs a restore rather than a file — unlike a cleaner that reports a number and moves on. an uninstaller that silently succeeds on everything is lying to somebody.
• an app already sitting in the Trash is still recognised — its identifier is read from the bundle there, or worked out from the leftovers — so a half-finished removal can be finished.
• what it deliberately leaves alone is listed too — a container where cache and data share one folder, a messenger's twenty gigabytes among them, since only that app's own cleanup knows which half is disposable.

what the module does and what it asks for: the app uninstaller

why a small utility asks for permissions at all: why Mac apps ask for accessibility

when the uninstall does not go cleanly

• the app came with its own uninstaller. antivirus, vpn clients, virtualisation and anything with a driver or a system extension must go through their own tool — dragging those to the trash leaves a running daemon and no way to reach it. Apple says to check the app's folder for one first, and on this it is right.
• it was installed by your employer through a management profile. it will come back, and removing it is a conversation rather than a task.
• the app refuses to move to the trash at all. that is a different problem with different causes.
• you deleted something and lost a licence or a project. this is why the Trash is the destination and not the target — restore first, look again after.
• you are removing an app to free space, and it is 200 mb. the space is elsewhere: caches, installers and old backups, not the applications folder.

if the app itself will not go: an app that will not delete

frequently asked questions

is dragging an app to the trash enough?

it removes the program itself, which is why the Mac stops running it. the settings, caches and support data stay, and on a machine a few years old that is a real amount of disk.

where do leftover files live on a Mac?

eleven folders under ~/Library — Application Support, Containers, Group Containers, Caches, Logs, HTTPStorages, WebKit, Preferences, Saved Application State, Application Scripts, LaunchAgents. the rest sits in the system Library and /var/db/receipts, behind an admin password.

does pkgutil --forget uninstall an app?

no. it discards the installer's receipt from /var/db/receipts and leaves every file that receipt described — install a test package, forget it, and the file is still on disk. it is the fix for an installer that refuses to reinstall, not a way to remove anything.

do i need a cleaner app to uninstall properly?

no. you need the bundle identifier and a list of folders, and for an App Store app it is two drags. it stops being simple when the folders are not named after the identifier — Chrome's eleven gigabytes sit under a folder called «Google» that Drive shares.

does hop delete the files permanently?

no — everything moves to the Trash, including the leftovers. that is deliberate: the failure mode of an uninstaller is removing something you needed, and it should cost a restore, not a file.

why is an app still listed after i deleted it?

usually a receipt or a login item that outlived the bundle. clearing the receipts and checking Login Items & Extensions settles both; a reboot alone does not.

the tool behind this

done with uninstall apps

other things people do

• the app will not go in the trashapp uninstaller
• system data: 180 gb, contents unspecifiedapp uninstaller
• the app is gone. its system extension is still there.app uninstaller