Hidden Bar pricing: what the free tier covers

Searching for a pricing page and finding nothing usually means one of two things: the price is hidden behind a signup, or there is no price. For this app it is the second. There is no paid tier, no trial that expires, and no upgrade prompt waiting a month into use.

That makes the interesting question a different one. Free software is not free of cost, it just moves the cost somewhere other than a card statement. Knowing where it lands is what makes the comparison against a paid alternative honest.

Zero, with nothing behind it

The Mac App Store listing shows a price of zero, published by Dwarves Foundation Company Limited and first released on February 19, 2019. Verified September 10, 2026 against the listing metadata.

What is absent matters as much as the number:

• No in app purchase entries
• No feature gated tier waiting to be unlocked
• No time limited trial
• No advertising and no bundled installers

The same applies to the other two distribution routes. The GitHub release and the Homebrew cask hiddenbar both cost nothing. The cask reports 28,968 installations over the trailing 365 days, so the non App Store path carries real volume rather than being a developer only option.

What keeps the price at zero

The pricing follows from how the project is built and distributed rather than from a promotional decision.

The source is public under the MIT license, which grants use, modification, and redistribution free of charge. The repository was created on February 12, 2019 and currently shows 14,687 stars and 463 forks. According to the project's own architecture notes, the app is roughly 1,500 lines of Swift with a single external dependency, a small wrapper for registering a global hotkey. There is no server component, no account system, and no network entitlement at all.

That structure removes the recurring costs that normally force a price. Nothing has to be hosted, no licence keys have to be issued or validated, and no support infrastructure has to be staffed.

The open source part also answers a question that free menu bar utilities tend to raise. When an app costs nothing and collects nothing, the natural suspicion is that usage data is the product. Here the claim that there is no network access, no file access, and no interprocess communication is written into the architecture documentation and can be checked against the published code by anyone who wants to.

What free costs instead

Three costs sit on the user side of this arrangement, and they are concrete enough to plan around.

Updates are not automatic on the current channel. The App Store listing sits at version 1.8, last updated June 1, 2021. The newest GitHub release is v1.10, published March 3, 2026. Anyone relying on App Store auto updates is not receiving newer builds. Getting them means using GitHub or Homebrew and running the update manually, or as part of a Homebrew upgrade.

Support is an issue tracker, not a queue with a response time. The project currently lists 101 open issues. Searching before posting usually finds the symptom already described, which is faster than any support form. What is not available is a commitment to answer by a given date, which matters if the tool is load bearing for daily work.

Operating system changes are absorbed on the project's schedule. The hiding technique inflates the width of a status item so neighbouring icons slide off screen, so a change to how macOS lays out the menu bar can break it outright. That happened on macOS 27 betas, where an issue opened on June 8, 2026 reports the mechanism no longer working, still under investigation. Nothing about the price predicts how quickly that gets resolved.

One more consequence is easy to miss. Volunteer maintained projects move in bursts rather than on a schedule, and the public record shows that pattern clearly: releases dated 2019, 2020, 2021, 2022, then a gap until 2026. A quiet period is not the same as an abandoned project, and an active period is not a commitment to future speed. Reading the repository's recent activity before a major macOS upgrade gives a far better estimate of near term responsiveness than any statement on a download page.

None of these makes the free option wrong. They describe what is being traded.

Three pricing shapes in this category

Comparing on the number alone hides the more useful distinction, which is the shape of the payment. All three shapes exist among macOS menu bar tools. Checked September 10, 2026 against each publisher's own pages.

Shape	How payment works	Example
Free and open source	No payment. Support runs through an issue tracker	This app under MIT, and Ice under GPL-3.0
Free base, paid add on	Core features free, one time purchase for extras	Vanilla, whose Pro tier is listed at 10 US dollars one time, with one activation code usable on up to 10 Macs and a 30 day money back guarantee
Paid with tiers	One time, yearly, and lifetime options side by side	Bartender, which lists a 4 week trial and a 14 day refund window

Prices on those pages change and some load dynamically, so the figures to act on are the ones shown at the moment of purchase, not the ones quoted in any article.

