Dozer pricing: what the free tier covers

The price is zero. There is no trial that expires, no licence key, no per machine limit, and no paid tier sitting above a restricted free one. Anyone searching for a pricing page will not find one, because the project never had a commercial side.

That answers the literal question in a sentence, which leaves the more useful one. Software that costs nothing still costs something, and the interesting part of the comparison is working out where that cost went and whether it lands on someone who can absorb it.

The licence, and what it removes

Every source file in the project carries the same header:

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0.

Source: github.com

Mozilla Public License 2.0, published source, no payment path anywhere in the app. That removes three things that normally appear in a pricing discussion:

• Purchase mechanics. No checkout, no licence key to store, no reactivation after a machine rebuild.
• Seat limits. The same build goes on as many Macs as required, with no counting.
• A cliff when payment stops. Subscription tools degrade or lock when billing lapses. There is no billing here, so there is nothing to lapse.

That last point is worth sitting with, because it is the genuine advantage of this model and it is easy to undersell. A subscription tool holds a permanent claim on continued payment. A one time purchase leaves the bought version in place but often charges again for the next major release. Neither applies here.

The release record is the price list

With no money changing hands, the substitute for a pricing page is the maintenance record, and that record is public.

As of 10 September 2026, the newest downloadable release is 4.2.0, published on 13 July 2020. The two before it were 4.1.0 in November 2019 and 4.0.0 in August 2019, so releases were already a year or more apart while the project was active. The source repository was edited after that, most recently on 1 November 2022. The project carries 8,717 stars, which shows that popularity and release cadence are independent variables.

The reading is that the cost moved from money to time, and specifically to the reader's time. macOS ships a major release every year and adjusts menu bar behaviour along the way. In a paid tool, keeping up with that is what the money buys. In a freely published one, keeping up depends on whether the author still wants to, and there is no counterparty to hold to it.

One caveat about reading the record. Star counts support the claim that a tool works now. They say nothing about whether it will keep working. The two dates worth comparing are the last release and the last source commit, not the star count.

Three cost shapes, one table

Laying the models side by side makes the comparison points obvious.

Model	Payment	Who handles macOS changes	If payment stops
Freely published	None, donations optional	Whoever maintains it, if anyone	Nothing, there is no payment
One time purchase	Once	Often deferred to a paid major upgrade	The purchased version stays
Subscription	Monthly or yearly	Included while the contract runs	Features reduce or stop

Free wins the first and last columns outright. It has nothing at all in the third, which is where the disagreement lives.

A one time purchase sits in between. The bought version remains available, but there is no guarantee it survives a major macOS release, and the version that does survive may carry a new price. This model fits people who prefer owning a specific version and accepting a re-evaluation every few years.

A subscription is effectively renting the upkeep. Total spend grows with time, but the answer to who fixes this when macOS changes is unambiguous. For a utility that sits in the menu bar all day, some people weigh that higher than the monthly figure.

There is a fourth arrangement that shows up in this category and does not fit the table cleanly: published source combined with a paid build. The code stays open, and a signed, notarized binary is sold for the convenience of not compiling it. Anyone comparing options should read carefully enough to notice which of these is on offer, because the words free and open source get used for both, and the practical experience of installing them is very different.

One more thing the table cannot show. A paid tool has a support address, and the value of that is uneven. For a menu bar utility, most questions are answered by a settings pane rather than a person, so the address matters less than it would for something handling data. Where it does earn its keep is in the specific case of a macOS release breaking something, when the useful information is whether a fix is coming and roughly when. That answer is only available from someone who is being paid to give it.

The install path is part of the cost

Distribution effort rarely appears in a pricing comparison, and here it should.

The README offers two install routes: a package manager one liner, and a manual disk image download. Only the second currently works. The package manager index no longer lists the app, and a local query returns no match, so the documented command fails regardless of typing.

The manual route has its own step. The disk image is signed with an Apple developer certificate but is distributed without notarization. Apple has required notarization by default since macOS Catalina, as the support documentation states, so opening it produces a warning that stops the process until the reader chooses to override it.

