Dozer: how to uninstall it cleanly

Removing a menu bar hider is not like removing an ordinary app, not because it is difficult, but because the result is immediately visible. The second the app quits, every icon it was pushing off screen comes back, all at once, and the menu bar looks worse than it did before the app was ever installed.

This is the removal sequence for Dozer, the files it leaves under its bundle identifier, the one piece that commonly survives a drag to the Trash, and how to decide what fills the space afterwards. The published details below were checked against the project's public repository on 10 September 2026.

What the app is doing, and why that matters when it goes

Dozer does not delete or unregister anything belonging to other apps. It places two or three status items of its own in the menu bar and changes their width. Everything to the left of the second one gets pushed past the edge of the screen, which reads as hidden. The project's own description sets this out plainly: the icons are numbered from right to left, the first is only a point of interaction, and the second one and everything left of it is what toggles.

That design has a direct consequence for uninstalling. Nothing needs to be restored, unregistered, or handed back. Remove the app and every icon returns to the position macOS already had recorded for it. There is no state to repair and no risk of leaving another app half configured.

The flip side is that the entire benefit disappears in the same instant. A menu bar that looked like six items has been nineteen items the whole time. Anyone removing this app because they no longer need it will not care. Anyone removing it because it stopped behaving on a newer macOS release will care a great deal, because the underlying crowding problem is still there and still needs an answer.

One more thing worth knowing before starting. Icon order in the menu bar is held by macOS, not by the hiding app, and is changed by holding Command and dragging. Uninstalling does not reset that order. What changes is that items which were parked off screen are visible again, which feels like a reshuffle even though nothing moved.

Check how the project is being distributed first

Distribution status is worth a minute of attention, because it usually explains why someone is uninstalling in the first place.

The most recent release is 4.2.0, published on 13 July 2020. Commit activity continued for a while after that and then stopped on 1 November 2022, and the final change was a fix to a demo image. The licence is MPL-2.0, the stated requirement is macOS 10.13 or newer, and the repository sits at roughly 8,700 stars with 95 open issues and 302 forks. None of that means the app is broken. It does mean that a macOS release which changes how status items behave will not be met with an update.

The install instructions still read as they always have:

Using Homebrew Cask: brew install --cask dozer Source: github.com

The catalogue page that line links to returns a 404 as of 10 September 2026, and a lookup on a local machine reports that no cask by that name exists. For an uninstall this matters in one narrow way: brew uninstall --cask dozer may or may not run depending on what your local installation still has on record. If it does not run, nothing is wrong. Switch to the manual sequence below and the outcome is identical.

Quit first, then remove the bundle

Start by quitting. Right clicking any of the app's own menu bar icons opens its settings, and the quit action lives there.

The order is not decorative. macOS keeps preferences in memory through a background process and writes them back out when an app exits. Delete the bundle while the app is still running and that write can recreate the preference file you are about to remove, which is the usual explanation for files that reappear after an apparently complete cleanup.

With the app quit, move the bundle out of the Applications folder. If it came from Homebrew, try the uninstall command first and fall back to removing the bundle by hand. If you are not sure how it was installed, the presence of the bundle in Applications answers the question well enough for this purpose.

At this point the menu bar is fully populated again. Resist the urge to start dragging icons around immediately. Finish the file cleanup, then treat the layout as one deliberate task rather than a reaction.

The files that carry the bundle identifier

Everything left behind is named after the bundle identifier, which the project configuration records as com.mortennn.Dozer. That single string is enough to find all of it.

The entitlements file in the repository is empty, meaning the app is not sandboxed, so nothing lives inside a container directory. The leftovers sit in the ordinary user library instead. Open the Library folder in your home directory, which Finder hides until you hold Option while opening the Go menu, and look in these four places for anything starting with that identifier.

Location	What it holds	Safe to remove
Preferences	The settings file: shortcut assignment, hide delay, icon sizing	Yes, after quitting
Caches	Temporary files from update checks	Yes
HTTPStorages	Network state from update checks	Yes
Saved Application State	Window and state restoration data	Yes

