Is an open source menu bar manager safe to give Accessibility permission?

Open source means the code can be audited, which is a meaningful advantage, but the permission itself grants the same control regardless of license. Read the project's stated reason for requesting it, check that the request matches the feature set, and remember that the grant can be revoked at any time under Privacy and Security in System Settings.

Which open source option works on an older Mac?

Of the three common projects, Dozer states the lowest requirement at macOS 10.13, Hidden Bar requires macOS 13 Ventura or later, and Ice requires macOS 14. If your Mac cannot move past an older release, check the repository's recent activity as well as the stated minimum, since a low floor often accompanies a long gap between releases.

Does the license affect what I can do with the app?

Not for ordinary use. MIT, MPL-2.0, and GPL-3.0 all allow free installation and use, including at work. The differences apply when you modify and distribute the code, where GPL-3.0 requires derivative works to be released under the same license, MPL-2.0 requires changes to the project's own files to be published, and MIT requires only that the notice is kept.

Do free tools hide icons less well than paid ones?

The basic hiding behaviour is comparable across the category. The differences appear in the layer above it, such as whether a hidden icon can be clicked without expanding the bar, whether overflow can be shown as a second row, and whether rules can differ per app or per display. Compare on those points rather than on price alone.

Open Source Menu Bar Manager for Mac: The Real Trade-offs

Searching for an open source menu bar manager for Mac usually starts from one of two places. Either the menu bar is full and a paid tool feels like a lot to ask for a strip of icons, or the idea of giving a background app permission to watch the top of the screen makes closed source uncomfortable. Both are reasonable starting points, and they lead to different conclusions.

The open source options in this category are real, maintained on public repositories, and free to install. They are also not interchangeable. They differ in the minimum macOS they run on, in the license attached to the code, in how they are distributed, and in what they do once the bar is collapsed. Those differences matter more than the shared label.

What open source actually changes for this kind of app

A menu bar manager is an unusual thing to install. To hide and reveal status items it has to sit permanently in the background, observe what is in the menu bar, and in most designs move things around on your behalf. That is a broader footprint than a typical utility, and it is why the source question comes up here more often than it does for, say, an image converter.

Open source gives you two concrete things. The first is auditability: the code is on a public repository, so the behaviour can be checked by anyone who reads Swift, and issues filed against it are visible. The second is continuity: if the original author stops, the code can be forked and kept alive by someone else. Both of the tools discussed below exist partly because that happened in this category before.

It does not automatically give you three things that are easy to assume. It does not guarantee the app is currently maintained, since a public repository can sit still for years. It does not guarantee the binary you downloaded was built from the source you read, unless you build it yourself. And it does not mean the app asks for fewer system permissions than a paid one, because the permissions are dictated by what the feature does, not by the licence on the code.

Open source is a property of the code, not a promise about the product. Read it as one input among several rather than as the answer.

The main open source options and how they differ

Three projects come up consistently in this space. The facts below come from their public repositories.

Project	Repository	License	Minimum macOS
Ice	jordanbaird/Ice	GPL-3.0	macOS 14
Hidden Bar	dwarvesf/hidden	MIT	macOS 13
Dozer	Mortennn/Dozer	MPL-2.0	macOS 10.13

The macOS column is the one that decides the shortlist for most people, and it decides it in opposite directions depending on your hardware.

Ice sets the highest floor of the three. Its documentation states that it relies on system APIs introduced in macOS 14, with no plan to support earlier releases. That is a deliberate choice rather than an oversight: newer system APIs are what allow a menu bar tool to work without some of the workarounds older tools needed. If your Mac is on a current macOS, this is not a constraint at all.

Hidden Bar requires macOS 13 Ventura or later, and its repository notes that version 1.10 was the final release supporting systems back through macOS 12 Monterey. It is distributed through the Mac App Store as well as Homebrew and direct download, which makes it the easiest of the three to install for someone who does not want to think about Gatekeeper.

Dozer has by far the lowest floor at macOS 10.13. On a Mac that cannot move past an older macOS, that floor is the whole argument. Before installing any project with a low stated minimum, it is worth opening the repository and looking at the date of the most recent commits and releases, because a low floor and a long gap since the last release often appear together.

Licenses, and when the difference reaches you

For someone who just wants a tidy menu bar, MIT, MPL-2.0, and GPL-3.0 are equivalent. All three let you download, install, and use the app for free, for anything, including work. No license in this group asks an ordinary user for anything.

The difference appears the moment you want to do something with the code. MIT is the most permissive: take it, change it, ship it inside a closed source product, keep the copyright notice. MPL-2.0 sits in the middle: changes to the project's own files have to be published, but you can combine it with proprietary code without that code becoming subject to the license. GPL-3.0 is the strongest: a distributed derivative work has to be released under GPL-3.0 as well.

