Where to get Hidden Bar: App Store or GitHub

Looking for the Hidden Bar Mac app produces two buttons that look interchangeable. One goes to the Mac App Store. The other goes to a GitHub repository, or to a Homebrew command that pulls from the same place. Both are free, both are published by the same developer, and both install something called Hidden Bar.

They do not install the same build. As of 18 September 2026, the App Store listing shows version 1.8, last updated on 1 June 2021. The GitHub repository shipped v1.11 on 18 September 2026, titled "macOS 27 support". Five years and three releases separate the two buttons, and which one gets clicked decides whether the app works on a current Mac.

What Hidden Bar is

Hidden Bar is an open source menu bar organizer for macOS, published by Dwarves Foundation under the MIT licence. The repository has been public since February 2019 and currently sits at 14,819 stars with 499 forks and 109 open issues.

The idea is deliberately small. The app puts an arrow into the menu bar. Icons dragged to the left of it collapse out of view when the arrow is clicked, icons to the right stay put. Clicking the arrow again brings the hidden group back. There is an optional second zone, described in the project's manual as the always hidden section, for icons that should not surface even when the rest is expanded.

Moving icons across that boundary uses a standard macOS gesture: hold Command and drag the icon sideways. Nothing about the layout is stored inside the app. macOS remembers each icon's position, which is why a rearranged bar survives a restart and why the same gesture works with or without any helper installed.

The two routes do not hand over the same build

	Mac App Store	GitHub release	Homebrew cask
Version available	1.8	1.11	1.10
Date of that version	1 June 2021	18 September 2026	3 March 2026
Stated minimum macOS	10.12	13 Ventura	follows the release it packages
Price	Free	Free	Free
How updates arrive	App Store updates	Manual download, or the cask	Through the cask when it is bumped

The Homebrew cask is named hiddenbar and currently packages v1.10 rather than the newest release, so it lands in between. That is normal for casks, which are updated by volunteers after a release appears rather than at the moment it ships.

What the App Store copy predates

Version 1.8 was released on 1 June 2021. Everything since then happened after that build was frozen.

The Mac releases alone make the gap concrete. macOS 12 Monterey, 13 Ventura, 14 Sonoma, 15 Sequoia, 26 Tahoe and 27 have all shipped since. Two of those releases reworked how the menu bar is drawn and how apps are allowed to start at login. A utility whose entire job is manipulating the menu bar is unusually exposed to that kind of change.

The repository itself has not been idle. Releases v1.9, v1.10 and v1.11 all landed after the App Store copy stopped moving, and the repository received commits on the same day this was written. The App Store listing and the repository are simply not tracking each other, and nothing on the App Store page says so. A download from there installs a 2021 application with a 2021 idea of what macOS looks like.

What the newer releases changed

Three changes in the later builds matter to anyone deciding between the buttons.

The minimum macOS went up

v1.11 requires macOS 13 Ventura or later. The project's own documentation gives the reason plainly: starting the app at login moved to the SMAppService API, which Apple introduced in Ventura. Anyone still on macOS 10.13 through 12 is directed to v1.10, described in the repository as the last release built on the old autostart mechanism.

This cuts both ways. On a current Mac, the newest release is the one to take. On an older Mac that cannot move past Monterey, the App Store build and v1.10 are both options, and the App Store build has the lower stated floor of macOS 10.12.

macOS 27 hiding was rebuilt

The v1.11 release is titled "macOS 27 support". The manual distributed with the project describes a changed layout on that release: in the direct download build the arrow itself acts as the boundary, with no separate divider character, and icons are Command-dragged to the arrow's left to hide them. Anyone following a tutorial written against an older build will be looking for a divider that is no longer drawn.

Permissions became explicit

The current build asks for Accessibility permission in System Settings, under Privacy & Security, so that it can see where the icons sit. Without that permission the manual states the bar simply stays expanded. This is worth knowing in advance, because an app that appears to do nothing after installation is usually an app waiting on a permission rather than a broken one.

Installing the direct build

