We maintain separate Taps for different types of binaries. Our nomenclature is:
Stable versions live in the main repository at Homebrew/homebrew-cask. They should run on the latest release of macOS or the previous point release (High Sierra and Mojave as of late 2018).
When software is only available as a beta, development, or unstable version, its cask can go in the main repo. When stable versions become available, only those will be accepted as subsequent updates.
Alternative versions should be submitted to Homebrew/homebrew-cask-versions.
When an App exists in more than one language or has different regional editions, the
language stanza should be used to switch between languages or regions.
Before submitting a trial, make sure it can be made into a full working version without the need to be redownloaded. If an App provides a trial but the only way to buy the full version is via the Mac App Store, it does not belong in any of the official repos. Freemium versions are fine.
Forks must have the vendor’s name as a prefix on the Cask’s file name and token. If the original software is discontinued, forks still need to follow this rule so as to not be surprising to the user. There are two exceptions which allow the fork to replace the main cask:
For unrelated Apps that share a name, the most popular one (usually the one already present) stays unprefixed. Since this can be subjective, if you disagree with a decision, open an issue and make your case to the maintainers.
We do not accept these casks since they offer a higher-than-normal security risk.
Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware — what is useful to one user may be seen as malicious by another.
But we’d still like for users to enjoy some kind of protection while minimising occurrences of legitimate developers being branded as malware carriers. To do so, we evaluate casks on a case-by-case basis and any user is free to bring a potential malware case to our attention. However, it is important to never forget the last line of defence is always the user.
If an app that bundles malware was not signed with an Apple Developer ID and you purposefully disabled or bypassed Gatekeeper, no action will be taken on our part. When you disable security features, you do so at your own risk. If, however, an app that bundles malware is signed, Apple can revoke its permissions and it will no longer run on the computers of users that keep security features on — we all benefit, Homebrew Cask users or not. To report a signed app that bundles malware, use Apple’s Feedback Assistant
We are also open to removing casks where we feel there is enough evidence that the app is malicious. To suggest a cask for removal, submit a Pull Request to delete it, together with your reasoning. Typically, this will mean presenting a VirusTotal scan of the app showing it is malicious, ideally with some other reporting indicating it’s not a false positive.
Likewise, software which provides both “clean” and malware-infested versions might be removed from the repo — even if we could have access to the good version — if its developers push for users to install the bad version. We do so because in these cases there’s a higher than normal risk that both versions are (or will soon become) compromised in some manner.
If a cask you depend on was removed due to these rules, fear not. Removal of a cask from the official repositories means we won’t support it, but you can do so by hosting your own tap.
Casks which do not reach a minimum notability threshold (see Rejected Casks) aren’t accepted in the main repositories because the increased maintenance burden doesn’t justify the poor usage numbers they will likely get. This notability check is performed automatically by the audit commands we provide, but its decisions aren’t set in stone. A cask which fails the notability check can be added if it is:
Note none of these exceptions is a guarantee for inclusion, but examples of situations where we may take a second look.
From the inception of Homebrew Cask, various requests fell under the umbrella of this reply. Though a somewhat popular request, after careful consideration on multiple occasions we’ve always come back to the same conclusion: we’re not a discoverability service and our users are expected to have reasonable knowledge about the apps they’re installing through us before doing so. For example, grouping casks by categories is not within the scope of the project.
Amongst other things, the logistics of such requests are unsustainable for Homebrew Cask. Before making a request of this nature, you must read through previous related issues, as well as any other issues they link to, to get a full understanding of why that is the case, and why “but project x does y” arguments aren’t applicable, and not every package manager is the same.
You should also be able to present clear actionable fixes to those concerns. Simply asking for it without solutions will get your issue closed.
However, there is a difference between discoverability (finding new apps you didn’t know about) and searchability (identifying the app you know about and want to install). While the former is unlikely to ever become part of our goals, the latter is indeed important to us, and we continue to work on it.
Before submitting a Cask to any of our repos, you must read our documentation on acceptable Casks and perform a (at least quick) search to see if there were any previous attempts to introduce it.
Common reasons to reject a Cask entirely:
binaryartifact). In that case, and in the spirit of deduplication, submit it first to Homebrew/core as a formula that builds from source. If it is rejected, you may then try again as a cask (link us to the issue so we can see the discussion and reasoning for rejection).
soapui, whose installation problems were not fixed in the two subsequent submissions (#9969, #10606).
Common reasons to reject a Cask from the main repo:
Follow the guidelines above and your submission has a great chance of being accepted. But remember documentation tends to lag behind current decision-making and we can’t predict every case. Maintainers may override these rules when experience tells us it will lead to a better overall Homebrew.