xbarの代わりを探すとき｜手放してよい機能を先に決める

任意のスクリプトの出力をメニューバーに出す道具として、xbarを使ってきた。ところが、書いたプラグインが増えるほどメニューバーは横に伸び、目的の項目を探す時間のほうが長くなっていく。xbarの代わりを探し始める理由は、たいていここか、更新の頻度への不安のどちらかである。

この記事は、乗り換え先を並べる前に「いま何を任せているのか」を分解し、手放してよい機能から決めていくための材料をまとめたものである。候補の情報は2026年9月10日に各配布元の公開ページで確認した。

いま任せている仕事を3つに分ける

代わりを探すときに失敗しやすいのは、機能の一覧を横に並べて比べてしまうことである。この種の道具が引き受けている仕事は、実際には性質の違う3つに分かれている。

1つ目は、任意の言語で書かれた実行可能なファイルを、決まった間隔で走らせることである。走らせる仕組みそのものは、macOSの標準機能でも代替できる領域である。

2つ目は、標準出力の文字列をメニューに変換することである。区切り線の下はドロップダウンに入り、縦棒より後ろは色や大きさやリンクの指定として解釈される、という約束事がここに当たる。この約束事が同じであれば、書いたプラグインはそのまま動く。

3つ目は、プラグインを探して入れる仕組みと、入力欄の提供である。公開されているカタログから選んで入れられること、プラグインの側で変数を宣言しておくと利用者に入力を求める画面が出ること、この2つが該当する。変数の値は、プラグインの隣に置かれる小さなJSONのファイルに保存される作りである。

代わりを探すというのは、この3つのうちどれを引き継ぎ、どれを手放すかを決める作業である。3つとも同じ形で欲しいのか、2つ目だけ揃っていれば十分なのかで、答えは変わる。

いまの配布の状況を数字で見る

判断の前提として、現状を確かめておきたい。公開されているリポジトリの情報では、最新の公開版はv2.2.1-betaで、公開日は2024年9月10日である。その直前のv2.1.7-betaは2021年10月であり、およそ3年の間隔が空いていた。すべての公開版に beta の表記が付いている点も、そのままの事実として押さえておきたい。

ライセンスはMIT、必要なmacOSは10.15以降と記されている。星の数は18,100を超え、未解決の課題は186件ある。この道具の説明には、成り立ちも書かれている。

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

つまり、先行するBitBarを作り直したものであり、Go言語で書き直された経緯がある。導入の実績も見ておきたい。Homebrewのカタログで公開されている集計では、直近1年の導入数は3,908件で、カタログが配っている版はv2.1.7-betaである。配布元の最新版とカタログの版が食い違っているため、Homebrewで入れた人と、配布元から直接入れた人とで、手元の版が違うという状況が起きている。

乗り換え先を3つの型に分ける

候補は、性質で3つに分けると見通しがよくなる。

1つ目は、同じ約束事を採用している道具である。プラグインの書式が同じなので、書いた資産をそのまま持っていける。移行の手間が最も小さい。

2つ目は、見せる場所を変える道具である。メニューバーではなくデスクトップに置く、あるいはメニューバーの表示そのものを別の実装で置き換える。情報を見たいという目的は同じでも、置き場所が変わることでメニューバーの混雑からは解放される。

3つ目は、決まった役目の専用アプリである。CPUの負荷や電池の状態のように、見たい情報が最初から決まっているなら、自分でプラグインを書くよりも専用アプリのほうが手が空く。

候補の一覧

主な候補を、確認できた事実だけで並べる。数字はいずれも2026年9月10日時点のものである。

名前	情報を置く場所	最新の公開	xbarのプラグインが動くか
xbar	メニューバー	2024年9月	本体
SwiftBar	メニューバー	2026年8月	動く
Übersicht	デスクトップ上のウィジェット	2023年12月	動かない
SketchyBar	メニューバーの表示を置き換える	2026年6月	動かない
Hammerspoon	自分で書いた項目	2026年2月	動かない
Stats	メニューバー（用途が固定）	2026年9月	動かない

この表で見るべきは、右端の列と、最新の公開の列である。プラグインを書き溜めている人にとっては、右端が「動く」かどうかで移行の手間が一桁変わる。更新の頻度は、新しいmacOSが出たときにどうなるかの目安になる。

それぞれの性格も一行で添えておく。Übersichtはシェルコマンドの結果を、JSXで書いたウィジェットとして描く仕組みで、公開されている説明にもウィジェットはJavaScriptのモジュールであると書かれている。SketchyBarは公開ページの説明で、細かく設定できるmacOSのステータスバーの置き換えと位置づけられており、ライセンスはGPL-3.0である。HammerspoonはLuaでmacOSの操作を自動化する道具で、メニューバーの項目も自分で書く。Statsは公開ページの説明でメニューバーに常駐するシステムの監視ツールと書かれており、用途が最初から決まっている。

プラグインをそのまま持っていける場合

同じ書式を採用している道具として、SwiftBarがある。公開されている説明では、プラグインの仕様はBitBarとxbarから引き継いだものであり、既存のプラグインをそのまま動かせると明記されている。ファイル名の付け方も同じで、名前と更新間隔と拡張子を点でつないだ形になる。

