Uninstall Mac Apps Installed from a .pkg Package
An app that arrived as a .pkg installer is not the same thing as an app you dragged out of a disk image. The installer ran as root, it could write wherever the package told it to, and it left a record of what it installed in the Installer's receipt database. Dragging the app to the Trash removes one of the folders that record lists and leaves the rest, including the record itself. This article is about that case: how to tell a package installed the app, how to read what it put on disk, what to remove and what to leave. If Finder refuses outright, or the app comes back after you delete it, start with when a Mac app will not uninstall instead, and for an app you dragged in yourself, the complete uninstall guide covers the usual path.
Why the Trash is not enough
A package can put files next to the app, not only inside it. When I reinstalled a batch of apps from their official installers and removed them again, the official Zoom package left three launchd jobs and a privileged helper, us.zoom.ZoomDaemon, outside zoom.us.app. Logi Options+'s installer also installed a second product, LogiRightSight, with its own receipt and its own launch agent. DisplayLink Manager added a launch agent to /Library/LaunchAgents. Microsoft Office installs a shared frameworks package that Word, Excel and PowerPoint all load, and Microsoft AutoUpdate plus a licensing helper come along with it. None of those move when the app bundle does.
The receipt does not move either. It lives in the Installer's own database, separate from the files it describes, so removing the app leaves pkgutil still reporting the package as installed. After a clean run of DisplayLink's official uninstaller, its two receipts were still there.
A password prompt in Finder is the other sign you are dealing with a package. The installer ran as root, so the bundle it left is owned by root, and moving it takes authentication. That is normal and is covered in the uninstall troubleshooting guide.
Check whether a package installed it
Start with the list of receipts and the app's own path:
pkgutil --pkgs | grep -i zoom
pkgutil --file-info /Applications/zoom.us.app
pkgutil --pkgs lists every package ID the Installer has recorded on the startup volume. Search for the vendor and the product name, not only the app's bundle identifier, because the two often have nothing in common. Zoom's app is us.zoom.xos and its receipt is us.zoom.pkg.videomeeting. The receipt that installs Cookie.app is app.fantasticthing.Bookkeeping. Even the case can differ: 爱思助手's bundle identifier is cn.i4Tools.mac and its receipt is cn.i4tools.mac, and pkgutil matches IDs exactly, so the mixed-case spelling answers "No receipt" while the receipt is sitting right there. Copy the ID from the --pkgs output rather than typing it.
pkgutil --file-info is supposed to name the package that installed a path, in pkgid: lines under the path. Do not read a missing answer as "not from a package". On macOS 27 I found it prints only volume and path for most paths, deleted or present; DisplayLink Manager's app got that empty answer while its two receipts were still on the Mac. A receipt is also not proof that you ran a .pkg yourself: the Mac App Store leaves one for some apps, such as com.apple.pkg.TestFlight.
What a receipt records
Two commands show what one package installed and where:
pkgutil --pkg-info us.zoom.pkg.videomeeting
pkgutil --files us.zoom.pkg.videomeeting
--pkg-info prints the package ID, version, volume, location and install time. --files prints paths relative to that volume and location, so the real path is the three joined together. A receipt with location Applications lists Foo.app/Contents/...; one with an empty location lists Applications/Foo.app/... instead. Read the location before you read the list, or every path you look up will be wrong.
The list includes directories as well as files. --only-files and --only-dirs split the two, which is useful once you see that a receipt can list Library and Library/LaunchAgents themselves. The raw records sit in /private/var/db/receipts as a .bom and a .plist per package, but the pkgutil manual says the location of receipt files is subject to change and to always query them through pkgutil.
A receipt is a map, not a delete list
It is tempting to feed pkgutil --files into a loop and remove everything. That is how a package uninstall breaks something else. The list says what this package wrote, not what only this package uses:
| What the list contains | Why you cannot just delete it |
|---|---|
Directories such as Applications, Library, Library/LaunchAgents |
The package created or touched them, but every other app on the Mac uses them too |
| Frameworks and helpers a vendor shares across apps | Word, Excel and PowerPoint all load Office's shared frameworks and crash at launch without them |
| Content several apps share | GarageBand, Logic Pro, MainStage and Final Cut Pro share /Library/Application Support/GarageBand, /Library/Application Support/Logic and /Library/Audio/Apple Loops, recorded under com.apple.pkg.MAContent10_* receipts |
| Another product the same installer brought | LogiRightSight came in with Logi Options+ and keeps working on its own |
| Launch agent and daemon plists | A loaded job has to be stopped before its plist goes, or launchd keeps a job with nothing on disk behind it |
The list also misses things. It records what the package's payload put on disk. Installer scripts can do more, and packages carry them: Foxit's, for example, has a postinstall script and an update service. The app writes its own data under your home Library once it runs, and none of that is in any receipt. For that side, use finding leftovers after an uninstall.
Run the vendor's uninstaller first
Apple's guidance on deleting apps is direct about this: if an app includes an uninstaller, "that's the best way to delete the app and any login items, extensions, or other data the app might have stored in other locations." Package-installed software often ships one, because the vendor knows its own scripts, helpers and shared parts. Look in the disk image the package came in, in the app's folder in Applications, in /Applications/Utilities, in the app's own menus, and on the vendor's support site. Splashtop Personal, for one, puts its uninstaller in the same disk image as the package.
If you already dragged the app to the Trash, put it back with File › Put Back, open it, and run its uninstaller from there. For security software, VPN clients and drivers the vendor's tool is not optional: extensions and network filters only come down through the app that owns them, which uninstalling antivirus on Mac covers.
Removing it by hand
When there is no uninstaller, the receipt tells you where to look. Work from it in this order:
- Quit the app and anything it runs in the background.
- Read
--pkg-infofor the location, then--filesfor the list, and write down the paths outside the app bundle. - For each launch agent or daemon in the list, unload the job with
launchctl bootoutbefore moving its plist. The launchd section of the troubleshooting guide explains why the order matters. - Move to the Trash only what clearly belongs to this product: the app bundle, folders and plists named after its bundle identifier or product, its helper in
/Library/PrivilegedHelperTools. Leave shared parent folders and anything the vendor's other apps still use.pkgutil --pkgs | grep -i vendornameshows whether other packages from the same vendor are still installed; if they are, their shared frameworks stay. - Forget the receipt last, once nothing it lists is left:
sudo pkgutil --forget com.vendor.pkg
--forget discards the receipt and, in the manual's words, does "not touch the installed files". Running it first leaves every file in place with no record pointing at them, which makes the rest of this job harder. It needs sudo because /private/var/db/receipts is owned by root, and it needs the ID exactly as --pkgs spells it. A stale receipt holds no user data, so if you are unsure whether something it lists is still in use, leaving the receipt costs nothing.
Checking the result
These commands only read. Replace com.vendor.pkg and vendorname with what you found above:
id=com.vendor.pkg
loc=$(pkgutil --pkg-info "$id" | sed -n 's/^location: //p')
pkgutil --files "$id" --only-files | while IFS= read -r f; do
p="/${loc:+$loc/}$f"
[ -e "$p" ] && echo "$p"
done
pkgutil --pkgs | grep -i vendorname
ls /Library/LaunchAgents /Library/LaunchDaemons /Library/PrivilegedHelperTools | grep -i vendorname
launchctl list | grep -i vendorname
launchctl print system | grep -i vendorname
The loop prints every file from the receipt that still exists, with its full path. No output means the payload is gone and the receipt is safe to forget. Output inside the app bundle means the app is still installed; output elsewhere is what the removal missed, or what you decided to keep because another app shares it. If pkgutil answers "No receipt for ... found", the receipt is already forgotten or the ID is spelled differently. The ls and launchctl lines catch helpers the receipt never listed. launchctl list shows your own agents and launchctl print system shows the daemons. Any line from either means the job is still loaded, and a nonzero number in its first column means it is running now.
How Mole handles pkg-installed apps
When you remove an app in Mole, it reads the receipts whose names match the app's bundle identifier or product name and lists the paths from them that still exist, but only inside a narrow set: the app bundle in Applications, and under /Library only the Application Support, Caches, Logs, PrivilegedHelperTools, WebKit and HTTPStorages folders, plus Preferences, LaunchAgents and LaunchDaemons plists, named with that exact bundle identifier. Those rows arrive unchecked, so you tick each one after reading it. Paths under /Users, /opt, /usr and /private never become rows from a receipt, and neither do the receipt files themselves.
After the app is gone, Mole forgets the receipt named after its bundle identifier, using the spelling pkgutil has on disk, and a vendor receipt it finds through pkgutil --file-info, the latter only when none of the files that receipt lists still exist. It does this only when the administrator helper was already authorized for that removal, so it never raises an extra password prompt for a receipt. The vendor lookup skips Apple's com.apple.* receipts.
The limit is the one described above. Because pkgutil --file-info rarely answers on macOS 27, a receipt whose ID has nothing to do with the app can stay after Mole removes it, as DisplayLink's two and Zoom's did. They are records only, and sudo pkgutil --forget clears them. For drivers, VPN clients and security software, Mole is not a substitute for the vendor's uninstaller.
FAQ
Does pkgutil --forget uninstall the app?
No. The manual says it discards all receipt data for the package but does not touch the installed files. Run it after the files are gone, never instead of removing them.
Can I delete every file pkgutil --files lists?
No. The list includes system directories such as Library and Applications, frameworks the vendor's other apps load, and plists for jobs that may still be running. Use it to find what to review, then remove what belongs only to this product.
The app is gone, but pkgutil --pkgs still lists it. Is it still installed?
Not necessarily. Deleting files never updates the receipt, so it stays until someone forgets it. Run the check loop above: if nothing the receipt lists still exists, only the record is left and sudo pkgutil --forget removes it.