Ice pricing: what the free tier covers

Searching for Ice pricing tends to end in confusion, because there is nothing to find. The app has no price page, no upgrade prompt, no licence key field and no trial timer. That absence is not an oversight, and it is not a sign that the paid tier is hidden somewhere. It is the whole business model, and it changes which columns are worth reading before installing anything on a Mac that already has a crowded menu bar.

Everything below was checked against the developer's own pages and the Homebrew package definition on 10 September 2026. Dates matter more than usual here, so they are stated inline rather than left implied.

No price page means a different set of questions

Menu bar utilities on macOS split into three commercial shapes: pay once, pay monthly or yearly, or pay nothing. The third shape splits again. Some free apps recover the cost through a paid tier or through advertising, which makes the free tier a boundary to map. Others publish their source code and leave payment entirely to the user's discretion, which removes the boundary altogether.

Ice sits in the second group. There is no feature that unlocks after payment, because there is no payment. So the question "what does the free tier cover" resolves to "everything that exists", and the useful question becomes a different one: what is not being promised in exchange.

That reframing points at four columns. What the licence permits. How the app is distributed and installed. How often new versions have actually shipped, and when the last one landed. Where support requests go when something stops working. Those four apply just as well to a paid utility. The price column is simply blank, which removes one input and leaves the rest intact.

There is a macOS-specific reason to put release history above everything else. Menu bar managers work close to parts of the system that Apple reserves for itself, reading the position of status items and moving them around. A major macOS release can change that surface, and an app in this category depends on being updated when it does. For a paid app, the annual fee is partly buying that maintenance. For a free one, the same maintenance is a matter of the developer's available time.

Where the app comes from, and what the installer asks for

Two distribution routes are documented. The first is a zip archive from the project's releases page, unpacked and dragged into the Applications folder. The second is Homebrew, using brew install --cask jordanbaird-ice.

Neither route involves a checkout page, an account, an email address or an activation step. The Homebrew cask definition is short enough to read in full, and it describes three things: place Ice.app into /Applications, quit the running process and remove the login item when uninstalling, and delete four specific support files when the user asks for a full cleanup. Nothing in it resembles licensing or payment logic.

Install volume is public through Homebrew's own analytics. The cask records 4,787 installs in the last 30 days, 15,021 in 90 days and 61,460 over the last year, as of 10 September 2026. The source repository carries 29,574 stars. Both figures undercount the real total, since anyone who downloaded the zip directly is invisible to Homebrew's counter. The numbers are useful less as a popularity contest and more as a rough signal that problems get reported by somebody other than the reader.

What GPL-3.0 covers, and what it deliberately does not

The project is published under GPL-3.0. In practical terms for someone deciding whether to run it on a work machine, that licence carries four consequences.

The source is public, so the behaviour of the app can be inspected rather than trusted. Modification and redistribution are permitted. Redistributing a modified version obliges the distributor to publish the modified source under the same terms. And there is no warranty of any kind, which means no contractual party is liable if something goes wrong.

The last two points are where the licence stops being an abstraction. A purchased utility usually comes with a support address and terms that name a company. A GPL-3.0 project comes with a public issue tracker and a maintainer under no obligation to answer. Neither arrangement is wrong. They are different allocations of risk, and the right one depends on whether the Mac in question is a personal laptop or a machine that has to work on a deadline.

For company-issued hardware there is one more step that is easy to skip. Many organisations have a software policy that treats copyleft licences differently from commercial ones, sometimes prohibiting them outright on managed machines. Zero cost removes the purchase approval, not the policy check.

Donations exist and change nothing about the app

The project links to GitHub Sponsors and to Buy Me a Coffee. Both are optional. Neither is advertised as unlocking features, priority support, or an early build.

The distinction matters because the habit of paying for software carries an expectation with it. Sending money here does not create a support relationship, does not put a bug at the top of a queue, and does not affect what the app does on the machine. It funds the continuation of something that already works. Reading it as a paid tier leads to disappointment on both sides of the transaction.

The inverse is equally true. Declining to donate does not degrade anything, insert a reminder dialog, or limit the feature set. There is no nag screen to dismiss.

