xbar alternatives: decide what you can drop

Putting the output of a script into the menu bar is a small idea that scales badly. Five plugins are useful. Nine plugins mean the menu bar runs out of room and the thing you actually wanted to glance at has been pushed somewhere near the middle. That, or a quiet worry about how often the app gets updated, is usually what starts the search for an alternative.

Before comparing candidates, it helps to separate what the app is doing into distinct jobs, because most replacements cover some of them and not others. The details below were checked against public project pages on 10 September 2026.

Three jobs, not one product

Comparing feature lists side by side is the wrong first move here. The work involved splits into three parts, and different replacements handle different parts.

Running executables on a schedule. Any file that can be executed and prints to standard output, in any language, run at a fixed interval. The interval is not stored in a settings screen, it is part of the file name. Documentation gives the format as {name}.{time}.{ext}, with date.1m.sh refreshing every minute and modifiers covering seconds, minutes, hours, and days.

Turning standard output into a menu. This is the part with rules. A line consisting only of --- separates what appears in the menu bar from what appears in the dropdown. A pipe character splits a line's text from its parameters, and those parameters cover colour, font, size, links, keyboard shortcuts, truncation, and whether the item is clickable at all. Any tool that implements the same rules can run the same plugins unchanged.

Distributing plugins and collecting input. A browsable catalogue of ready made plugins, plus a way for a plugin to declare variables that the user fills in. Those declarations become environment variables at runtime, and their values are stored in a sidecar JSON file sitting next to the plugin.

Replacing the app means deciding which of the three to carry over. Someone with a folder of hand written plugins has a different answer from someone who installed four things from the catalogue and never opened a text editor.

Where the project stands right now

Facts before opinions. The most recent published release is v2.2.1-beta, dated 10 September 2024. The one before it, v2.1.7-beta, was published in October 2021, so there is a gap of roughly three years between them. Every release carries a beta tag. The licence is MIT, the stated requirement is macOS Catalina or newer, and the repository holds around 18,100 stars with 186 open issues.

The project describes itself simply:

xbar (the BitBar reboot) lets you put the output from any script/program in your macOS menu bar. Source: github.com

There is one distribution detail worth knowing, because it produces confusion in bug reports. Homebrew's catalogue currently ships v2.1.7-beta, which is not the newest published release. Its analytics page records 3,908 installations in the last year. So two people running the app from different sources can be running different versions while both believe they are current. Check the version before assuming a behaviour has or has not been fixed.

Sorting the candidates into three shapes

Candidates become easier to judge once grouped by shape rather than by feature count.

The first shape keeps the same plugin contract. Plugins move across unchanged, so migration cost is close to zero and the decision comes down to system requirements and update cadence.

The second shape changes where information lives. Instead of the menu bar, output goes onto the desktop, or the status bar rendering is replaced entirely with something configurable. The information need is met, but the menu bar crowding problem is sidestepped rather than solved.

The third shape gives up generality. If what you actually want is CPU load, network throughput, or battery health, a purpose built app covers it without any scripts to maintain.

The candidates

Everything in this table was checked on 10 September 2026.

Name	Where output lives	Latest release	Runs xbar plugins
xbar	Menu bar	September 2024	The original
SwiftBar	Menu bar	August 2026	Yes
Übersicht	Desktop widgets	December 2023	No
SketchyBar	Replaces the status bar	June 2026	No
Hammerspoon	Whatever you write in Lua	February 2026	No
Stats	Menu bar, fixed purpose	September 2026	No

The two columns that decide most cases are the last one and the release date. Plugin compatibility changes migration from an afternoon to a file move. Release cadence is the best available proxy for what happens when the next macOS version changes how status items behave.

Short descriptions, from each project's own page. Übersicht renders widgets written as JavaScript modules using JSX, and a widget can run a shell command and display its result. SketchyBar describes itself as a highly customisable macOS status bar replacement and is published under GPL-3.0. Hammerspoon is desktop automation driven by Lua, where menu bar items are something you construct yourself. Stats describes itself as a macOS system monitor in the menu bar.

When the plugins can come with you

SwiftBar is the candidate that keeps the contract. Its documentation states that the plugin API is adopted from BitBar and xbar, and that it can therefore run any existing plugin of that kind. File naming follows the same {name}.{time}.{ext} pattern.

The differences are worth knowing before moving.