The shape drives the follow up questions. A one time purchase is usually a purchase of one major version, so the question is whether the next major version costs again. A yearly plan buys ongoing compatibility work, and stops buying it when payment stops. A free tool promises neither and asks for nothing.

One time or recurring, decided by four variables

The absolute amounts in this category are small enough that the decision rarely turns on price. It turns on these:

Expected lifespan of the setup. A tool being trialled for a few months makes a yearly plan cheap. A tool expected to run for five years makes a one time purchase cheaper in total, assuming major version upgrades are included.

Sensitivity to the macOS release cycle. A new macOS version ships every autumn. Anyone who upgrades in the first weeks needs the tool updated in the first weeks, which is exactly what recurring revenue funds.

Whether a reply is needed. Posting an issue and waiting is acceptable for a personal setup. It is a poor fit when a broken menu bar interrupts billable work.

Number of Macs. Activation limits set the effective per machine price. A licence covering up to 10 activations behaves very differently from one tied to a single machine.

These are also worth scoring for a household rather than a single machine. A licence limited to one activation makes a second Mac a second purchase, while a free tool scales at no cost and a 10 activation licence sits somewhere between the two. On a personal setup with two or three Macs, that single term often outweighs the headline price entirely.

Score those four. Nothing applies, and the free option is sufficient. Two or more apply, and the price difference in this category is unlikely to be the deciding factor.

Continuity is the risk worth pricing

The failure mode that actually costs something is not a price increase, it is a tool that stops working with no path forward. That risk looks different on each side of the paid line, and it is worth comparing directly.

For an MIT licensed project, the code stays available regardless of whether the original maintainers continue. Forking, patching, and redistributing are all permitted, and this category has demonstrated that: several menu bar tools in active use today started as forks or successors of earlier ones. Ice, published under GPL-3.0, currently shows 29,574 stars, which is a reasonable indicator that more than one maintained option exists if any single project pauses.

For a paid tool, the question to ask before purchase is what happens to licence validation if the company stops operating. A licence checked against a server behaves very differently from one validated locally, and the difference only becomes visible at the worst possible time. Refund windows and trial periods are published; server dependency usually is not, which makes it worth asking directly.

A cheap piece of insurance applies either way: keep a copy of the build that currently works. The GitHub release is a single archive of roughly 7.7 MB, small enough to keep alongside other setup files. That copy covers both the case where a project stops and the more common case where a new version behaves worse than the old one on a particular machine.

What to check besides the number

Price is the easiest thing to compare and the least likely to change a decision after the fact. Four other checks catch the changes that do. Applied here, against public information as of September 10, 2026:

Still shipping. The repository is public and active, the most recent release is dated March 3, 2026, and code activity is recorded as recently as June 15, 2026.

Still open to new users. Distribution continues through the App Store listing, GitHub releases, and the Homebrew cask, with no signup gate on any of them.

Same operator. Dwarves Foundation has been listed as the developer since the 2019 release, with no ownership change recorded in the project's public history.

No pricing change pending. There is no payment mechanism to revise. For a paid alternative this is the check that catches a plan being restructured or a perpetual licence turning into a subscription.

Run the same four against any paid option under consideration. Ownership changes and paid major version upgrades are the two that a pricing page alone will not reveal.

What is left to decide after the money question

Once price stops being the variable, what remains is how the tool behaves during an ordinary day. Whether a hidden icon can be clicked while the bar is still collapsed, how items positioned under the notch are handled, and how many permanent slots survive on a laptop screen all affect the number of interactions per day far more than the purchase price does.

The features page sets out what is possible when hidden items stay reachable without expanding, and the how it compares page places the different hiding techniques side by side. For the payment shape itself, the pricing page shows the terms in the same three way frame used above.

What to change first

Establish which build is installed and where updates will come from, since that single choice determines most of what free costs here. Then score the four variables above before looking at any price. If a hidden icon still needs to be clickable without unpacking the whole bar, that is a design question rather than a budget one, and Koffret is one of the options built around it.