違いもいくつかある。更新間隔の単位に、秒や分に加えてミリ秒が用意されている。プラグインを置くフォルダは、初回の起動時に自分で選ぶ方式で、場所が固定されていない。フォルダは入れ子をたどる作りで、除外用の設定ファイルを置けば特定のファイルを読み込ませないこともできる。新しいファイルを見つけたときに、必要であれば実行権限を自分で付ける挙動も持っている。実行権限の付け忘れで動かない、という詰まり方が減る部分である。

必要なmacOSは12以降で、xbarの10.15以降より新しい。古いMacを使い続ける前提なら、ここが判断の分かれ目になる。導入数はHomebrewの集計で直近1年25,678件であり、公開版は2026年8月に更新されている。

移行の実際の手順は、プラグインのファイルを新しいフォルダへ移し、変数を使っているプラグインについては入力し直す、という流れになる。変数の値は隣のJSONファイルに入っているため、中身を見れば何を入れていたかは分かる。

引き継げないものを先に数える

プラグインのファイルは移せる。移せないのは、その周りにある便利な部分である。移った翌日に気づくと面倒なので、先に数えておきたい。

1つ目は、プラグインを探す仕組みである。アプリの中と公開されている一覧の両方から、分野ごとに分けられたプラグインを選んで入れられる。移った先には移った先の一覧があり、中身は同じではない。押すだけで入っていたものを、探し直すか、手元のファイルとして持っていくかの判断が要る。

2つ目は、入力欄である。プラグインの中にタグの形で変数を宣言しておくと、利用者に値を尋ねる画面が出る。宣言できる型は文字列、数値、真偽、選択肢の4種類で、入力された値は実行時の環境変数として渡される。宣言そのものはソースの中のコメントなので一緒に移るが、その宣言から入力欄を作ってくれるかどうかは移った先の実装次第である。値そのものは、プラグインの名前を含むJSONのファイルに入っているので読み出せる。

3つ目は、外から操作するための仕組みである。専用の書式のアドレスを開くことで、特定のプラグインを開いたり、1つだけ更新したり、全部を更新したりできる。この仕組みに何かをつないでいた場合、たとえば値のファイルを書き換えてから更新をかける自作の手順などは、移った先で作り直すことになる。

4つ目は、外観の切り替えを知らせる仕組みである。システムの外観が変わったときに、明るい表示か暗い表示かを示す環境変数が更新される。この値を見て表示を変えているプラグインは、移った先でも動くが、値が渡ってこないため常に片方の表示になる。

5つ目は、本体の設定である。自動更新をするかどうかは設定ファイルで切り替えられ、そのファイルは最初から存在するわけではない。消して起動し直せば初期状態に戻る、という扱いも移らない。

数えてみると、実際に使っていたのは半分程度、というのはよくある結果である。使っていないものを移さずに済ませれば、移行の作業もメニューバーの幅も同時に減る。

見せる場所を変えるという選択

メニューバーが混むという問題に対しては、そもそもメニューバーに出さないという答えもある。

デスクトップに情報を置く方式なら、ウィンドウの後ろに常時表示されることになるので、メニューバーの幅は一切消費しない。ただし、ウィンドウを全画面にして作業する人には見えない時間が長くなる。

メニューバーの見た目そのものを別の実装に置き換える方式もある。表示の自由度は高いが、設定を書いて調整する前提の道具であり、導入の手間は大きい。自動化の言語を持つ道具に寄せる方法もあり、この場合はメニューバーの項目も含めて自分で書くことになる。

見たい情報が決まっているなら、専用アプリが最も静かである。1つのアイコンに情報が集約されるため、プラグインを3つ4つ並べていた状態からは確実に幅が減る。

手放してよい機能を決める順番

ここまでを踏まえて、決める順番を書いておく。

最初に決めるのは、常時見ておきたい情報がいくつあるかである。プラグインの数ではなく、視線を送る回数で数える。1日に何度も見るものだけがメニューバーに残る候補で、それ以外はドロップダウンの中か、別の場所でよい。

次に決めるのは、書いたプラグインを引き継ぐかどうかである。引き継ぐなら候補は同じ書式の道具に絞られる。引き継がないなら、専用アプリのほうが手が空く。

最後に決めるのが、残ったアイコンの扱いである。プラグインを整理しても、クラウド保存や同期や常駐アプリのアイコンは残る。ここは表示するかどうかの二択ではなく、必要なときにだけ出すという第三の道がある。隠したアイコンを、メニューバーを畳んだまま押してその場でメニューを開ける作りであれば、隠したものへ手を伸ばす操作が1手で済む。実装ごとに何ができるかはできることに一覧があり、方式の違いを軸ごとに並べたものはほかの道具との違いにある。判断に金額を含めるなら料金も見ておきたい。

代わりを探すという言い方をすると、同じものを1対1で置き換える作業に見える。実際には、3つの仕事のうち2つを別の場所へ移し、残った1つだけをメニューバーに置く、という形に落ち着くことが多い。手放してよい機能を先に決めれば、候補は自然に2つか3つまで減る。