Dozer alternatives: decide what you can drop

The usual trigger is a command that stops working. A new Mac, a familiar Homebrew line, and an error instead of an install. Or a macOS upgrade, after which the divider behaves differently than it used to. Either way the question becomes what to use instead, and the fastest way to get that wrong is to open a feature comparison and pick whichever tool lists more.

A better order is to look at the record first, then work out which of the features actually got used, and only then compare. Most people who ran this tool used two of its capabilities and configured four more once, years ago. Dates and version numbers below were checked on 10 September 2026.

What the public record shows

The repository is still online and the code is still readable. What has changed is the timeline around it.

The most recent published build is 4.2.0, dated 13 July 2020, and it is marked as a pre-release. The most recent stable release is 4.0.0, from 20 August 2019. The last commit to the repository landed on 30 November 2023. The licence is MPL-2.0, and the project has 8,717 stars, which is a reasonable indicator of how widely it was adopted.

The gap between those dates matters more than any single one of them. Work merged into the code after 2020, including support for newer hardware, was never packaged into a release. Anyone installing the published binary is installing a 2020 build. Anyone who wants the newer code has to compile it, which means installing a development toolchain for a menu bar utility.

Homebrew's handling changed too. The cask definition was marked deprecated on 26 November 2023 with the reason given as discontinued, then disabled on 1 December 2024, and finally removed from the repository on 2 December 2025. That sequence is why the install command fails on a new machine rather than warning.

One thing not in the record: the repository has not been archived, and there is no statement from the author declaring the project finished. The verifiable facts are the three dates and the package manager's decision. What they mean for a particular Mac is a judgement each reader makes.

Audit what actually got used

Before comparing anything, write down which capabilities were in daily use. The full list of what this tool offered looks like this.

A divider item in the menu bar, with everything on the hidden side collapsed behind it. A second group, reachable by holding Option while clicking. A setting to start collapsed at login. Automatic collapse after a delay, with the delay configurable. A remove function for individual items, and a mode with no visible divider at all. Icon size adjustment and control over whether the app appears in the Dock. Reordering handled by the system, with Command held while dragging.

Now count how many of those were used this month. For most people the honest answer is one, sometimes two. The divider and, occasionally, the launch collapsed setting. The second group, the timed collapse and the icon sizing get configured during the first hour and then never revisited.

That audit is what makes the next step easy. A replacement does not need to match a feature list. It needs to cover the one or two things that were load bearing, and it needs to not make the daily interaction worse.

Which features are safe to give up

Sort the list by a single question: if this feature disappeared, how many extra actions would the day contain?

Anything touched only during setup costs nothing to lose. Icon sizing, Dock visibility, the hidden divider mode, the configurable delay. These are set once. A replacement without them produces zero additional actions per day.

The features that are not safe to lose are the ones on the click path. If an icon that gets used five times a day is hidden, and reaching it means expand, locate, click, collapse, that is four actions instead of one, five times over. Some menu bar managers are designed so a hidden icon can be clicked directly while the bar stays collapsed, which removes the round trip entirely. That is an architectural difference rather than a preference setting, so it has to be chosen for rather than configured later.

The other non negotiable, for anyone on a MacBook with a camera housing, is behaviour around the notch. Items that wrap past it are not merely hidden, they are unclickable. If that was the reason for installing anything in the first place, check explicitly what each candidate states about that region rather than assuming that hiding icons covers it.

The current options, by distribution and upkeep

The table below lists what could be verified on 10 September 2026. Prices are as published and vary by region and over time.

Name	Distribution	Cost	Version seen	macOS stated
Dozer	Open source, MPL-2.0	Free	4.2.0, from 2020	10.13 and later
Hidden Bar	Open source, MIT	Free	1.10	Not stated in cask
Ice	Open source, GPL-3.0	Free	0.11.12	14 and later
Bartender	Commercial	Paid, one time purchase available	6.6.2	14 and later
Barbee	Mac App Store	Free with in-app purchase	4.3	11.0 and later

