xbar alternatives: decide what you can drop

For most people looking for an xbar alternative, the answer is SwiftBar. It is free and open source, it runs existing xbar and BitBar plugins without changes, it requires macOS 12 Monterey or later, and it shipped a stable release in August 2026. The other candidates make sense only when the plugins are going to be rewritten anyway: Raycast's menu bar commands for people who already live in Raycast, and Hammerspoon for people whose menu bar item is one piece of a larger automation.

The rest of this guide covers where xbar stands today, how to move plugins across without losing any, how the three routes differ, and the question that usually sits underneath the search: how many script outputs the menu bar can hold before some of them stop being drawn. Release dates and requirements below were checked on the projects' own pages on 18 October 2026.

Where xbar stands on 18 October 2026

xbar still works for many people, so the case for moving is about trajectory rather than a sudden failure. Here is what the project's own pages show.

Item	xbar	SwiftBar
Latest release	v2.1.7-beta, 29 October 2021	v2.1.1, 11 August 2026
Newer builds	None since 2021	v2.1.2 betas, latest on 29 September 2026
macOS requirement	Catalina 10.15 or newer	Monterey 12 or later
Licence	MIT	MIT
Plugin format	xbar / BitBar	Same format, plus extensions

The xbar figures come from its GitHub releases page and README. Every xbar release since the 2.0 rewrite carries the beta label, and the last one is now almost five years old. The repository has received occasional commits since, with the most recent push in September 2024, and its issue tracker held 185 open issues on the check date. The README also asks contributors not to send pull requests to the main repository without opening an issue first, and says they will likely not be accepted.

None of that means xbar will stop running tomorrow. It does mean that a macOS change which breaks it has no obvious path to a fix. For a tool that sits in the menu bar all day and runs scripts on a timer, that is a reasonable reason to move while things still work, rather than after an update.

The SwiftBar figures come from its releases page and its README. The project is active, with stable and beta builds through 2026.

SwiftBar: the drop-in route

SwiftBar's README states that its plugin API is adopted from BitBar and xbar, which means it can run any existing BitBar or xbar plugin. In practice that holds for the common case: a script that prints lines to standard output, with --- separating the menu bar title from the dropdown, and parameters such as href= or shell= on each line.

Refresh intervals carry over too. xbar reads the interval from the file name, in the form {name}.{time}.{ext}, so date.1m.sh refreshes every minute, as described in the xbar plugin guide. SwiftBar reads the same pattern, with suffixes from milliseconds (ms) up to days (d).

Where SwiftBar goes further is in plugin types xbar never had:

• Cron schedules. A <swiftbar.schedule> metadata tag accepts cron syntax, so a plugin can run at 9:00 on weekdays instead of every N minutes.
• Refresh on open. <swiftbar.refreshOnOpen>true</swiftbar.refreshOnOpen> reruns the script when the menu is clicked, before it is shown, which suits data that only matters at the moment of looking.
• Shortcuts plugins. A Shortcut from the Shortcuts app can produce the output, with a refresh schedule set in SwiftBar's settings, so no script file is needed.
• Ephemeral plugins. Items created on demand through a URL scheme or a Shortcut action, with an optional exitafter time in seconds. The README suggests them for notifications and other temporary items.
• Streamable plugins. A long-running process that updates the item each time it prints a ~~~ separator, intended for streams such as a websocket feed.

Ephemeral items are worth noting for anyone whose menu bar is already full. A build status that exists only while a build is running takes no space the rest of the day.

Moving plugins across without losing any

The move takes about as long as reading the plugin folder. These steps keep the old setup intact until the new one is confirmed.

1. List what is installed. xbar keeps plugins in ~/Library/Application Support/xbar/plugins, according to its README. Open the folder in Finder and note each file name, since the name carries the refresh interval.
2. Note anything that depends on xbar's own features. Plugins that use xbar's variables feature keep the user's values in a separate file next to the plugin, such as tail.5s.sh.vars.json. Copy those values somewhere readable before the move, so they can be set again if the new tool reads them differently.
3. Install SwiftBar. Download from the releases page, or run brew install swiftbar as the README shows.
4. Choose a plugin folder. SwiftBar asks for one at first launch. Pointing it at a copy of the xbar folder, not the original, keeps a clean fallback.
5. Quit xbar before testing. Running both at once with the same plugins produces two copies of every item, which makes the bar look broken when it is only doubled.
6. Check each item. Confirm the title, the dropdown and one click action. SwiftBar's README says it makes a new file in the plugin folder executable if needed, so an error is more often the shebang line pointing to an interpreter that does not exist on this Mac.
7. Remove xbar from login items once everything has run for a few days, under System Settings, General, Login Items & Extensions.

