Vanilla: how to uninstall it cleanly

Dragging the app to the Trash is the obvious move, and it is not quite the whole job. A menu bar utility that asks for system permissions leaves records behind in places the Trash does not reach, and on some Macs the menu bar looks worse immediately after removal than it did before.

This covers the order that avoids rework: what to do while the app is still running, how to remove it, which entries survive, and what to check when icons fail to come back.

Do two things before deleting anything

Expand the collapsed section first. Click the divider so the hidden icons are visible, and leave them visible. Deleting the app while the section is collapsed means the icons return in whatever order macOS decides, with no record of how they were arranged, and the reconstruction happens by memory.

Second, if the removed section is in use, empty it. Open the preferences window, drag the dividers left, and bring those icons back into the visible strip. Icons parked in the removed section are visible only while preferences are open, so once the app is gone there is no way to look at that list and check what was in it.

A screenshot of the menu bar at this point costs nothing and saves the most time later. The arrangement is the part that took effort to get right, and it is the part with no backup.

For anyone holding a Pro license, locate the license code and put it somewhere findable. Codes are limited to a default of ten activations according to the published help, and having the purchase record on hand removes any question later about whether a reinstall requires buying again.

Removing the app

Quit the app first. The published help lists three ways to do it: the menu on the menu bar dot, right-clicking the Dock icon, and Activity Monitor. Any of them works, and quitting before deleting matters because a running background process can keep operating even after the bundle is moved.

Then drag the app from the Applications folder to the Trash.

Check the menu bar immediately afterwards. If the previously hidden icons are visible and the strip looks roughly as it did before the app was installed, the background process is gone. If part of the bar still looks collapsed, something is still running, or the icons are being dropped for a different reason covered further down.

What the Trash does not remove

Four things survive deleting the application bundle.

Location	What is left	Worth removing
Privacy and Security, Screen Recording	The permission entry	Yes
Privacy and Security, Accessibility	The permission entry	Yes
General, Login Items	A startup entry, if launch at login was enabled	Yes
Library folder in the home directory	Preference and support files	Optional

The two permission entries are the ones with a practical consequence. Since macOS 15, apps holding Screen Recording permission trigger a periodic re-authorisation prompt, set to a monthly cycle after Apple revised an earlier weekly interval before release. Leaving a stale entry in that list keeps a deleted app in the rotation of things the system asks about, which is confusing at best.

Removing them is straightforward. Open the relevant list in system settings, unlock it for editing if required, select the row, and use the minus button. This is the same operation the developer documents as a repair procedure, where removing and re-adding both entries fixes a setup screen that will not advance. The published explanation for that fix is that permission records can end up conflicting or pointing at something no longer valid, which is precisely the state a deleted app leaves behind.

The login item entry only exists if launch at login was switched on, which is a Pro feature. It appears under General, Login Items in system settings and is removed with the same minus button.

Preference files, and how to identify them

Support files live in the Library folder inside the home directory, which is hidden by default. Reaching it means holding the option key while opening the Go menu in Finder, or using Go to Folder and typing the path.

Four subfolders are worth checking: Preferences, Application Support, Caches, and Saved Application State. Anything in those folders carrying the app's name or its bundle identifier belongs to it.

The naming is the awkward part, because these files are usually named after a reverse-domain bundle identifier rather than the app's display name. The identifier can be read directly while the app is still installed, by running osascript -e 'id of app "Vanilla"' in Terminal. Doing this before deletion turns the cleanup from guesswork into a text match. After deletion, searching the Preferences folder for the app name usually still finds it, since the identifier normally contains the name.

Order matters here too. Deleting preference files while the app is still running lets the process write them back on quit, so the files reappear and the cleanup looks like it failed. Quit first, delete second, and optionally log out and back in to confirm nothing has been rewritten.

Two cautions on what to keep. Files whose names clearly contain the app's own identifier are safe to remove. Folders named only after the developer, which could be shared with their other apps, should stay if any of those apps are still in use. And none of this is urgent: these files are typically a few kilobytes, so leaving them in place costs nothing measurable.