This matters in one practical situation that comes up more than you would expect. If you work somewhere with a legal review for internal tooling, the reviewer will care about which of these three is attached before anyone installs it on a fleet. GPL-3.0 in particular tends to trigger a longer conversation than MIT, not because it is worse, but because the obligations attach on distribution and a company has to be sure it is not distributing.

What these tools ask of your Mac

This is the section worth reading slowly, because it is the same for open and closed source and it is where the real cost sits.

To manipulate the menu bar, an app in this category typically needs at least one privileged permission. Accessibility permission lets an app observe and control other applications' interface elements, which is how items get moved and clicked. Screen Recording permission lets an app read the contents of the screen, which some designs use to detect what is currently in the bar and how wide it is. These are not the same grant. Accessibility is about control, Screen Recording is about seeing everything on your display, including other windows.

Before installing anything here, open the project's README and find out which of the two it asks for and why. A tool that explains the reason in its own documentation has already told you something useful. When the permission is granted, macOS lists it under Privacy and Security in System Settings, and it can be revoked there at any time without uninstalling the app.

The second thing to check is distribution. A Mac App Store build runs inside the App Store sandbox, which restricts what an app can do to other applications. A directly downloaded build is not sandboxed, which is how some features exist at all, but it needs to be signed and notarized or macOS will refuse to open it without a manual override. Neither route is inherently safer. They fail differently.

Where open source and paid tools tend to diverge

The honest summary is that the split is not about the hiding itself. All of these tools hide icons, and the basic collapse behaviour is broadly comparable across the category.

The differences show up in the second layer. Whether a hidden icon can be clicked and its menu opened while the bar is still collapsed, rather than expanding everything first, changes how many actions a normal day costs. Whether overflow can be shown as a second row under the menu bar matters specifically on a MacBook with a camera housing, because that second row is not split by the notch. Whether the app has per-app or per-display rules, whether it can auto-rehide after a delay, and whether settings survive an OS upgrade are the sort of details that only become visible after a week of use.

Paid tools in this category generally fund that second layer, along with support and a release cadence tied to macOS updates. Open source projects fund it with maintainer time, which varies. Neither model wins in the abstract. The comparison worth making is between two specific tools on the features you will actually touch, and that is what the How it compares page is organised around.

What none of them can do

It saves time to know the shared ceiling before comparing feature lists, because several things people expect from this category are not available to any app in it, open source or not.

None of them can reduce what the hidden applications are doing. An icon that is parked off screen belongs to a process that is still running, still syncing, and still using the same battery and memory it used before. What changes is how much of the top of the screen demands attention, which is worth having, but it is not a performance improvement and no tool in this category should be described as one.

None of them can reposition every item freely. Certain system items hold their place at the right end of the bar, and third-party status items queue to their left. A menu bar manager works within that ordering rather than overriding it, which is why the collapse point behaves the way it does.

None of them can create width where the frontmost application has taken it. When an app with a long menu list is in front, the left side of the bar grows and the space available to status items shrinks. Hiding items is the response to that, not a way to prevent it.

And none of them survive the underlying system changing without work. Each macOS release can alter how status items are laid out and what an app is allowed to observe, which is exactly why release cadence is the most informative thing on a repository page. A project that shipped an update alongside the last major macOS version has demonstrated the thing you are relying on. One that has not, has not yet.

Knowing the ceiling makes the remaining differences easier to weigh, because it leaves only the choices that are genuinely the tool's to make.

How to evaluate one before you commit

Four checks separate the options faster than reading feature lists.

Open the repository and look at the last release date and the last commit date, not the star count. A menu bar tool touches system behaviour that changes with each macOS release, so a project that has not shipped since the previous major version is a different proposition from one that shipped last month.

Check the minimum macOS against the oldest Mac you use. If you have a machine on an older release, that constraint eliminates most of the list immediately.

Check the permission requested and the reason given. If the README does not say, the issue tracker usually does.

Finally, install one and use it for a week without changing anything else, then ask whether you ever went looking for an icon you had hidden. If you did, the hiding is not the problem. Reachability is, and that is the axis on which these tools genuinely differ. The specific behaviours are listed on the Features page.

What to change first

Try the free option that matches your macOS version before anything else, because it costs nothing and it tells you whether hiding alone solves your problem. If you find yourself expanding the bar repeatedly to reach something you hid, the next thing to compare is how each tool handles clicking a hidden icon in place, which is what Koffret is built around. Terms are on the Pricing page.