On a managed Mac issued by an employer, this gets heavier still. Organisational policy often blocks unnotarized apps outright, in which case no local override helps and the conversation starts with IT. A tool that requires a purchase order can paradoxically be easier to introduce, because approval routes exist for purchases and not for overrides.

Multiple machines change the arithmetic again. No seat limit sounds like pure upside, and it is, but each machine repeats the same manual download and the same warning. The more Macs involved, the smaller the money gap and the larger the effort gap.

Architecture is a lifespan question, not a price question

Release 4.2.0 ships as an Intel only binary, so it runs on Apple silicon through the macOS translation layer. That works today. Apple has published how long that layer remains a general purpose facility, and it is not indefinite.

For a resident utility this matters more than for an app that gets opened occasionally. Menu bar tools are installed once and left alone for years, so the relevant question is not what it costs now but whether it still runs in three years without intervention. If the plan is to get through the current setup and revisit later, the point is moot.

Checking any app's build type takes a few seconds: select it in the Finder, open the info window, and read the Kind field. Apple documents the three values on the Apple support site. Worth applying to paid candidates as well, since a higher price does not automatically mean a newer build.

On a commercial product, this information usually sits on the system requirements page rather than the pricing page, and the two are worth reading together. The useful signals are whether Apple silicon support is stated explicitly, which macOS versions are listed as supported, and how recently the version history was updated. A tool that costs money and last shipped in 2021 is in a similar position to one that costs nothing and last shipped in 2020, except that the money has already been spent.

Donations are support, not a contract

The project page links to an external service for donating to the author. The amount is undefined and nothing changes if nothing is sent.

That decoupling is the whole point and also the limit. Donating is a reasonable way to back a tool that has earned its place, and it buys no promise of a next release, no response to a bug report, and no commitment to follow a macOS change. Anyone who wants those specific things is shopping for a support agreement, and support agreements come attached to prices.

The practical decision usually falls one of three ways:

• Unwilling to pay, able to absorb the effort. A freely published tool fits.
• Willing to pay for continuity and a place to send questions. A commercial tool fits.
• Start free, move to paid if the habit sticks. Common, and it works, with one caveat.

The caveat for the third path is that settings rarely transfer. Tools in this category store icon ordering and hidden groups in their own formats, so a move usually means rebuilding the arrangement by hand. Writing down the current order before switching turns that from an afternoon into a few minutes.

How a free tool actually ends

Commercial software announces its exit. There is an end of sale notice, a support window, and time to move. Freely published software usually just stops, and the reader finds out at the worst moment. In practice it shows up as one of these:

• A major macOS update lands and the behaviour changes overnight.
• A reinstall is attempted and the documented steps no longer work.
• The download page stays up while years pass without a new version.

None of these come with a warning, and none come with a migration path, because at zero cost there is no obligation to provide either. Whether that counts as a real cost depends entirely on how much disruption a broken menu bar would cause.

The mitigating factor, and it is a genuine one, is that published source can be picked up by someone else. The licence permits it, and abandoned projects in other categories have been revived exactly that way. What cannot be relied on is that it will happen on any particular timeline, so it belongs in the category of pleasant surprises rather than planning assumptions.

The practical response is to decide in advance what happens if the tool stops. For most people the honest answer is a tidier menu bar becomes an untidy one and a replacement gets found within a week, which makes the risk small enough to ignore. For anyone whose workflow genuinely depends on reaching a specific hidden control quickly, the answer is different, and that difference is worth the price of something with an owner.

What to work out first

Price is the least informative column in this comparison, so start with the other three: who fixes it when macOS changes, how much effort the install takes on every machine involved, and whether the build has a plausible three year life. Estimate what a sudden failure would actually cost in lost time, and compare that against the annual figure on any paid alternative. The Koffret pricing page sets out one such figure, the comparison page shows how the tools in this category differ structurally, and the FAQ covers the questions that come up before a purchase.