The project states that the non App Store build is notarized before being distributed, which is what allows it to open without the unidentified developer warning. Notarization is Apple's automated malware scan of a signed app, not a review of behaviour, so it answers the question of whether the file was tampered with rather than whether the app is any good.

Three practical points come out of the documentation.

The app has to live in the Applications folder. The manual is explicit that macOS only recognises that copy as Hidden Bar, and a copy run from Downloads will hide its own arrow instead of working normally.

Apple's own menu bar items stay visible no matter what. The clock, Wi-Fi, Sound and Control Center are drawn by the system and are outside what any third party app can collapse. Anyone hoping to remove the clock this way will need the per module settings in System Settings instead.

New icons tend to arrive already hidden. The manual explains that macOS inserts a brand new menu bar icon at the far left slot, which is inside the hidden zone, so a freshly installed app can look like it never appeared. The fix is a single Command-drag to the right of the boundary, and macOS remembers the placement from then on.

Checking which build is already installed

Plenty of Macs already have Hidden Bar on them from an earlier attempt at tidying the bar, and the version number is the only way to tell which of the two routes it came from. Open the Applications folder, select Hidden Bar, then choose Get Info from the File menu. The version shown there is what is running. Anything reading 1.8 came from the App Store or from a download made before mid 2021.

Switching routes is not an upgrade in the usual sense. The App Store copy and the direct download are separate installations, and replacing one with the other means removing the old app first, then dragging the new one into Applications. The menu bar layout survives that swap, because the positions belong to macOS rather than to the app, but the login item does not. After replacing the app, check System Settings, then General, then Login Items, and confirm the entry points at the new copy.

One leftover is worth knowing about. Older versions installed a separate helper for starting at login, and the documentation notes that a ghost entry from that mechanism can linger in Login Items. Launching the current version once deauthorises the legacy item automatically, so the fix is to run the new build rather than to hunt for the stray entry by hand.

Settings that only exist in Terminal

The current build carries a handful of options with no interface, changed with the defaults command and applied after quitting and relaunching the app. The preference domain is com.dwarvesv.minimalbar.

Two of them are worth knowing. One turns on expanding by resting the pointer on the menu bar for about half a second, which is off by default and changes the app from click driven to hover driven. The other sets the auto collapse delay to any number of seconds, rather than the fixed list the preferences window offers, which matters if the built in choices are all either too eager or too slow. Undoing either is a matter of deleting the key again.

These are documented in the project's manual rather than hidden, but they are easy to miss, and both address the most common complaint about a two state hiding model: that the group collapses at the wrong moment.

Which route to pick

For a Mac running macOS 13 or later, the GitHub release is the one that matches the operating system. The App Store route gives automatic updates, but a listing that has not moved since 2021 has no updates to deliver, so the main advantage of that route does not currently apply.

For a Mac on macOS 12 or earlier, the choice is between the App Store build and v1.10 from the releases page. Both are older code by design, and neither will receive fixes.

The project is also honest about its current limits, which is worth reading before committing to a layout. The manual flags the always hidden zone as a known limitation being reworked, and advises against putting critical icons there for now. For a bar where the important items need to stay reachable, that is a real constraint rather than a footnote.

Where the paid tools differ

The reason paid menu bar organizers exist alongside a free one is narrower than the marketing around them suggests, and it comes down to what happens after the icons are hidden.

A hide and reveal model has two states. Collapsed, where the icons are gone, and expanded, where they are all back. Checking one hidden item means expanding the whole group, clicking, and waiting for it to collapse again. Tools that go further let a hidden icon be clicked while the bar stays collapsed, show the hidden group in a panel below the bar rather than in the bar itself, or bring a single icon out automatically when its state changes. Whether any of that is worth paying for depends entirely on how often hidden icons get used, which is a question only the person with the cluttered bar can answer. The side by side comparison sets the behaviours against each other, and the pricing page states the cost without a subscription attached.

What to change first

Install the current GitHub release rather than the App Store copy if the Mac is on macOS 13 or later, spend a week finding out which hidden icons actually get retrieved, and count the retrievals. If the answer is several a day, the expand and collapse cycle is the thing costing time, and that is what Koffret was built around.