Homebrew 7.0.0 Demotes Every Intel Mac and Explains Why the Rust Rewrite Never Shipped
Homebrew 7.0.0 landed on 13 September and moved Intel Macs to Tier 3. Buried in the Hacker News thread is the more interesting admission: the maintainers built the Rust rewrite everyone asks for, measured it, and found it slower.
The WJS Desk
Sep 13, 2026 · 7 min read
Homebrew 7.0.0 shipped on 13 September 2026. The headline changes are the ones that break things: macOS 10.15 Catalina and earlier are gone, the minimum is now Big Sur 11, and every Intel Mac has been moved to Tier 3, which in Homebrew's language means unsupported.
We went looking for the performance numbers and found something better in the announcement thread. Lead maintainer Mike McQuaid answered the question the project has been asked since 2020, which is why Homebrew's CLI is still Ruby. The answer is that somebody built the Rust version and it lost.
What 7.0.0 actually changes
The release is large enough that it is worth separating the parts that affect you today from the parts that are announcements.
Breaking, immediately: macOS 10.15 and earlier are unsupported, the .pkg installer is Apple Silicon only and requires macOS Sequoia 15 or later, and the ghcr.io/homebrew/ubuntu22.04 Docker image is gone. On Linux, Bubblewrap sandboxing has been replaced by Landlock, which the notes say requires "no dependencies or escalated Docker permissions." If you were running Homebrew in a container with extra privileges purely to make the sandbox work, you can stop.
Deprecated with a long runway: third-party formula post_install blocks and cask *flight blocks are on the way out in favour of declared *_steps, with December 2027 as the deadline. If you maintain a tap, that is your work item, and it is not urgent.
New surface: brew install --dry-run gives a unified formula and cask preview, brew list --no-installed-on-request tells you which packages are only present as somebody else's dependency, and brew services now reads persistent overrides from $HOMEBREW_USER_CONFIG_HOME/services/<formula>.env. That last one is the quiet quality-of-life win, because it means service environment tweaks survive a reinstall.
There is also BrewUI, a native macOS graphical app, now fully released and installable with brew install homebrew-app. The design decision worth noting is that it "shows the underlying brew commands for package operations," which is the difference between a GUI that teaches you the tool and one that hides it.
The Intel decision, and who it hits
Tier 3 is not deletion. The release notes are specific: existing bottles remain, but updated formulae may require source builds. Your 2019 iMac will keep working and will get progressively slower to update as more packages have to compile locally.
The justification is the most quotable thing in the notes, and McQuaid repeated it in the thread when an Intel iMac owner said goodbye:
If Apple and Microsoft's GitHub, two of the world's largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew.
The supporting facts are checkable. Apple has dropped Intel x86_64 from macOS 27 Golden Gate, and GitHub Actions is retiring its Intel macOS runners in autumn 2027. A volunteer project cannot build bottles on runners that do not exist.
To Homebrew's credit, the notes send Intel users somewhere specific rather than shrugging: "MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform." That is a maintainer telling you to use a competitor, which is rarer than it should be.
The sharpest reply in the thread came from jezek2, and it barely got upvoted: "How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?" Nobody answered it. The honest answer is that MacPorts builds from source by default, so it never had a bottle-building fleet to lose, which is a different trade rather than a better one. But the question deserved a reply.
basiliobeltran, running one of the last Intel Macs on Sonoma, put the cost plainly: "How long should I expect working tech being supported? I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop."
The Rust rewrite that got built and then measured
Homebrew has had an open issue about rewriting its CLI in a compiled language since June 2020. In the 7.0.0 thread, a commenter asked whether it was still happening. McQuaid's reply is the paragraph we would have led the release notes with:
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches). The lessons learned were instead used to make the Ruby frontend much faster.
A project built the rewrite the internet demanded, measured it, lost, and shipped the lessons instead.
The qualifier is doing real work there: non-synthetic benchmarks, specifically repeated installs with warm caches. That is the workload a package manager actually has. A cold-start microbenchmark of process spawn time would almost certainly favour Rust, and would tell you nothing, because Homebrew spends its time on network requests, disk writes and subprocess coordination rather than on interpreting Ruby.
You can see that conclusion reflected in what 7.0.0 optimised. brew install, brew reinstall and brew upgrade now overlap package preparation with downloads. brew config gathers independent system details concurrently. Startup launches fewer subprocesses. None of those wins require a different language.
What we measured, and what we did not
The desk Mac runs Homebrew 6.0.22 on Apple Silicon under macOS 26.5.1, with 120 formulae and 4 casks installed. We took baseline timings, three runs each, so anyone upgrading has a before number to compare against:
| Command | Homebrew 6.0.22, 120 formulae |
|---|---|
brew --version | 0.02 to 0.03 s |
brew list --versions | 0.26 to 0.31 s |
brew deps --tree --installed | 0.32 to 0.36 s |
brew outdated --quiet (cold) | 10.79 s |
brew outdated --quiet (warm) | 0.34 to 0.40 s |
We did not upgrade. This ran unattended on a working machine, and a major version with breaking changes is not something to apply to somebody's daily driver without them watching. So we have no 7.0.0 numbers of our own. Every speed claim below is attributed, and you should treat it as attributed.
The thread's own evidence is a single data point and worth exactly that. d3Xt3r posted: "Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was!" That is one person, one machine, no measurement, and they went looking for an explanation after noticing. It is the best kind of anecdote and it is still an anecdote.
The 30x gap between our cold and warm brew outdated is the useful context. Most of what feels slow about Homebrew is cache state and network, which is exactly what McQuaid's non-synthetic benchmark point was about.
The security story is smaller than the headline
The notes list "built-in brew vulns" among the 7.0.0 features. We checked ours before writing that up:
$ brew vulns --help
Usage: brew vulns [options] [formula ...]
Check formula for known security vulnerabilities using the OSV.dev database.That is Homebrew 6.0.22. The command already exists, already queries OSV.dev, and already takes --deps and --brewfile. So if you read the release notes and thought vulnerability scanning arrived today, it did not.
What is new is underneath it. Homebrew has published its own advisory database, which "records vulnerabilities against the formula versions and revisions Homebrew ships," plus advisory findings in the formula API and a downloadable advisory index. That matters because OSV.dev tracks upstream version ranges, and Homebrew's revision numbers and backported patches do not always line up with them. Mapping advisories onto what Homebrew actually shipped is the harder half of the problem, and it is the part that reduces false positives.
Also new and worth knowing: sandboxed builds now block reads of your home directory by default. If a formula's build was quietly picking up a config file from ~, it will stop.
One more exchange is worth surfacing. A commenter asked how to apply a cooldown period to Homebrew itself, the way you might delay npm or PyPI packages to dodge a supply chain attack. McQuaid: "You can't, by design. We instead apply it for you on upstream packages from NPM, PyPi, etc. Our model is very different to those where cooldowns exist and make sense. As-is it would just delay security updates too." Agree or not, it is a stated position rather than an oversight.
What we would actually do
On Apple Silicon, upgrade, but do it when you are watching rather than in the middle of something. The breaking changes are concentrated in platforms and tap authoring, not in daily commands, and the concurrency work is the kind of change that either helps or is invisible.
On an Intel Mac, do not panic and do not rush. Tier 3 means bottles you already have keep working. Take the release notes' advice seriously and evaluate MacPorts before your next big upgrade rather than after something breaks. The 2027 dates are real deadlines, and they are far enough away to plan around.
If you maintain a tap, the post_install and *flight deprecation has until December 2027. Put it on the list, not on today.
The part worth carrying past this release has nothing to do with Homebrew. A widely used project spent real effort building the rewrite its community kept asking for, measured it against the workload it actually has instead of the workload that flatters the new language, got a result it did not want, and published it in a comment thread. We would like more of that and less of the version where the benchmark quietly matches the conclusion somebody already reached.
