Most of the casks that disappeared from Homebrew in the last couple of years didn’t go because the software was bad. They went because the author hadn’t paid Apple.
That’s not how anyone phrases it. The PR says the cask failed brew audit. The audit says the binary is unsigned, or signed but not notarised, or signed by a Developer ID that doesn’t match the bundle. The deprecation policy gives the cask a sunset date. From the outside the chain looks like quality control. From the maintainer’s side it’s a $99-a-year invoice from Cupertino.
The chain#
macOS has shipped Gatekeeper for over a decade. The change that matters happened with notarisation in 10.14.5: from that point on, a freshly-downloaded app that isn’t signed with a Developer ID and stapled with a notarisation ticket gets a dialog reading “Apple could not verify [App] is free of malware that may harm your Mac”. There is a workaround. Right click, Open, confirm twice. Anyone who has been on a Mac for a while knows it. Most users don’t, and even those who do react badly to a fresh-install dialog that sounds like an antivirus warning. The friction is enough to put people off.
Homebrew Cask saw the friction and decided to optimise the install path. Casks are audited on every PR. The auditor checks for a valid Developer ID signature and a notarisation ticket. When a cask fails, the maintainer gets a heads-up; if it stays failing, the cask gets a disable! directive and a deprecation window. After the window, it’s gone from homebrew/cask.
I don’t think that’s a malicious policy. The cask review team is trying to keep the default brew install --cask foo experience from ending in a dialog box, because if a user has to learn about the right-click trick on their first cask install they will assume Homebrew is broken, and the maintainer will spend the next month answering “doesn’t work on my Mac” issues. The cost-benefit makes sense in isolation, but the policy is also, in practice, a paywall on inclusion in the central repo.
What a Developer ID actually costs#
The list price is $99 per year for the Apple Developer Program. That’s the part everyone quotes. The rest of it is less visible:
- You need an Apple ID with a real name, recovery email, and phone number. Apple’s terms forbid pseudonymous developer accounts and they have started enforcing it.
- Outside the US, Apple’s regional availability is its own problem. The program isn’t available in every country, and where it is available it sometimes wants a registered legal entity and a tax ID.
- The toolchain is a 12 GB Xcode install for
codesign, plusnotarytooland an app-specific password for notarisation. The upload step sends your binary to Apple for scanning before they staple the ticket. - Renewal is mandatory. If membership lapses, existing signatures still validate on already-installed Macs, but anything you ship after the lapse fails the audit.
For a salaried developer working on Mac software professionally, none of this is a real obstacle. For someone maintaining a single utility on GitHub on their weekends, the maths looks different. $99 of recurring cost, an annual identity check, and a build pipeline that calls home to Apple is not nothing to keep a free tool listed in someone else’s package repo.
Who gets cut#
The casks I have seen disappear, or watched limp along under deprecation, tend to fall into a small number of buckets.
A lot come from hobbyists with one tool. A keyboard remapper, a window manager, a status bar widget. The author wrote it for themselves, put the binary on GitHub Releases, and never thought of themselves as a “developer” in the Apple-business-relationship sense. Paid membership isn’t something they want to deal with. Cask gone.
Some are forks. The original author of an app has moved on; a couple of people keep it building on modern macOS. They can’t sign with the original Developer ID because they aren’t the original developer, and the fork is unpaid work that nobody wants to put a credit card behind.
Some come from regions where Apple’s Developer Program is hard to access at all. Iran, Cuba, parts of Russia post-2022. The signing requirement isn’t an opinion about their software, but the effect is the same as a ban.
Reproducible-build projects want anyone who builds from source to get a binary that hashes identically to the released one. Notarisation rewrites the binary, and the two goals don’t easily reconcile without extra workarounds.
And then there are people who simply don’t want to do business with Apple. Some are loud about it, most aren’t. They look at the developer agreement, the price, and the binary-scanning step, and decline.
In every one of those buckets the software is fine. The cask gets removed anyway.
What’s left for the user#
Homebrew has not closed every door.
brew tap lets anyone publish their own cask repository. A user runs brew tap somebody/repo and then brew install --cask somebody/repo/app. The cask doesn’t have to pass the central audit. The downside is discoverability: nobody finds the cask by typing brew search, and the implicit “this is in homebrew/cask” stamp of approval is gone. Users have to find the tap on their own and decide to trust it.
brew install --no-quarantine bypasses the Gatekeeper quarantine bit at install time, which side-steps the scary dialog even on unsigned binaries. The cask still has to exist somewhere for the user to install it, and the flag is something the user has to know to type.
Some projects ship a DMG with installation instructions that include xattr -d com.apple.quarantine. That works but it’s a manual step on each version bump and it doesn’t get the project a Homebrew install button on its README.
None of those is a substitute for being in homebrew/cask itself.
What it would take to fix#
Homebrew didn’t invent the signing requirement; Apple did, and Homebrew decided not to absorb the cost of disagreeing. A different posture would look like:
- A second-tier cask repository (
homebrew/cask-unsigned?) for casks that pass every other audit but fail signature verification, with--no-quarantineapplied automatically. Users opt in to the tier the same way they opt in tohomebrew/cask-fonts. - Better first-class tooling for self-hosted taps, so a maintainer can publish a cask without spinning up their own repository skeleton from scratch.
- An install flow that handles the Gatekeeper dialog itself: detect the unsigned binary, walk the user through right-click-Open or
xattrremoval, and treat it as a one-time setup rather than a per-app crisis.
None of those are on the roadmap as far as I can see. The current trajectory is the opposite. Each year the audit tightens, each year more casks fail it, each year more open-source software is no longer one brew install away.
If you’ve ever wondered why a small Mac utility you used a year ago is suddenly missing, this is usually the reason. The software didn’t die; it just couldn’t, or wouldn’t, pay the rent.