Comparison
Vee vs SwiftBar
SwiftBar is the category leader for good reason — native Swift, light, mature, MIT-licensed, and a Homebrew cask install away. Vee runs the same plugins, so think of it as a superset in practice: same native lightness, with a few things added on top. This page is honest about where each one wins.
At a glance
| Vee | SwiftBar | |
|---|---|---|
| Engine | Native Swift 6.2 / SwiftUI + AppKit | Native Swift / AppKit |
| Runs xbar/SwiftBar plugins | Yes, unchanged | Yes (its own format + xbar) |
| Weight / footprint | Native, light | Native, light |
| Trust-at-install layer | Yes — plain-language summary + badges | No |
| Built-in catalog browser | Yes — Discover, trust-gated install | No (install plugins manually) |
| Searchable filter panel + global hotkey | Yes — opt-in ⌘F fuzzy search across nested menus, optional system hotkey | No |
| Rich menu rows | Yes — progress= gauges, sparkline=, pie=/donut=/stackedbar= charts, and toggle=/slider= controls, drawn natively | No such params — text, images and SF Symbols only |
| Desktop widgets | Yes — Notification Center tiles, with rich cards via <vee.surface> | No — menu bar only |
| Typed preference forms | Yes — Keychain-backed secrets | Yes — <swiftbar.var> forms |
| Typed SDK | Yes — TypeScript, no build step | No official typed SDK |
| URL scheme | vee:// & swiftbar:// | swiftbar:// |
| License | MIT, open source | MIT, open source |
| macOS support | 26+ only | 10.15+ (much wider) |
| Architecture | Apple Silicon only | Intel + Apple Silicon |
| Install | Homebrew cask + notarized Releases | Homebrew cask + Releases |
| Maturity | v0.1.x — early | Mature, widely deployed |
Where Vee is different
A trust layer at install
This is the main reason Vee exists. Every menu-bar script runner executes plugins un-sandboxed — SwiftBar auto-chmod +xes and runs whatever lands in the folder, which is exactly the model the category needs to be useful. Vee keeps that model but makes it transparent: authors declare what a plugin touches (network domains, files, secrets, external binaries) with <vee.*> tags, and Vee shows a plain-language summary before you install, plus trust badges in the Plugin Manager. It’s advisory, not enforced — but at least you’re not running things blind. See the trust model.
A built-in Discover catalog
Vee ships a browser over the shared matryer/xbar-plugins catalog, with trust chips on each entry and one-click install through the trust gate. With SwiftBar you typically find plugins on the web and drop them into the folder yourself.
Refresh reliability after sleep
SwiftBar has open reports of refreshes not resuming reliably after the machine sleeps or wakes (#179, #390). Vee’s scheduler is built to keep intervals honest across sleep/wake cycles.
A typed SDK for authors
Vee has an optional zero-dependency TypeScript SDK with Menu/Section builders that Node runs directly — no build step — kept in lockstep with the Swift parser by a golden-fixture drift guard. See the SDK docs. SwiftBar plugins are hand-formatted text (which Vee also fully supports).
Where SwiftBar wins today
- Wider macOS support. SwiftBar runs on macOS 10.15+; Vee requires macOS 26 or later.
- Intel Macs. SwiftBar has an Intel build; Vee is Apple Silicon only.
- Maturity. SwiftBar is battle-tested across a huge install base; Vee is v0.1.x and early.
Bottom line — when to choose which
Choose Vee if…
- You want to see what a plugin touches before you install it.
- You’d use a built-in catalog with trust chips.
- You’ve hit refresh-after-sleep annoyances.
- You want a typed SDK for authoring.
- You’re on macOS 26 + Apple Silicon.
Choose SwiftBar if…
- You need older macOS (10.15+) or an Intel Mac.
- You value a long, proven track record over the newest features.
The good news: because Vee runs the same plugins, trying it costs nothing to switch back from. Point it at your existing folder and everything runs. See Migrating from SwiftBar/xbar.