小さくて単一目的の Mac アプリを擁護する

長年の Mac ユーザーのアプリケーションフォルダを開けば、奇妙なパターンが見つかります。実際に毎日開く大手の有名アプリが5つか6つあり、そのほかにメニューバーやホットキー、クイックアクションとして静かに動く小さなユーティリティが40個ほどあります。大きなアプリは2年ごとに、ときには痛みを伴って再設計されます。小さなユーティリティはただ動き続けます。

この記事は、なぜ小さなユーティリティが勝つのか、そしてそのパターンを意図的に念頭に置いてソフトウェアを作るとどうなるのか、についてです。

そのパターン

ここでいう「小さなアプリ」とは、1つの仕事を持ち、シンプルな UI 面（多くはメニューバー、ときにウィンドウ）を持ち、機能リストが1画面に収まるものです。Mac のパワーユーザーならほぼ誰でも見覚えのある例を挙げます。

Itsycal、メニューバーに常駐する小さなカレンダー。
Hand Mirror、カメラをワンクリックの鏡に変えるもの。
Maccy、クリップボード履歴。
Rectangle、ウィンドウマネージャー。
Pure Paste、コピーしたものから書式を取り除くもの。
Lungo、必要に応じて Mac をスリープさせないでおくもの。

これらのどれもプラットフォームになろうとはしていません。機能ゲート付きの「Pro 枠」もありません。アカウント作成を求めるものもありません。ほとんどが無料か一度きりの購入です。オープンソースのものもあります。どれもちょうど1つのことをし、開発者が一度もカンバンボードを追加したいと思わずに、その1つのことを何年もやってきました。

なぜ小さい側で機能し、大きい側で崩れるのか

小さなアプリが生き延びる理由は、機能ごとの複雑さの税が決して積み上がらないことです。クリップボードだけを管理するクリップボードマネージャーは、表面積が小さいです。バグの表面も小さいです。設定ページも小さいです。リリースノートも小さいです。開発者はアプリ全体を頭に入れておけるので、問題をすばやく直し、ほかの機能を壊さずにアップデートを出せます。

小さなアプリが「プラットフォーム」に成長しようとした瞬間、計算が変わります。新しい機能はテストの組み合わせを倍々にします。新しい設定はエッジケースを増やします。新しい統合は、他人のバグをあなたのコードベースに持ち込みます。複雑さの税は、おおよそ二次関数的に増えます。

大きなアプリがこれを生き延びるのは、チームを雇うことによってだけです。小さなアプリは、成長を拒むことによって生き延びます。

経済性

一度きり5〜15ドルの小さなアプリは、月に千ダウンロードあれば一人で作り、サポートできます。計算が成り立つのは、ユーザーが1人増えるごとの限界費用が本質的にゼロだからです。サーバーはありません。開発者を超えるサポートチームもありません。月額請求の来るアナリティクスダッシュボードもありません。

同じ開発者が同じ価格帯で「プラットフォーム」をサポートしようとすれば、破産します。プラットフォームにはチームが必要です。チームには給料が必要です。給料には継続収入が必要です。だからこそ、あらゆる「プラットフォームになった小さなアプリ」は最終的にサブスクリプションに移行します。経済性がそれを強いるのです。

興味深い結果は、小さなアプリの開発者のほうが、プラットフォームの開発者よりも、アプリを絞り込み続ける強い動機を持つということです。機能を追加することは、小さなアプリの開発者にとって実際のコストです。彼らはそれに抵抗します。プラットフォームの開発者には、新機能の出荷を要求する四半期の OKR があるので、必要かどうかにかかわらず追加します。

デザインの規律

小さなアプリを作るうえで最も難しいのは、機能にノーと言うことです。これは、あらゆる機能リクエストを解く価値のある小さく興味深い問題と見なしがちなエンジニアに自然に湧くノーではありません。アプリが何であるかについての強い意見から生まれるノーです。

正しいテストは「これは一部のユーザーに役立つか」ではありません。どんな機能でも、その答えは常にイエスです。正しいテストは「これは、すでにこのアプリを愛しているユーザーにとって、アプリを悪くするか」です。メモを追加したクリップボードマネージャーは、もはやクリップボードマネージャーではありません。プロジェクトやエリアやタグを追加した ToDo アプリは、もはや小さな ToDo アプリではありません。絞り込まれたバージョンを愛していたユーザーは、重さに気づき始めます。

