「Why is Claude an Electron App?」の中で、Drew Breunigはこう問いかけている。

Claudeはエージェントの群れに2万ドルを費やして（いちおう）CコンパイラをRustで実装させたのに、デスクトップ版のClaudeはElectronアプリだ。

もしコードがタダなら、なぜすべてのアプリがネイティブにならないのか？

そして、答えはLLMがまだ十分に優秀ではないからだと論じている。LLMは作業の9割はこなせるが、残りを手作業で磨き上げる必要があり、結局コストがかさむというのだ。

だが僕は、それが本当の理由ではないと思う。本当の理由はこうだ。ネイティブにはもはや何の魅力もないのだ。

APIという点では、ネイティブアプリはとっくの昔にウェブアプリに敗れている。ネイティブAPIは使いにくく、OSベンダーはあらゆる手段を使って、開発者が自社プラットフォーム向けにネイティブアプリを作りたいと思わなくなるようにしてきた。それがLLM時代以前にElectronが台頭した理由だが、これは今やLLMが解決してしまった問題でもある。もしそれがネイティブアプリ開発の本当の障壁だったのだとしたら、もはや障壁は存在しないのだ。

次に、見た目と一貫性の問題がある。かつて――おそらく90年代後半から2000年代にかけて――は、ネイティブに分があった。見た目は良く、一貫性があり、そして実際にちゃんと動いていた。アプリ（当時はプログラムと呼んでいた）がネイティブのルック＆フィールに従えば従うほど、アプリをまたいだユーザー体験は良くなったのだ。

ところが今や、ネイティブはウェブと同程度か、むしろそれ以上にひどい。一貫性はほぼ失われた。何でもありの見た目になり、ボタンには枠線がなく、コントラストは存在せず、慣習もない。例えばAppleは、ウィンドウの信号機ボタンや角丸の半径を、明確なガイドラインというより雰囲気で決めているように見える。

見た目が良いこともあれば、悪いこともある。そして悪い場合、プラットフォームに準拠してはいるものの、総じて出来の悪いUIに縛られることになる（Liquid Glassのことだ、ええ）。しかも変化が激しすぎる。今日作ったアプリは、来年Appleがまたルック＆フィールを変えると決めた途端、場違いな見た目になってしまう。もはや「ネイティブらしい見た目」など存在しないのだ。

理論上、ネイティブアプリはOSとより深いレベルで統合できる。聞こえはいいが、実際にはそれが何を意味するだろうか。まともに相互運用できるファイル形式はほとんどなく、すべては個別のアプリの中に閉じ込められ、ほとんどのサービスはウェブに移行し、OSは共通基盤をきちんと作ることに失敗した。OS標準のカレンダーとなら連携できるが、ウェブのカレンダーとはそうはいかない。もちろん、できないわけではないが、ウェブの方が簡単だ。そこではネイティブは何の役にも立たない。

最後に、ネイティブに憧れる人々の最後の希望はパフォーマンスだ。ネイティブアプリなら速くなるはずだと彼らは考えている。確かに、速く「なり得る」。だが、そうなるとは限らない。ウェブアプリだって速くなり得るが、実際には誰も気にしていない。画面にチャンネル名10件とメッセージ3件を表示するだけなのにSlackが80MiBも読み込む必要がある技術的な理由などない。問題はウェブではないのだ！わざわざ悪くしているだけだ。会社がネイティブに移行したところで、何かが変わると思えるだろうか？

誤解しないでほしい。こんなことを書いても全然楽しくない。ウェブが解決策だとも思っていない。ただ、ネイティブが平均以上の仕事をしていて、皆がそれを使うことで恩恵を受けていた良き時代を覚えているだけで、その時代が過ぎ去ってしまったことが悲しいのだ。

ソフトウェアの唯一の問題はElectronであり、SlackをSwiftUIで書き直せばすべてがバラ色になる、などと自分をごまかしても何の生産性もないと思う。本当の問題は、作り手のこだわりのなさだ。そして手抜きの粗製濫造――それはどんな技術スタックでも作れてしまう。