The update mechanism is worth one line of explanation, because it is what creates most of the cache entries. The project's dependency list includes Sparkle, the common third party updater for Mac apps, and an update feed file ships in the repository alongside it. Update checks are network calls, so they leave traces in the cache and network storage directories. Those files are small and harmless if left in place. Remove them if you want the removal to be complete rather than because anything depends on it.

The login item is the part that survives

This is the step most cleanup guides skip.

Automatic startup here is handled by a small helper application bundled inside the main app, using the common LaunchAtLogin approach that appears in the project's dependency list. That approach registers the helper with macOS rather than dropping a file somewhere obvious, which means the registration is a separate thing from the bundle you just deleted.

On macOS 13 and later, registrations of this kind appear in System Settings under General, in Login Items, in the list of software allowed to run in the background. After removing the app, open that list and look for an entry that shows only a developer name, or an entry with no name at all. Turn it off if it is there. A restart clears most stale entries on its own.

Keyboard shortcuts are a related loose end. The app supports assigning a global shortcut for toggling, and that assignment is stored in the preference file covered above. Remove the preference file and the assignment goes with it. Leave the preference file behind, then try to give the same key combination to a different menu bar manager later, and the new assignment may not take. If a shortcut refuses to register in a replacement app, an orphaned preference file is the first thing to check.

Confirm the removal actually finished

Three checks are enough.

The menu bar itself. The app's own status items are gone and everything it was hiding is visible. That confirms nothing is still running.

A restart with nothing coming back. If an icon reappears after a restart, either a copy of the bundle survives somewhere outside Applications, such as an unarchived copy still sitting in Downloads or on the Desktop, or the login item registration is still active.

A search of the user Library for the bundle identifier. Finder's search, scoped to file names, will list anything left in one pass.

One question comes up often enough to answer here: whether the app needs to be removed at all before installing something else. Two menu bar managers can technically run at the same time, but they will fight over the same territory, because each one measures the row and decides which items sit past a boundary. Running both usually produces a menu bar that flickers or hides the wrong things. Uninstall first, then evaluate the replacement with a clean row, and the comparison will actually mean something.

There is no account side to any of this. The app is distributed free under an open source licence, so there is no licence to deactivate, no seat to release, and no subscription that keeps billing after the software is gone. That is a genuine difference from paid menu bar utilities, where deleting the app and ending the payment are two separate jobs and forgetting the second one costs money.

Deciding what fills the gap

Once the cleanup is done, the original problem is back on screen. Two passes get through it quickly.

The first pass is per app. Cloud storage, backup, sync, and update tools very often have a preference controlling whether they appear in the menu bar at all. Anything you interact with by opening the app itself does not need a permanent icon, and turning those off removes the item completely rather than hiding it.

The second pass is macOS itself. Control Center settings let you decide, item by item, whether Bluetooth, Sound, Focus, and the rest are shown in the menu bar permanently or only inside Control Center. Anything you glance at once a week belongs in the second group.

What is left after both passes is the middle layer: items you click sometimes and do not need to see the rest of the time. That is the layer a hiding tool exists for, and it is worth knowing how a given implementation handles it. Some tools only collapse the row, so reaching a hidden item means expanding it first and clicking second. Others let you open a hidden item's menu without expanding anything. The features page lists which behaviours are on offer, and how it compares sets out the differences between approaches without hiding the trade-offs.

Screen shape belongs in this decision too. On a MacBook with a notch, the usable width of the menu bar is reduced, and a tool that works by pushing items past the edge can put the boundary somewhere you did not intend.

What to change first

Quit the app before deleting anything, then clear the four Library locations that carry the bundle identifier and check Login Items for the background entry that outlives the bundle. After that, spend the ten minutes on per app settings and Control Center rather than reinstalling something to hide the same twenty icons, and if a collapsing tool is still the right answer, Koffret is one of the options to weigh.