Seats, discounts and volume deployment do not apply

Anyone who has bought Mac utilities before arrives with three habitual questions: how many machines does one licence cover, is there an education discount, and is there a volume programme for deploying across a team. None of the three has an answer here, because none of the underlying mechanisms exist.

Without a licence key there is no seat count. The same build can go on a personal laptop, a work machine and a desktop at home without any activation limit being consulted or exceeded. Households with several Macs install it on each one and stop thinking about it. Education discounts and volume pricing both require a list price to discount, so neither has been set up.

Deployment across a fleet becomes a distribution task rather than a purchasing one. An organisation using a management tool to push applications can package the app and ship it, with no licence assignment step, no renewal date to track and no seats to reclaim when someone leaves. That removes a genuine administrative burden.

What replaces it is less visible. A paid utility deployed to fifty machines costs fifty times the unit price and comes with a vendor address to escalate to. A free one deployed to fifty machines costs nothing and comes with an internal owner who has to answer when a macOS update changes something. The expense does not disappear so much as move from the budget line to somebody's calendar. For a small team that trade is usually favourable. For a fleet large enough that a single support ticket multiplies into fifty, it is worth costing out honestly before rolling anything out.

Free and actively maintained are two separate claims

This is the section most likely to change a decision, so the facts are listed with their dates attached, all verified on 10 September 2026.

The shipping version is 0.11.12, which has not reached a 1.0 milestone. The update feed used by the app's own auto-updater records that release as published on 29 October 2024. No newer build has been distributed through that feed since. On the source side, the most recent change to the main branch is dated 20 September 2025. The stated system requirement is macOS 14 or later, expressed only as a floor, with no upper bound listed for versions confirmed to work.

There is no notice of discontinuation, no suspension of downloads, no change of owner and no pricing change, because there is no price to change. One structural detail can look alarming and is not: release binaries live in a separate repository from the source code, so the download link points somewhere other than the main project page. That is a housekeeping arrangement by the same developer.

The project's own description states the position plainly:

Ice is currently in active development. Some features have not yet been implemented.

How much weight to put on the gap between October 2024 and today depends entirely on circumstances. A Mac running a macOS version where the app already works, doing a job it already does, is not affected by the absence of a new build. A machine about to take a major OS upgrade is a different case, because nothing guarantees behaviour on a version released after the last build was made. Testing costs nothing, which is one genuine advantage of this pricing model.

What each payment shape actually asks of the user

Comparing prices across this category is less informative than comparing what each arrangement promises.

Arrangement	Cost	What the user takes on
Open source, no charge	None	Support runs through a public tracker. No committed release schedule
Optional donation	Chosen by the payer	Identical to the row above. Amount and features are unlinked
One-time purchase	Paid once	A future major version may be sold separately
Subscription	Monthly or yearly	Check before subscribing whether the app stops working when payments stop

Ice occupies the first two rows. If a paid alternative is under consideration, the question worth asking before comparing headline numbers is what happens to the configuration and to the app itself when the arrangement ends. A menu bar layout that took an afternoon to arrange has a real cost attached to it, and that cost is not on any price page.

Three questions that settle it

Because there is no purchase decision, the only decision left is whether this arrangement is acceptable.

Does it run on the macOS version currently installed? With only a floor published, this can only be answered by installing it. That test is free and reversible, and uninstalling is a short procedure.

Is granting screen recording access acceptable? The current build treats that permission as optional rather than required, and runs in a reduced mode without it. Deciding this in advance changes which features are even on the table.

Is there time to investigate when something breaks? Support arrives when a volunteer has capacity. On a machine used for paid work every day, that single factor often outweighs a subscription fee that would otherwise look expensive.

What to change first

Install it, spend ten minutes deciding which icons belong in the hidden section, and watch how the arrangement holds up over a week of ordinary work. If the sticking point turns out to be reaching a hidden icon quickly rather than hiding it in the first place, compare the interaction models on how it compares and check the permission requirements listed under FAQ before installing anything else. A build of Koffret can be tested alongside it, since two menu bar managers running at once is a configuration worth avoiding permanently but perfectly workable for an afternoon of evaluation.