Stopping without uninstalling

If the reason for removal is that a background app feels like clutter rather than that the tool is unwanted, there is a middle option that preserves the configuration.

Turn off launch at login in system settings, then quit the app. The background process stops, the divider disappears from the menu bar, and the zone layout stays saved for whenever it is next opened. Nothing needs rebuilding if the decision reverses.

The permission entries stay in place under this approach, which means the periodic macOS prompt keeps arriving. Removing the entries stops the prompt but also means going through the initial permission grant again on next use. A reasonable rule: if the app has gone a full month without being opened, uninstall properly; if it still gets opened weekly, quitting is enough.

Keep three things if a reinstall is possible

Uninstalling with the door left open takes three items, and none of them are the app itself.

The license code comes first, for anyone on the paid version. Removing the app does nothing to the code, and the published activation allowance is ten by default, so a reinstall on the same machine does not normally raise a licensing question. What causes trouble is not the limit but the record: a purchase made two years ago through a payment processor is hard to find later without the original receipt. Filing it alongside other software licenses solves this in thirty seconds.

The screenshot comes second, and it is the item most often skipped. Zone boundaries are not documented anywhere a person can read. Which icons sat in the collapsible group, which sat in the removed group, and what order the visible ones were in exists only as pixels on screen until it is captured.

The preference file comes third, with a caveat. Leaving it in the Library folder means a reinstall may pick up the previous layout automatically. It may also be ignored, if the file format changed between versions. Treat it as a convenience rather than a backup, and do not skip the screenshot on the assumption that the file will restore everything.

After removal, decide whether the original problem is back

Uninstalling a menu bar manager for macOS returns the menu bar to its previous state, which is the state that prompted installing one in the first place. That is fine if the tool was installed out of curiosity. It is worth a second thought if it was installed because the bar was unusable.

Narrowing down the reason for leaving points at what to do next. If the periodic permission prompt was the problem, any tool using the same screenshot approach to blend the bar will produce the same prompt, so the answer is a different technique rather than a different vendor. If the friction was reaching a hidden icon, the relevant question is how many actions that takes: expanding the bar and then clicking is two, and some tools make it one by keeping hidden icons clickable while the bar stays collapsed. If the setup itself was the obstacle, particularly the drag-the-divider model on a notched machine, a tool that configures from a list rather than from the bar itself will feel different.

Writing the reason down in one sentence before installing anything else is the cheapest way to avoid repeating the same uninstall in a month. The feature breakdown is a reasonable starting point for checking whether a given behaviour exists at all, and the FAQ covers the setup questions that tend to surface in the first hour.

When icons are missing after the uninstall

Icons disappearing right after removal is a common outcome, and the cause is usually not leftover files. It is menu bar width.

On MacBooks with a notch, macOS silently drops menu bar items that do not fit in the space to the right of the notch. Dropped items cannot be seen, cannot be clicked, and give no indication that they exist. While the app was installed, the collapsed section kept the visible count low enough to fit. Removing it puts every icon back onto the strip at once, and whatever no longer fits is quietly discarded.

The fix is to reduce the number of items. Most menu bar apps have a preference controlling whether they show an icon at all, so going through them one at a time and switching off the ones that are never clicked recovers the space. Command-dragging icons rearranges the order, which decides what survives when the strip overflows.

A separate symptom is icons that returned but in a different order. macOS remembers menu bar positions per app, and those positions can shift during the period when part of the bar was collapsed. Restoring the previous arrangement is a manual command-drag operation, which is where the screenshot taken before the uninstall pays for itself.

What to change first

Before deleting anything, expand the bar, empty the removed section, and take a screenshot. After the app is gone, clear the two permission entries and the login item, then check whether the menu bar is now overflowing rather than assuming icons were lost. If the original problem still stands and the reason for leaving was the number of clicks needed to reach a hidden icon, compare that specific behaviour on the comparison page before installing the next one, which is the difference Koffret is built around.