Brew Browser: a native GUI for Homebrew, shipped as a Tauri build and a SwiftUI build
Homebrew is the standard package manager on macOS. brew-browser gives it a real native GUI.
At a glance
- What is it?
- Brew Browser is a MIT licensed desktop front end over the brew CLI, with a dashboard, a filterable library, a 16k package catalog, curated bundles with a hardware readiness grade, Brewfile snapshots and opt-in CVE scanning. It is maintained twice, once in Tauri for macOS 13 plus Linux and once in Swift 6 and SwiftUI for macOS 26.
- Who is it for?
- Take Brew Browser if you manage a large Homebrew setup and want browsing, outdated tracking, a Brewfile snapshot and opt-in vulnerability scanning in one window instead of a pile of terminal commands. Take the Tauri build on macOS 13 or later or on Linux, and the native SwiftUI build only if you are on macOS 26 and care about the memory difference.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Brew Browser is for
Homebrew is the standard package manager on macOS and it has always been a terminal tool. Brew Browser gives it a desktop window: browse what you have installed, search the catalog, install, uninstall and upgrade with live output, and snapshot your setup to a Brewfile you can restore on a new machine. The audience is people who carry a few hundred formulae and casks across machines and want to see the state of that collection rather than reconstruct it from a scrollback. The README is unusually clear about the boundary, and the boundary is the selling point. Every action shells out to the real brew CLI, so nothing here forks package management or invents its own install logic. Trending data comes from the analytics Homebrew publishes at formulae.brew.sh rather than from a service the project runs.
Two builds, one data contract
The project is maintained as two implementations of the same app, kept in feature and data contract parity, and the README explains why: SwiftUI does not run on Linux and Liquid Glass is macOS 26 only. The Tauri build is Tauri 2 with SvelteKit and Rust, runs on macOS 13 and later plus Linux, and is the shipping signed and notarized download. The native build is Swift 6, SwiftUI and Liquid Glass, targets macOS 26 Tahoe, and is described as the genuinely native macOS flagship at about half the memory. Source lives in src/ plus src-tauri/ for the Tauri build and in native/ for the Swift package. Updates differ too, an in-app updater using minisign on the Tauri side and Sparkle 2 with ed25519 on the native side. Both read the same settings.json schema, the same bundled categories.json and enrichment.json, and issue the same brew and brew vulns invocations, and memory-bank/ is the canonical spec for both with a 2026-06-01 decision record to keep both.
The sections, and the ones worth the click
Dashboard is the overview: installed count, updates available, brew version, the formula and cask split, a top categories donut, and storage usage across Cellar, Caskroom, var/log and cache with a one click reveal in the file manager, plus Run brew doctor and Clean up cache with a reclaimable space estimate. Library is the dense filterable list of installed packages with outdated badges, sortable columns, category chip filters, a Vulnerable filter pill, inline severity dots and a Pinned filter with per package pin and unpin for formulae and casks, which is what stops a package you deliberately held back from being swept up by an update all. Discover searches the catalog of over 16k packages, bundled at build time and refreshable by the user, through a 19 category tile grid with subcategory drilldowns. Trending shows top packages over 30, 90 and 365 day windows with a velocity index comparing the recent month against the prior eleven, and opt-in per package sparklines. Services lists, starts, stops and restarts launchd managed services, and Activity streams every brew invocation into a resizable bottom drawer with full stdout and stderr, keeping the last 200 jobs across launches.
Bundles and the hardware readiness grade
Bundles is the newest headline feature and the most opinionated one. Nine curated stacks shipped at launch: Local LLMs, Image Generation, Graphics and Design, Media Toolkit, Web Dev Starter, Local Databases, Agentic Web Dev, LAMP and LEMP. Every token in every recipe was verified against brew info and draws only on homebrew/core and homebrew/cask, so no third party taps are involved. The part that separates it from a list of install commands is the system profile: Bundles reads RAM, architecture, GPU and disk with nothing installed and grades each stack Ready, Marginal or Not recommended, so an 8 GB machine is not told to install a local LLM stack it cannot run. Each bundle shows an intent paragraph, per package install with live installed state, expandable descriptions and a setup checklist where brew native steps such as starting a service or opening a URL run inside the app while external commands stay copy only. Recipes are validated JSON anyone can contribute against a published contract, and CONTRIBUTING-bundles.md covers that path.
Installing it and what it runs underneath
Both macOS builds ship on the latest release page, and the choice is by operating system: the Tauri build for macOS 13 or later and for Linux, the native build for macOS 26. Once it is running, the useful thing to understand is that the window is a front end and the work happens in brew. The commands the app drives are the ones you would type yourself.
brew doctor
brew bundle
brew services
brew vulnsbrew bundle is what the Snapshots feature uses to save and restore a Brewfile, brew services backs the Services section, and brew vulns is the official subcommand behind the opt-in security scanning, which queries OSV.dev and can enrich with GHSA data when you are signed into GitHub. Security is off by default and the app offers a one click installer for the subcommand when you opt in. If you want to work on the app itself, the frontend is SvelteKit on Vite and the desktop shell is Tauri 2 with a Rust side; the dev script runs the Vite dev server.
vite devType checking runs svelte-check against the project tsconfig and the unit tests run under vitest.
vitest runThe Swift side is a separate Swift package under native/ with its own release history, which is why the two version numbers differ while tracking the same feature batch.
Where it breaks, and what 0.7.2 fixed
The most instructive release is 0.7.2, published on 2026-07-20, because it is a story about depending on an external CLI that moves under you. In Homebrew 6.0 and later, the vulns subcommand moved into core and the standalone homebrew/brew-vulns tap and formula were deprecated and deleted. On a current Homebrew, that left vulnerability detection failing and the Install brew-vulns button chasing a formula that no longer exists. The fix falls back to brew help vulns when the legacy prefix check fails, changes remediation to brew update, and widens formula name validation to accept two segment tap qualified names in the form user/name alongside user/repo/name while still rejecting shell metacharacters and path traversal. The same release removed the startup macOS Keychain prompts caused by the app reading GitHub credentials. Two smaller frictions are worth knowing: the Linux auto-updater is unwired, so 0.7.1 changed CI to skip that artifact and publish the deb, rpm and AppImage installers again, and the catalog is bundled at build time, so a package added to Homebrew yesterday needs a refresh before Discover finds it.
Compared with a Brewfile and a terminal
The alternative most users already have is brew itself plus a checked-in Brewfile. That route is scriptable, reviewable in a pull request, and reproducible on a clean machine, and it needs no desktop app that has to be kept in step with a CLI that changes. It fails at discovery: there is no way to browse 16k packages by category, no trending signal to tell you what other people actually install, no readiness grade telling you whether your hardware can run a stack, and no live output drawer to watch a long upgrade. Brew Browser covers all four and is better for exploring and for day to day hygiene. It is worse for anything you want to automate or review, since the actions are clicks rather than a file you can diff. Running both is reasonable: use the app to find and maintain, and keep a Brewfile snapshot under version control as the record.
Licence and upkeep
The project is MIT licensed and its last push was on 2026-09-15, with releases 0.7.0 and 0.7.1 on 2026-07-15 and 0.7.2 on 2026-07-20. The privacy posture is stated as a feature: no analytics, no accounts, no phone home, and there is no paid tier because there is no tier at all. Upkeep cost is the obvious one to budget for, because maintaining two implementations of one app in two languages means every shared data contract change has to land twice, and the 37 open issues suggest the surface is not small. The repository also carries SECURITY.md, a gitleaks configuration, AGENTS.md and CLAUDE.md, plus a landing site and a docs directory, which is more process than a weekend project usually has.
Editorial conclusion
Take Brew Browser if you manage a large Homebrew setup and want browsing, outdated tracking, a Brewfile snapshot and opt-in vulnerability scanning in one window instead of a pile of terminal commands. Take the Tauri build on macOS 13 or later or on Linux, and the native SwiftUI build only if you are on macOS 26 and care about the memory difference. Skip it if you want scriptable, version controlled package management, because every action is a GUI click that shells out to brew and the README is explicit that this is not a Homebrew replacement. Before you rely on the security card, check your Homebrew version, since scanning only works through the built-in brew vulns subcommand that arrived in Homebrew 6.0.
Frequently asked questions
Does Brew Browser replace Homebrew?
No. The README states that every action shells out to the real brew CLI and describes the app as a thin frontend over it, so Homebrew stays the thing doing the work.
Which Brew Browser build should I download?
The Tauri build runs on macOS 13 and later plus Linux and is the shipping cross-platform download, while the native build is Swift 6 and SwiftUI with Liquid Glass, needs macOS 26 Tahoe, and is described as using about half the memory.
Why did vulnerability scanning stop working in Brew Browser?
In Homebrew 6.0 and later the vulns subcommand moved into core and the standalone homebrew/brew-vulns tap was deprecated and deleted. Release 0.7.2 fixed detection by falling back to brew help vulns and changed the remediation command to brew update.
Community notes