Bartender: how to uninstall it cleanly

Dragging the app to the Trash removes the binary and nothing else. The permission entries stay in System Settings, the preference files stay in the user library, and the login item registration stays wherever macOS keeps it. For a menu bar utility that is a bigger gap than usual, because this class of app writes to more places than a normal document app does. The sequence below covers what to save first, where the leftovers actually are, and how to clear the records that files alone do not cover.

Why this class of app leaves more behind

A text editor writes documents and a preference file, and that is close to the whole story. A menu bar utility works differently, because its job is to reach across into other applications and rearrange things that belong to them. Doing that requires system level permissions, a process that starts at login and keeps running, and a store of state describing every item it has ever managed. Each of those is recorded in a different place, and each survives the removal of the binary.

The practical consequence is that the visible symptom of an incomplete removal is not wasted disk space. The files involved are small. The symptom is a stale permission entry that grants access to something no longer installed, or a login item that fails silently at every startup, or a reinstall months later that behaves strangely because old state was still sitting on disk waiting to be read.

None of this is unique to any one product. Anything that manages windows, captures screen content, remaps keys, or organises the menu bar will have the same shape, and the same removal checklist applies to all of them. The identifiers change. The list of places to look does not.

Save three things before removing anything

The license key. Support offers a lookup page that emails license details back, so this is recoverable, but recovering it costs a round trip. Copying it somewhere first costs nothing. Anyone on the yearly subscription should treat cancellation as a separate decision, since removing the app does not end a subscription. The purchase page lists a fourteen day refund window, and if that window is still open, the refund question needs answering before the app disappears.

Screenshots of the settings. The support FAQ states that a version 5 configuration cannot be imported into version 6 because of platform changes underneath, and recommends reference screenshots while the old install is still available. That advice applies just as well to moving to a different tool entirely. Rebuilding a layout from a picture takes minutes. Rebuilding it from memory takes days of small corrections.

A list of what was hidden. After a long stretch of use, the hidden items are the ones nobody thinks about. They all reappear at once after removal, and without a record of which ones were deliberately hidden, sorting them again is slow. One screenshot of the item list is enough.

Quit it properly first

The distributed build is marked as an agent app, meaning no Dock icon. That is comfortable in daily use and awkward during removal, because there is no obvious signal about whether the process is still running. Quit from the menu bar icon, then confirm in Activity Monitor by searching for the process name.

This step matters more than it sounds. A running app can write its preferences back on quit, which restores files that were deleted moments earlier. Confirm the process is gone, then move the app out of the Applications folder.

Two special cases change the procedure. If both version 5 and version 6 are installed, they are separate apps with separate files, and the support guidance is to confirm the newer one runs correctly before removing the older one. If the app arrived through a Setapp subscription, remove it from within Setapp rather than by hand, because a manual delete leaves the subscription manager out of step with what is actually installed.

Search by bundle identifier, not by company name

This is where most cleanups miss files. Searching for the vendor name returns nothing useful, because the identifier predates the change of ownership and was never renamed.

The build distributed on 10 September 2026, version 6.6.2, carries the bundle identifier com.surteesstudios.Bartender. Its code signature is issued to Bartender App LLC, and the website's copyright notice reads Applause Group, Inc. It also declares an application group, 24J875RH8J.com.surteesstudios.Bartender, which is the name any shared container folder will use.

Open the user library in Finder by holding option while opening the Go menu, then check these locations for folders and files whose names contain either identifier.

Location	What it holds
Preferences	The property list file named after the bundle identifier
Application Support	Settings data and supporting files
Caches	Temporary files that regenerate on demand
Group Containers	The shared area named after the application group
HTTPStorages	Cookies and cached network data
Saved Application State	Window and interface state from the last quit

Everything named after those two identifiers is safe to delete once the app is going away for good. Anything not named after them is out of scope and should be left alone, and the system library at the root of the disk is not part of this cleanup at all. When a file's purpose is unclear, moving it to a temporary folder for a few days is safer than deleting it, since anything that turns out to matter announces itself quickly.

