Hidden Bar alternatives: decide what you can drop

Comparison pages make this decision look harder than it is. Every candidate lists more features than the tool currently installed, so switching always looks like an upgrade. What the lists never say is whether the extra rows correspond to anything that happens on a real Mac more than twice a year.

There is an advantage here that does not exist when replacing a large app. This one is small. The settings window fits on a single screen, the documented behavior fits in one file, and the whole feature set can be counted in a couple of minutes. That makes the useful question answerable: which of these can go, and what is left that a replacement genuinely has to provide. Everything below was checked against public listings on 10 September 2026.

Count what the tool actually does

The published manual lists six settings in the preferences window.

• Start at login, registered through the login item mechanism introduced in macOS 13 and revocable from System Settings, General, Login Items
• Show preferences on launch
• Auto collapse, which re-hides the section after a chosen delay
• A global shortcut for expanding and collapsing
• An always-hidden section, a second zone whose icons stay out of sight even when the bar is expanded
• Use the full menu bar while expanded, intended for bars that are already tight on space

The interactions are three. Left-clicking the arrow expands or collapses. Right-clicking the arrow, or left-clicking the separator, opens a small context menu. Holding ⌘ while dragging moves an icon across the separator, which is what decides whether it hides. Option-clicking the arrow toggles the separators and the always-hidden zone without expanding anything.

Three more settings exist with no interface at all. The manual documents them as defaults commands: expanding by hovering over the menu bar for about half a second, setting the auto-collapse delay to any value rather than the fixed list in the interface, and forcing the app's language independently of the system order.

That is roughly ten decisions in total. Ten is a number a person can go through one at a time and answer honestly.

The reason for switching is rarely a missing feature

Three situations account for most of these searches, and only one of them is about capability.

The macOS version does not line up. The README on the development branch states a requirement of macOS 13 Ventura or later. For anything older, v1.10 is named as the last release that works, and the reason is given: autostart moved to the SMAppService API that arrived in macOS 13.

The distribution channel decides which version arrives. Checked on 10 September 2026, the Mac App Store listing shows version 1.8 with a last update date of 1 June 2021 and a stated minimum of macOS 10.12. The GitHub releases list shows v1.10, published 3 March 2026. Same name, same project, two different builds depending on where the download came from. A Homebrew cask is also available. Anyone unhappy with the tool should confirm which build is actually installed before concluding anything about it.

A specific documented behavior is in the way. That is the next section, and it is the only one of the three where a different product is likely to help.

Two of the more common complaints turn out to be settings rather than absences, which is why the count in the previous section included the ones with no interface. Expanding on hover, rather than by clicking the arrow, is off by default and can be switched on with a defaults command. The auto-collapse delay is presented in the interface as a fixed list of options, but the underlying value accepts any number of seconds. Both are documented in the manual with the exact commands and with the instruction to quit and relaunch afterwards. A search that started with "the delay is wrong" or "clicking is slow" can end there instead of in a migration.

The project is MIT licensed and free, and the repository carries 14,687 stars as of the same date. Cost is therefore not a variable on this side of the comparison, which changes what the shortlist should be measured on.

The limits are written down, which is worth using

Most utilities in this category leave the failure modes to forum threads. Here they are in the manual, which makes them usable as selection criteria rather than surprises.

The most common complaint has a mechanical explanation:

Hidden Bar hides icons by widening its separator so everything to the left of it slides off-screen. macOS always inserts a brand-new menu-bar icon at the far-left slot, which is inside that hidden zone, so a freshly launched or updated app can appear "swallowed". Source: github.com

The manual also states plainly that no app can reposition another app's menu bar icon, which is why the fix is a one-time ⌘ drag that macOS then remembers per app. That constraint is not specific to one product. It applies to every tool of this type, so it should not appear on a comparison table as a difference between them.

The always-hidden zone has a stated condition. Items placed there are reliably pushed off-screen only when the separators are also hidden by option-clicking the arrow. With separators visible, always-hidden items can still reappear after expanding. The manual calls this a known limitation being reworked and advises against putting critical icons in that zone until the rework lands, because an icon stuck off-screen has to be recovered by dragging it back.

A third entry is the sharpest one for anyone planning an OS upgrade. The troubleshooting table lists a macOS 27 beta on which nothing hides at all, attributed to the menu bar re-architecture breaking the hiding mechanism, with a fix under investigation. If a major macOS update is imminent, that single line is a more useful input than any feature grid.