Refresh intervals go finer. Millisecond modifiers are documented alongside seconds, minutes, hours, and days.

The plugin folder is your choice. Rather than a fixed path, the folder is chosen on first launch. Nested folders are traversed, symlinks included, hidden folders are skipped, and a .swiftbarignore file can exclude specific items.

Executable bits are handled. When a new file appears in the folder, the app makes it executable if it is not already. That removes the single most common reason a working script shows nothing in the menu bar.

The macOS requirement is higher. SwiftBar states macOS Monterey (12) and later, against Catalina (10.15) for xbar. On a Mac kept deliberately on an older release, that ends the comparison.

Adoption differs too. Homebrew's analytics record 25,678 installations of SwiftBar in the last year, against 3,908 for xbar, and the most recent stable release was published in August 2026.

Migration in practice is moving plugin files into the new folder and re entering values for any plugin that used variables. The old values are readable in the sidecar JSON files, so nothing has to be reconstructed from memory.

One habit is worth carrying across. Because the refresh interval lives in the file name, changing how often a plugin runs means renaming the file, and renaming it also resets its position in the menu bar in tools that remember order by file name. Doing the interval tuning first, before spending time arranging icons, saves repeating the arrangement. It is also the moment to ask whether a plugin that refreshes every ten seconds needs to. Intervals set during development and never revisited are a common source of both battery drain and a menu bar that changes width while you are trying to click something in it.

What does not carry over

Plugin scripts move cleanly. The surrounding conveniences do not, and they are easy to forget until the day after switching.

The catalogue. Plugins are browsable from inside the app and from the project's website, organised into categories such as network, system, finance, and weather. A replacement has its own catalogue with its own contents, so a plugin installed by clicking once may need to be found somewhere else or kept as a local file.

Variable prompts. A plugin can declare inputs in its metadata using tags, with types covering string, number, boolean, and select, and the app renders a form for them. The values become environment variables at runtime. The declarations are just comments in the source, so they travel with the file, but whether a given replacement renders a form from them is a separate question. The values themselves are recoverable either way, since they sit in a JSON file named after the plugin.

Control URLs. The app can be driven through xbar:// addresses that open a plugin, refresh a single plugin, or refresh all of them. Anything wired to those addresses, a Shortcuts action or a script that updates a variable file and then forces a refresh, stops working the moment the app is gone and needs rebuilding against whatever the replacement offers.

The dark mode signal. An environment variable is set to true or false when system appearance changes, so plugins can render differently in light and dark. A plugin that relies on it will still run elsewhere, it just will not receive the value, and the output silently picks one branch forever.

Update behaviour. A configuration file controls whether the app keeps itself updated, and it does not exist until created. Deleting it and restarting returns the app to defaults. None of that transfers.

The practical takeaway is to spend twenty minutes listing what is installed and what each item is for before moving anything. Half the list usually turns out to be things installed once out of curiosity, which shortens the migration and the menu bar at the same time.

When the answer is to stop using the menu bar

The menu bar is a fixed width strip shared by every app on the machine, and on a MacBook with a notch it is narrower than it looks. Adding a sixth plugin to it is a losing move regardless of which app renders it.

Desktop widgets trade visibility for room. Nothing is consumed in the menu bar, and there is space for charts rather than a truncated number. The cost is that full screen windows cover the display, so the information is present only when you look at the desktop.

Replacing the status bar rendering entirely gives the most control over appearance and position, at the cost of maintaining a configuration file rather than a settings window. Automation frameworks sit in the same territory, where the menu bar item is something you write rather than install.

There is also a version of this that requires no new software at all. A script that already runs on a schedule can post a notification when a threshold is crossed instead of displaying a number continuously, which turns a permanently visible item into something that speaks only when there is news. For anything checked once or twice a day rather than continuously, a terminal alias covers it, and the menu bar keeps the slot.

A purpose built monitor is the quietest option when the requirement is known and stable. Three plugins showing CPU, memory, and network collapse into one icon, and the scripts stop being yours to maintain.

What to change first

Count the things you genuinely look at several times a day, not the number of plugins installed, and decide whether the plugin files are coming with you. Those two answers narrow the field to two candidates at most. Then deal with the icons that remain regardless of which tool renders the scripts, because sync tools, backup agents, and update helpers will still be there: how it compares sets out the collapsing options next to each other, and Koffret is one of the tools in that group.