Klaar: Removing macOS Apps and What They Leave Behind
Dragging an app to the Trash removes the app. Klaar removes the rest of it — including developer toolchains.
Deleting a macOS application by dragging it to the Trash removes the .app bundle and nothing else. The preferences, caches, support files and logs it created over months of use stay exactly where they are. Klaar finds those and removes them with the app.
Why anything is left behind at all
This is a consequence of how macOS apps are designed, not a flaw in the Finder. An application bundle is self-contained and read-only in normal use, so everything an app needs to write goes elsewhere — conventionally under your Library folder:
| Location | Typically holds |
|---|---|
~/Library/Preferences | Settings, as .plist files |
~/Library/Application Support | Databases, user data, plugins |
~/Library/Caches | Cached downloads and thumbnails — often the largest |
~/Library/Containers | Everything, for sandboxed App Store apps |
~/Library/LaunchAgents | Helpers set to start at login |
~/Library/Saved Application State | Window positions and restored state |
Sandboxed apps are tidier: nearly everything lives in one container folder named after the bundle identifier. Apps distributed outside the App Store are under no such obligation and scatter more widely — which is precisely when a remover earns its keep.
The LaunchAgent problem
The leftovers that matter are not the ones taking up space. A LaunchAgent or LaunchDaemon left behind by a deleted app is a job macOS still tries to run at login, pointing at a binary that no longer exists. It is a small persistent error, and in the case of updaters and helper tools it can be a process still running long after you believed the app was gone.
Finding those by hand means knowing they exist and knowing where to look, which is the gap this kind of tool fills.
Developer toolchains
Klaar also handles developer toolchains, which are the extreme case of the same problem. Toolchains install compilers, SDKs, simulators, package caches and command-line tools across multiple locations, and the volumes involved are large — simulator runtimes and derived-data folders routinely reach tens of gigabytes. Removing the visible application recovers almost none of it.
What a remover cannot do
Worth being straight about. Matching files to applications is inference: it works from bundle identifiers, names and install records, and shared components are genuinely ambiguous — a framework used by two apps should not be removed with the first. Anything installed by a package installer with a preinstall script can put files anywhere it likes.
So a remover should be treated as a tool that finds candidates for you to confirm, not an oracle. Reviewing the list before removing is the correct workflow for any tool in this category, this one included.
Why a direct download
Klaar ships as a disk image rather than through the Mac App Store. The reason is structural: App Store apps are sandboxed and cannot reach into other applications' support directories — which is the entire job here. The sandbox that makes KOCaffeine a natural App Store app is what rules it out for this one.
A disk image is the standard format for macOS software distributed outside the store: mount it, drag the app to Applications, eject.