Three questions that mark a feature as expendable

Run the ten items through these in order.

Was it touched in the last seven days? Configuring the auto-collapse delay once and never thinking about it again means the setting is not doing work. It can leave the requirements list.

How many extra motions appear per day without it? For someone who expands with the global shortcut, a candidate without a global shortcut costs dozens of keystrokes daily. For someone who clicks the arrow with a pointer, its absence changes nothing at all. The same feature, opposite verdicts, decided by habit rather than by the feature.

Is it recoverable when it misbehaves? Anything that works under a stated condition is a poor place for an icon that has to be reachable, which is exactly the point the manual makes about the always-hidden zone.

Features that answer no to all three come off the requirements list. Removing a requirement widens the shortlist rather than narrowing it, and a wide shortlist is easy to finish, because what remains to compare is cost and release cadence. The Features page lays out what a short requirements list usually looks like in practice.

The two that hurt every day

Applied across most setups, the same two survive.

The first is what happens after an icon is hidden. Most tools in this category require expanding the bar first and then clicking the target, which turns one action into two. The number of clicks between a collapsed bar and an icon's own menu is the difference that compounds, because it is paid every single time rather than once at setup.

The second is whether the arrangement survives a restart or a macOS update. Positions are remembered by macOS per app, so a newly installed app lands at the far left on any of these tools. Whether that means re-sorting every few weeks depends less on the product than on which zone holds which icon.

Everything else is situational. Styling, presets, and automation are worth exactly what they get used for, which for many setups is nothing.

Two smaller behaviors are easy to overlook when comparing, and both are documented here. The collapse timer defers while the pointer is anywhere in the menu bar, then restarts once it leaves, so the section does not fold away mid-use. And if the arrow or separator is ever dragged off the bar, which used to leave the app unreachable, both return on the next launch. Neither shows up as a row on a feature grid, and both are the kind of thing that decides whether a tool feels finished.

What the public listings say

Checked on 10 September 2026 at each project's own distribution page. Prices and supported versions change, so confirm at the source before deciding.

Name	Cost	Distribution and latest activity
Hidden Bar	Free, MIT	App Store listing at 1.8, updated 1 June 2021. GitHub latest release v1.10, 3 March 2026
Ice	Free, GPL-3.0	Latest release 0.11.12, 29 October 2024. Repository last pushed 20 September 2025
Dozer	Free, MPL-2.0	Latest release v4.0.0, 20 August 2019. Repository last pushed 30 November 2023
Vanilla	Free, Pro is a one-time $10	One Pro code activates on up to 10 Macs, with a 30 day money-back note
Bartender 6	From $12 one-time, plus a yearly tier and a lifetime tier	Built for macOS Tahoe and Sequoia. Four week trial, no card required
Barbee	Free, App Store	Listing at 4.3, updated 15 June 2026, minimum macOS 11.0

Sources are each project's own pages: the GitHub repositories for Hidden Bar, Ice, and Dozer, the official sites for Vanilla and Bartender, and the App Store listing for Barbee. The Bartender site carries a copyright notice for Applause Group, Inc., dated 2026.

The interesting column is the right one, not the middle. Three of these cost nothing and ship their source, and they differ mainly in how recently anything shipped. With a major macOS release approaching, release cadence is the practical selection criterion, and it is one that a feature grid never shows. The paid options publish an upgrade path instead, which is a different kind of assurance. The Pricing page sets out how to think about the cost of a resident tool over a few years.

Nothing transfers except the sorting decision

Settings do not migrate between tools in this category. The formats are unrelated, and no import path exists.

What does transfer is the classification. Which icons stay visible, which hide by default, which stay hidden always. Written down on paper, that survives any switch, and rebuilding it in a new tool takes minutes because the ⌘ drag itself is a macOS behavior rather than a feature of any particular app.

Kept only in memory, the same three-way sort gets re-derived from scratch every time, which is what makes switching feel expensive when it is not. Write the list before downloading anything. The How it compares page covers what changes between tools once that list exists.

What to change first

Write out the three-way sort of the icons currently in the bar, then run the ten settings through the seven-day question and keep only what survives. If reaching a hidden icon in one click is on the short list that remains, that is the requirement worth shopping on, and Koffret is built around it.