成功した小さなアプリのほとんどは、決して追加しない機能の公開された「アンチロードマップ」を持っています。ときにはウェブサイトに明示されています。多くの場合は、変わらないリリースノートに暗黙のうちに表れています。5年経ってもアプリはその1つのことをしている。それが機能なのです。

なぜメニューバーがそれらの多くにとって正しい居場所なのか

メニューバーは、1つのことをするアプリにとって完璧な面です。常に利用でき、視覚的な場所をほとんど取らず、ポップオーバーを開くワンクリックのアフォーダンスを1つ持つからです。注意を奪い合う Dock アイコンはありません。開け閉めを要求するメインウィンドウもありません。アプリは必要なときにそこにあり、必要ないときには見えません。

これが、ここ10年で最も愛された小さな Mac アプリのいくつかがメニューバーアプリだった理由でもあります。形態が使命に合っているのです。これがなぜ機能するのかをもっと詳しく扱ったメニューバー ToDo アプリの選び方についても書きました。

なぜこの流れが戻ってきているのか

数年間は、小さなアプリのモデルは死につつあるように見えました。サブスクリプションの圧力がインディー市場を食い荒らしていました。App Store の変更が経済性を厳しくしました。Apple は WWDC の基調講演のたびに有名ブランドの大きな生産性アプリをデモし続けました。

しかし、ここ2年でこの流れは静かに逆転しました。いくつかのことが変わりました。

サブスクリプション疲れが現実のものとなり、測定できるようになった。 顧客が目に見える規模でサブスクリプションをキャンセルし始めました。
オンデバイス AI が安くなった。 以前はクラウド LLM の請求が必要だったアプリが、Apple の Foundation Models フレームワークで同じ作業をローカルで行えるようになり、「推論コストを賄うために月額課金しなければならない」という最も一般的な言い訳がなくなりました。
新しい波のインディー開発者は、前の波がプラットフォームになろうとして燃え尽きるのを見て育った。 彼らはあえて小さな範囲を選びました。

その結果、2025年と2026年は、小さな Mac アプリにとって静かに良い年になりました。新しいものが毎月ローンチします。古いものは小さく思慮深いアップデートを受けます。このモデルが機能し続けるのは、これらのアプリを買う人たちが、積極的にそうあってほしいと願っているからです。

買い物をする人にとってこれはどう見えるか

おおよそ同じことをする2つのアプリを見ていて、一方が5つのタブとペイウォールを持つ「プラットフォーム」で、もう一方が同じ仕事をする単一のポップオーバーなら、3年後にあなたのメニューバーに残っているのはプラットフォームのほうではありません。プラットフォームは B2B 顧客が望むもののほうへ舵を切ります。ポップオーバーは静かに絞り込まれたままでいます。

これは普遍の法則ではありません。これまで作られた最良の Mac アプリのいくつかは、大きく、野心的で、一ドルの価値もあるものでした。Logic Pro は小さなアプリではありません。Final Cut Pro も小さなアプリではありません。Things 3 はその中間あたりで、優れています。要点は、大きいことが悪いということではありません。要点は、「小さくて変わらない」こと自体が1つの機能カテゴリーであって、まだ成長していないアプリのしるしではない、ということです。

ソフトウェアを作る人にとって、教訓はもっとシンプルです。範囲は小さく、テールは長く。1つのことを10年間うまくやるアプリは、6つのことを2年間そこそこにやった5つのアプリより価値があります。小さなユーティリティは Mac で30年間、再設計されたプラットフォームを生き延びてきました。それが変わる明白な理由はありません。

ソフトウェアを使う人にとって、教訓は、アプリがしっくりくると感じたら自分の直感を信じることです。ただそこにあって動く小さなものは、たいていそれを続けてくれるものです。17個のタブと「Pro 枠」を持つものは、おそらくそうはなりません。

TodoBar はこの系譜の中で作られています。1つのメニューバーアプリ。1つのポップオーバー。プロジェクトもタグもカンバンボードもありません。プラットフォームにはなりません。別のペイウォール付きの「Pro 枠」もできません。無料枠がほとんどのユーザーをカバーします。1つの一度きりのアンロックがパワーユーザーをカバーします。絞り込まれたバージョンを大きくではなく良くするものでない限り、ほかには何も追加されません。