Comparison
Vee vs xbar
xbar pioneered the “any script → menu bar” format and the community plugin catalog that Vee also draws from. Vee runs your xbar plugins unchanged — natively in Swift/AppKit — and its central pitch is aimed at one specific, documented problem: xbar’s long-running memory growth.
The memory point, stated carefully
Vee doesn’t assert a benchmark; it points at xbar’s own issue tracker. Users have reported xbar’s memory usage climbing over a session into the multiple-gigabyte range, and those reports are still open:
Vee’s answer is architectural: the menu bar is a real NSStatusItem/NSMenu with no embedded WebView in the menu, subprocess output is drained incrementally, and runaway processes are timed out and killed — so long-running use is designed to stay light.
At a glance
| Vee | xbar | |
|---|---|---|
| Engine | Native Swift 6.2 / SwiftUI + AppKit | Go + Wails (WKWebKit WebView) |
| Menu rendering | Native NSStatusItem / NSMenu | WebView-based runtime |
| Long-running memory | Designed to stay light | Documented growth reports (open) |
| Runs xbar plugins | Yes, unchanged | Yes (native format) |
| Runs SwiftBar plugins | Yes | Shared core format |
| Trust-at-install layer | Yes — plain-language summary + badges | No |
| Plugin catalog | Built-in Discover (same catalog) | Web-based plugin site |
| 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 colors only |
| Desktop widgets | Yes — Notification Center tiles, with rich cards via <vee.surface> | No — menu bar only |
| Typed preference forms | Yes — Keychain secrets | <xbar.var> forms |
| Typed SDK | Yes — TypeScript, no build step | No |
| URL scheme | vee:// & swiftbar:// | xbar:// |
| License | MIT, open source | MIT, open source |
| macOS support | 26+ only | Wider (older macOS) |
| Architecture | Apple Silicon only | Intel + Apple Silicon |
| Install | Homebrew cask + notarized Releases | Homebrew cask + Releases |
What you keep when you move
Migration is just pointing Vee at your existing xbar plugins folder. The whole xbar protocol works — filename intervals, ---/-- menus, | params, <xbar.*> headers, SF Symbols, ANSI, Markdown, streaming — and Vee even injects xbar’s XBARDarkMode environment variable for plugins that switch appearance. See Migrating from SwiftBar/xbar.
What you gain
- Native menu rendering with no WebView in the menu, aimed squarely at the memory-growth reports above.
- A trust layer — plugins declare what they touch and Vee shows a plain-language summary before install. See the trust model.
- A typed TypeScript SDK with no build step. See the SDK docs.
- Keychain-backed secrets in auto-generated preference forms.
Bottom line — when to choose which
Choose Vee if…
- You’ve watched xbar’s memory climb over a day and had to relaunch it.
- You want the same plugins rendered by a native menu.
- You want a trust summary before installing catalog plugins.
- You’re on macOS 26 + Apple Silicon.
Choose xbar if…
- You need older macOS or an Intel Mac.
- Its memory profile isn’t a problem for your usage.
Prefer SwiftBar’s native approach? See Vee vs SwiftBar — and note that SwiftBar, like Vee, is native, so the memory argument above is specific to xbar’s WebView runtime, not to SwiftBar.