The usual failures are environmental rather than format problems. A script that called node or python3 by name may have worked under xbar because of the environment it inherited, and fail elsewhere. The xbar plugin guide's own advice is to give the full path to the interpreter in the shebang for Node and similar runtimes. Doing that during the move removes a whole class of errors.

Raycast menu bar commands: when a rewrite is coming anyway

Raycast takes a different approach. A menu bar item is a command inside a Raycast extension, written in TypeScript and React, with its mode set to menu-bar. Existing shell plugins do not run as they are. Each one becomes a small extension.

That trade suits a specific person: someone who already uses Raycast daily and wants the menu bar item to share code, preferences and authentication with commands used from the launcher. Raycast's menu bar commands reference describes the model. Commands are not long-lived processes. Raycast loads them on demand, runs them, and unloads them, then restores the item from its database after a restart.

Refresh works through background refresh, documented on the background refresh page. Two details matter when replacing xbar timers. First, scheduling is not exact: macOS chooses the moment to save energy, and timing can vary on battery. A plugin that must update on the minute is a poor fit. Second, Raycast adds a preference to each scheduled command so the user can turn background refresh on or off and see when it last ran, which is more visibility than xbar ever offered.

Cost is not a barrier here. Raycast's pricing page lists the Free plan at $0, covering built-in extensions and public Store extensions, and Pro at $8 per month billed annually for AI features. Writing personal extensions does not require Pro. One limit to know: the reference states menu bar commands are not available on Windows.

Hammerspoon: when the item is part of an automation

Hammerspoon is a bridge between macOS and a Lua scripting engine. Out of the box it does nothing. Its configuration file connects events to actions: a hotkey to a window arrangement, a Wi-Fi network change to a set of commands, a battery level to an alert.

Menu bar items are one of its modules. The hs.menubar documentation covers creating an item with hs.menubar.new(), setting its title and building its menu. That makes it a good home for an xbar plugin that was really a remote control for something else, such as a toggle that runs a script on click, because the trigger, the action and the menu bar item live in one file.

It is a poor fit for someone who just wants to keep a folder of shell scripts running. Each plugin becomes Lua, and the refresh timer is written by hand. The latest Hammerspoon release on the check date was 1.1.1, from 26 February 2026.

Choosing between the three

	SwiftBar	Raycast menu bar commands	Hammerspoon
Runs xbar plugins unchanged	Yes	No, rewrite in TypeScript	No, rewrite in Lua
Language	Any executable	TypeScript and React	Lua
Refresh	File name interval or cron	Background refresh, not exact	Timers written in code
Price	Free, MIT	Free plan covers it	Free, open source
Best for	Keeping existing plugins	People already in Raycast	Automations with a menu bar face

The deciding question is simple. If the plugin folder is the asset, SwiftBar keeps it. If the plugins are being rewritten anyway, choose the environment the rest of the workflow already lives in.

The question underneath: how many items should be up there

Script output is unusually good at filling a menu bar. Each plugin is cheap to add, so the count grows until something breaks. And what breaks is not the tool. Raycast's developer documentation says plainly that macOS has the final say on whether a menu bar item is displayed, and that with many items present, a new one may not show up. The same passage suggests closing items that are not needed or hiding them with a menu bar manager.

On a MacBook with a notch the limit comes sooner, and it moves: an app with long menus in front shrinks the space available on the right. A plugin that was visible under Finder can vanish under Xcode. Moving from xbar to SwiftBar does not change that, because both draw into the same space.

Two habits help regardless of the tool chosen. First, prefer items that exist only when they matter, such as SwiftBar's ephemeral plugins or a script that prints nothing when there is nothing to report. SwiftBar's README notes that a plugin exiting with code 0 and empty output puts nothing in the menu bar. Second, hide what is consulted rather than watched. A menu bar manager for macOS can hold rarely read items out of sight and, in some tools, bring one back automatically when a condition holds, including a script that exits with 0. The features page shows one tool's take on those conditions, and the comparison page lists several menu bar organizers with prices and the date they were checked.

What to change first

Copy the xbar plugin folder, install SwiftBar, point it at the copy, and quit xbar before testing. Fix interpreter paths in shebangs as each plugin is checked. If the bar is still too crowded once everything runs, try Koffret on the items that are read only now and then.