■ 1. 生成したネイティブアプリ群
- MDV.app:
- 他に本気のMarkdownビューアが現れるまで世界最高のMarkdownビューア
- UIコードにはほとんど手を加えず、召喚した
- 良いUIを作る困難:
- 大半のUIと同様に新規性はなく、難問でもない
- 一方でコードは退屈で反復的かつ厳密さを要求され、プラットフォームの概念知識に依存する
- 習熟には何年もかかるため、この種のプログラムを手書きすることはない
- SageMathフロントエンド:
- Math AcademyでFoundations Iから機械学習まで進め、独学で微積分を修めた延長で作った電卓型SwiftUIアプリ
- Sageの出力をLaTeXで自動描画し、多変数微積分が深まるほど有用になる
- ベクトル、行列、式などのオブジェクトのメソッドをポイント&クリックで露出する
- 勾配を取るといった頻出操作を短く打てる「little language」を備え、[1,2;3,4] が行列になる
- 配布しない方針:
- このアプリはパッケージ化しない
- 欲しければ該当箇所のスクリーンショットをClaudeに渡せば有用なものが出来上がる
- DJ Roomba:
- Apple Music用の自作プレーヤーで、ジャンルマップは怪しい機能
- ライブラリ、最終再生リスト、次の曲を読むツールコールを持つLLMエージェントを組み込んだ
- 地下の工作場で額縁を作る気分に合うノースキップのプレイリストを頼むと、Kurt VileとTom Pettyが大量に並び文句なしだった
- まともなスキーマのSQLiteをバックエンドに据えたことも驚くほど有用な特徴だった
- 開発か設定かという疑問:
- Music.appの90%のインターフェースを備えたAI支援音楽プレーヤーであり、宿敵に対する龍退治に等しい
- それでいて一行もコードを書いていないため、ソフトウェアを開発しているのか、単に自分のコンピュータを設定しているだけなのか判然としない
- Self Driving Wiki.app:
- 素材を与えて質問すると自らwikiを書く自走式wikiは非常に有用な発想
- Responses APIクライアントを直接埋め込むDJ Roombaと違い、内部で claude -p を駆動する
- エージェントは漁れるファイルシステムがあるほうが働くと考え、macOSの仮想ファイルシステム拡張を召喚した
- 拡張はSQLiteの読み取り専用ビューをサンドボックス内のマウント済みファイルシステムとして反映する
- 不要でインストールを面倒にした可能性はあるが、この種のヤクシェービングはLLM以前の開発の喜びであり、今も味わえるのは嬉しい
- 食事マクロトラッカー:
- GPT5を前面に置いた単純なエージェントで、半自動的に栄養を記録する
- ケーキの生地とクリームチーズのフロスティングを味見したといった短い記述を摂取量の推定に翻訳する
- 温度監視メニューバーアプリ:
- 安価なTP-Linkの温度センサーで家中の温度を追う
- 通常なら通信プロトコルやHTTP APIを語れるところだが、その調査を一切していないため、クラウド経由と各センサー直結の二つのサインイン経路がある程度しか言えない
- Apple TVリモート:
- メニューバーで動く汎用リモコンで、macOSネイティブ開発の聖杯にあたる
- Apple TVとの直接通信は厄介だが、既に解決してPythonライブラリを書いた人々がいる
- ネイティブSwiftアプリなのでそのライブラリを使いはしないが、Pythonで書かれた実装はSwiftでもC#でもBrainfuckでも同じことであり、フロンティアモデルには区別がない
- 生成UIの品質:
- 生成したSwiftUIの見た目に対する容赦ない批評は歓迎する
- App Storeの長年の利用者として、これらのデザインはいずれも代替水準より一歩先だと主張する
- 5年前にmacOSのUI担当者がこの品質を出してくれたなら大喜びしていた
- アプリではなく成果物:
- 配布する意図がないため、これらを「アプリ」とはほとんど考えていない
- コンピュータに自分のやり方で仕事をさせるための成果物にすぎない
- Unixナードとしてコマンドラインの言語で常にできていたことが、今やグラフィカルインターフェースでも同じ手軽さでできる
■ 2. CLIとTUIの区別
- TUIを作る理由:
- 我々がターミナルインターフェースを作るのは、そうすべきだからではなく、そうせざるを得ないから
- 両者の出自:
- CLIもTUIも1970年代の産物で、テレタイプとダム端末の制約に合わせて成形された
- どちらもGUIに比べて時代遅れかつ敵対的で制約が多い傾向を持つ
- 傾向の帰属先:
- これらの傾向はTUIに内在するものであり、CLIに内在するものではない
- CLIには代替不能な用途があり、CLIを作るのはほぼ常に良い判断
- TUIを作るのはほぼ常に良くない判断
- Stephensonの神話:
- 1999年の「In The Beginning Was The Command Line」はHCIの分野を20年後退させた
- CLIを操るUnixナードの聖職者集団を、産業全体を背負う強力なモーロックとして描き、EloiはWordのようなGUIを使うとした
- 極上のファンサービスゆえに分野の聖典となったが、25年後に成立している部分はごくわずか
- TUI存在の実際の理由:
- 機械と操作者の間に特別な機械共感が生まれるからではない
- 存在理由はモデムと、UnixナードがMotifを学びたがらなかったことの二つだけ
- Motifとcurses:
- 1990年代半ばのわずかなMotif作業のせいでその後29年UI開発から遠ざかったので、彼らを責められない
- cursesも大したものではないが5分で習得できる
- 今どき生のcursesを選びはしないが、概念説明を省いてpicoを書く最低限を尋ねれば、返ってきたコードはそのままコンパイルでき、次の一手も明確
■ 3. TUIの技術的劣位
- ネイティブの安定性:
- エージェントはAppleの指示どおりにSwiftUIを使うことで、妥当なネイティブmacOS UIを確実に構築できる
- ネイティブアプリは他のネイティブアプリに似ているべきであり、web UIと違って同一性は美点
- ターミナルとの戦い:
- Ratatui、Textual、Bubbleteaのような良いフレームワークを使っても、ネイティブが標準で備える水準に漸近的に近づくためターミナルと戦う羽目になる
- スクロールとスクロールターゲット、ドラッグ&ドロップが典型例
- ウィンドウ枠をインバンド信号で描くためテキスト選択が厄介になる
- 複数のフローティングウィンドウも難しく、画像処理はそれ以前の話
- ウィジェットの限界:
- 日付ピッカー、秘匿テキストフィールド、プログレスバー、テキストエディタは1時間でそこそこ作れる
- しかし多くはシステム版に劣り、さらに手を掛けなければ組み合わせも効かない
- これらはすべてネイティブUIでは箱を開けた時点で動く
■ 4. TUI擁護論への反駁
- 情報密度と速度:
- TUIが経済的で高速、高情報密度なのは事実で、ナードはレトロな美学だけを愛しているのではない
- ただし説得力を持たせるには「TUIだけが」と書く必要があり、そう書けば嘘になる
- GUIが密でない理由:
- GUIが経済的でも高密度でもキーボード中心でもない傾向は、ナード向けに設計されていないことに由来する
- Linuxですら神話的な一般デスクトップ利用者を目標に設計されがち
- 密で経済的なGUIの設計を妨げるものは何もなく、実例も存在する
- グラフィカル側への含意:
- TUIの美点はむしろグラフィカルな仕事を増やす強い論拠になる
- 実験が容易で安価になった今、MagitやLazygitの良さをすべて捉えたネイティブUIを、自分で作らずに見たい
- SSH越しの利用:
- 本番にユーザーインターフェースは恐らく必要なく、必要なのは手元のMacBookのUIから駆動できるCLI
- bpftraceでハッシュマークの棒グラフを3度も作れば骨身にしみるはず
- 先例としてEmacs TRAMPがあり、SSH接続を隠してリモートファイルにネイティブな編集体験を与え、LSPやMagitとも動く
- アクセシビリティ:
- TUIがアクセシブルという主張は恐らく偽
- 自分はアクセシビリティ機能の利用者ではないため、a11yに携わる人々の経験に依拠するほかない
- スクリーンリーダーがTUIのクロームの行単位更新を、ハッシュマークやダッシュとして読み上げる様子は明らかに良くない
- ネイティブ側の設計:
- 現代のネイティブUIフレームワークは当初からアクセシビリティを適切に扱うよう設計されている
- SwiftUIは視覚的なツリーと意味的なアクセシビリティツリーの二本を保持する
- 正しく実装しようと努めるTUIフレームワークもあり立派だが、アクセシビリティはTUIをGUIより選ぶ理由にはならない
- クロスプラットフォーム性:
- TUIに対する唯一の強い論拠はクロスプラットフォーム性
- エージェントにWindowsやLinux向けのネイティブUIを作らせても妥当なものになる確信はある
- しかしそれらを試すデスクトップを持たず、vibe-codingとvibe-shippingの間には重要な区別が残る
- 自分が見も使いもしないアプリを出荷する者は間もなく現れるが、それは自分ではない
- 自分向けという前提:
- TUIを作ればLinux利用者に同じ体験を届けられる確信は得られ、それは無価値ではない
- ただし自分は他人のためではなく自分のために作っており、公開する気もないプログラムのためにTUIの制約を飲むのは代償が大きすぎる
- 時期の問題:
- 数年前ならこの議論は馬鹿げていた
- TUIが良かったからではなく、ネイティブUIが現実的な要求ではなかったから
- その証拠に我々は10年近くElectronアプリと暮らしてきた
- ネイティブUIが難しかった時代は終わったので、もっとネイティブを作るべき
■ 5. 制作プロセス
- 前提:
- 語れるのはmacOS開発だけで、LinuxのGTK 4とWindowsのWinUI 3も同程度に容易だと仮定する
- まともなネイティブmacOSアプリを作るのに大したものは要らない
- 採用したスキル:
- macOSデザインのスキル、基本的なタイポグラフィのスキル、Paul HudsonのSwiftUIスキルを集めた
- 生成コードが慣用的かどうかを気にする性分が抜けないため、AirbnbのSwift言語スキルも加えた
- computer-use:
- computer-use、あるいはCodexでの相当機能を有効にしておくべき
- 指示を投げて昼食を作りに行き、戻れば快適にデバッグできる程度に動くアプリがある状態が望ましい
- それはエージェントがアプリを見て操作できるときにこそうまく働く
- Xcode回避:
- 最大の生活改善はXcodeを一度も開かずに済むこと
- 友人のJoshがMDVを自分でコンパイルしようとして作った純粋なMakefile駆動のビルド手順を、新規プロジェクトごとにClaudeで複製している
- テンプレート方式:
- テンプレートのアプリディレクトリを複製し、ClaudeかCodexを開いて作りたいものを伝える、それが全工程
- 自分のテンプレートが優れているとは思わず、より有能な誰かが真に良いSwiftUIの原型アプリを作るべき
- TUIの場合:
- 同様の手順でTUIも作れ、エージェントにtmuxでTUIを検証させるとうまくいく
- それでも自分が再びTUIを作りたくなるとは思えない
■ 6. 結論
- 呼びかけ:
- TUIを葬りに来たのではなく、新しく作るのをやめてほしいと願っている
- 個人的な来歴:
- もともとTUIが好きではなかった
- 1990年代はPineからElm、Muttと使ったが、やめてグラフィカルなメールリーダーに移れる瞬間に移った
- この文章全体を個人的な好みの皮肉な表明として読むこともでき、それは自分の柄に合っている
- 境界の消失:
- 重要なのはターミナルインターフェースの好き嫌いではない
- 数十年にわたるフロントエンドとバックエンド、さらにwebとネイティブという区分を、エージェントがほぼ溶かした
- 何を作るにもネイティブUIを既定にでき、その出来もそれなりに良い
- 再調整の勧め:
- ユーザーインターフェースコードを書かないシステムプログラマだと数十年思ってきた人、あるいはASCII文字でウィンドウを描くのが自分の持ち場だと考えてきた人は、認識を改める時期
- UIに関心がない、あるいは1970年代的な美学を好んで良いUIを厭うのは別の話であり、Enlightenmentを走らせていた身としてそれを咎めはしない
- NetNewsWire、Transmit、Little Snitch、Audio Hijackのようなインターフェースを愛でる隠れEloi気質のUnixモーロックなら耳を貸すべき
- 500個ある使い捨てCLIの一つをネイティブアプリに仕立てたことがないなら、自分を損なっている
- ネイティブUIを作れば、恐らく物の考え方が変わる