Two of those numbers narrow the field immediately. Options requiring macOS 14 are unavailable to anyone staying on an older system, which is a common position for people running hardware that a 2019 utility still suits.

Upkeep is the column that is easy to overlook and expensive to ignore. Hidden Bar received code as recently as 15 June 2026. Ice received code on 20 September 2025. Free and open source describes a licence, not a maintenance commitment, and the useful question is when the most recent commit landed rather than what the licence says. The same check that produced the timeline in the first section of this article can be run against any candidate in about two minutes.

How to check a candidate in two minutes

The timeline in the first section was not specialist research. The same four checks work on any candidate and take about two minutes, which is less time than reading a feature page.

Check one: the date of the most recent release, not the version number. A high version number tells you nothing about whether the build in front of you predates the macOS on the machine. Releases pages show dates next to tags.

Check two: the date of the most recent commit, which is usually different from the release date. A project with commits from this year and releases from four years ago is being maintained but not shipped, and the download available to ordinary users is the old one. That distinction is exactly what caught people out here.

Check three: how the package manager treats it. A cask that is deprecated, disabled or missing entirely is a signal that volunteers who track these things have already concluded something. The reason string is published alongside the deprecation, so the stated cause is visible rather than inferred.

Check four: the minimum macOS version, taken from the project itself or the cask definition rather than from a review. This one eliminates candidates faster than any other, particularly for anyone deliberately staying on an older release.

A fifth check applies only to commercial software: whether the company behind it has changed. Ownership of tools in this category has changed hands before, sometimes without an announcement at the time, and while that says nothing about whether the software works, it is the kind of fact people prefer to learn before paying rather than after. Questions that come up while running these checks are collected on the FAQ page.

What does not transfer

Expect to rebuild the configuration. Settings do not move between tools in this category, and the reason is structural rather than an oversight.

A divider based tool does not store a list of hidden applications. It stores the position of a divider. Whether a given icon is hidden depends on which side of that divider it currently sits on, and that arrangement lives in the menu bar order that macOS maintains, not in the app's own preferences. A replacement that records hidden state per application has no compatible data to import, because the original never held that data in the first place.

What survives: icon order. The system remembers where status items sit, so anything positioned earlier stays positioned after the switch.

What does not survive: which icons were hidden, automatic rules, keyboard bindings, delay settings, group assignments.

What has to be redone by hand: the decision about what stays permanently visible. That part takes roughly ten minutes, which is worth knowing before postponing the switch on the assumption that it is a large job.

Run the switch in this order

Twenty minutes covers the whole thing if the steps are taken in sequence.

Start by expanding everything and taking a screenshot of the full menu bar. Anyone who has been running collapsed for months genuinely cannot recall what is behind the divider, and this image becomes the working list for the new setup.

Next, quit the old tool without deleting it. The bar now shows the true number of resident items. If that count is close to twenty, no tool will fix the problem on its own, and the real work is deciding what does not need to be permanently visible.

Install the replacement and grant the permissions it asks for. Tools in this category generally need permission to act on interface elements belonging to other apps, because that is what macOS requires for the job. If the old tool still holds grants in System Settings, remove those entries so it is clear which app is doing what.

Build the arrangement last, using the screenshot as the reference. Do not aim for a final layout on day one. Run it for a week, then move back only the icons that turned out to need a round trip. Delete the old tool once the new one has survived that week.

What to measure, and what to change first

Three numbers decide this, and none of them appear on a feature comparison. The total count of resident icons. How many of those get clicked at least once a day. How many actions it takes to use one after it has been hidden.

If the second number is two or lower, a simple divider tool remains the right shape of solution, and several free ones are maintained. If it is five or higher, the round trip is what will drive the next uninstall, and the property worth selecting for is being able to click a hidden icon while the bar stays collapsed, which is how Koffret is built. Either way, install one candidate, hide the icon reached most often, and count the actions. Side by side differences in approach are set out on the comparison page.