Decide whether to let a removal tool do it

Dedicated uninstaller apps find related files automatically and are faster than a manual pass, particularly across many apps at once. The trade off is that they present candidates without showing the reasoning, so an unrelated file in the list is easy to approve by accident.

A reasonable rule: for a single app, checking the six locations by hand takes five to ten minutes and leaves no ambiguity. For clearing years of accumulated leftovers from many apps, a removal tool earns its place. Either way, read the candidate list before confirming, and check that every entry is named after the identifiers above.

It is also worth looking inside the app's own settings before removing it, since some vendors build a full removal option into the preferences window. Where one exists, it is the most reliable route available.

Clear the permission and login item records

Deleting files does not touch the records macOS keeps about the app. Open System Settings, go to Privacy and Security, and check each list for a leftover entry.

The signed entitlements in the distributed build declare calendar access, location, weather data, and Apple Events automation, with Music and Spotify listed as named scripting targets, on top of the Accessibility and Screen and System Audio Recording permissions the app requests on first launch. Which of those lists actually contains an entry depends on which features were used. Select the entry and use the minus button to remove it.

Login items live elsewhere. Under General in System Settings, open Login Items and remove any registration that starts the app at sign in. Leaving one behind means macOS keeps trying to launch something that is no longer there.

There is a forward looking reason to be thorough here. macOS stores the app's code signature alongside each granted permission, so a stale record combined with a later reinstall can produce permissions that appear granted but do not work. The documented fix for that situation is to remove the entries and grant them again, which is exactly the work being done now. Doing it during removal means never having to diagnose it later.

Expect the menu bar to look worse at first

Sign back in and every previously hidden icon returns at once. On a busy machine the result looks more crowded than it did before the tool was ever installed, which is a poor moment to make a decision about replacements.

Two things are worth doing before considering any new software. First, check each app's own preferences for an option to remove its menu bar icon. Many utilities have one, and removing an icon at the source is better than hiding it, because it shrinks the problem rather than managing it.

There is a useful side effect to this exercise. Working through the preferences of every menu bar app is the only reliable way to find out which ones were installed deliberately and which ones arrived as part of something else. Printer utilities, graphics drivers, and bundled updaters all put icons in the menu bar without ever being chosen, and they tend to survive for years because nothing forces a decision about them. The moment after a cleanup is exactly when that decision is easiest to make.

Second, work through the Control Centre settings. Items such as Bluetooth, Sound, and Focus can each be set to show always, show only when active, or never appear. Switching several of them to show only when active clears a handful of icons with no third party software involved.

If the menu bar is tolerable after those two passes, the machine does not need a management tool at all. If it is still overloaded, the remaining icons are a precise description of what a tool would need to solve, which is far more useful than a vague sense of clutter.

If the plan is to reinstall the same app later

Removal is sometimes a troubleshooting step rather than a goodbye. When the intention is to put the same app back, the sequence changes slightly and the order matters more.

Clear the permission entries before reinstalling, not after. Granting a permission to a fresh install while a stale record for the same identifier still exists is the situation that produces a checkbox that appears enabled while the feature stays broken. Removing the entries first means the new install requests them from a clean state.

Keep the preference files only if the goal is to preserve a working layout, and delete them if the layout itself is the suspect. Trying to have both at once, keeping the settings while hoping a corrupted state disappears, is how a troubleshooting pass ends up proving nothing. Decide which of the two is being tested and act accordingly.

Restart between removal and reinstall. Menu bar positions on macOS are held partly by the system, and a sign out clears state that would otherwise carry across and confuse the result. It costs a minute and removes an entire category of misleading outcome from the test.

What to do next

Do the two free passes above before installing anything else, then judge what is left. If a replacement is still needed, compare tools on how hidden items get recalled, which permissions they require, and how easily they can be removed later, using Features and How it compares as the starting point. Trying one on the machine that has the problem, via Download, settles the question faster than any feature list will.