テキストが必要になるまで、ずっとネイティブ：ネイティブUIの隠れたコスト

Appleエコシステムにおける過去20年間の主流な考え方は、「すべてをネイティブで」というものでした。その約束はシンプルです。SwiftUI、AppKit、TextKitを使用することで、比類のないパフォーマンス、深いOS統合、そして洗練されたユーザー体験が得られるというものです。しかし、多くの開発者にとって、この約束は、モダンでテキスト主体のインターフェース、特にMarkdownサポートを備えたチャットアプリケーションを構築しようとした瞬間に壁にぶつかります。

最近の刺激的な投稿で、ベテランのmacOS/iOS開発者のArtem Loenkoは、シンプルなチャットインターフェースを実装しようとした際に「開発地獄」に陥った過程を説明しています。彼の経験は、現代のソフトウェアエンジニアリングにおける高まる緊張関係を浮き彫りにしています。すなわち、ネイティブフレームワークの認識されている効率性と、複雑なテキストレンダリングを実装する際の実際の生産性のコストとの間のギャップです。

ネイティブの苦闘：SwiftUIからTextKitへ

Loenkoの旅は、現代的な宣言型フレームワークであるSwiftUIから始まりました。単純な画面を扱うことは可能ですが、彼はそれがリッチテキストのインタラクションには根本的に不向きであることを発見しました。主な決裂点は、基本的なユーザーの期待でした。SwiftUIのプリミティブから構築されたMarkdownドキュメント全体を選択できるという能力です。設計上、これはほぼ不可能です。

より堅牢なソリューションを求めて、彼はApple SDKの階層を辿りましたが、各ステップは、生産性の面で後退しているように感じられるトレードオフを伴っていました。

• NSTextView & TextKit 2: より良いテキスト制御を提供しますが、プロジェクトをSwiftUIですでに行われたパフォーマンスやテストの作業から切り離してしまいます。
• AppKit & NSCollectionView: 実証済みの手法ですが、設計上避けられないと思われる「点滅するセル」に悩まされます。
• Pure TextKit 2: 低レベルのプロトタイプであり、許容可能なパフォーマンスを提供しますが、モダンなAI駆動型チャットアプリに不可欠な要件であるテキストのストリーミングには惨めに失敗しました。

Loenkoは、コンテキストメニュー、辞書引き、アクセシビリティといった基本的なmacOSの挙動と機能的な同等性を実現するには、数ヶ月の手作業が必要になると結論付けています。ここで、「ダークサイド」であるElectronが魅力的に見えてきます。

「Electronのパラドックス」

Loenkoが最終的にElectronに転換したとき、彼はテキスト操作、Markdownレンダリング、およびタイポグラフィが、純粋なTextKit 2の実装に匹敵するか、それを上回るパフォーマンスで、そのままの状態で動作することを発見しました。

これはパラドックスを生なります。開発者はしばしばElectronを「肥大化している」または「遅い」として嘲笑しますが、リッチテキストに関しては、ブラウザエンジン（Blink/WebKit）は、そのマシン上で最も最適化されたソフトウェアの一部であることが多いのです。あるコメント主の@pornelは、次のように述べています。

"Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Meanwhile SwiftUI doesn't feel particularly fast."

コミュニティ・ディベート：スキル不足か、システム的な失敗か？

この経験を巡る議論は、鋭く分かれています。

一部の開発者は、これが「スキルの問題」であると主張し、既存のネイティブライブラリやTextKitでの自身の成功例を指摘しています。

• ネイティブ派の支持者: @lenkiteや@msephtonのような一部のユーザーは、SwiftUI用の成熟したMarkdownレンダラーが既に存在するか、あるいはTextKit 2を正しく実装すれば非常に高いパフォーマンスを発揮できると主張しています。@msephtonは、完全な再スタイリングを伴いながら、150msで20回の連続したキーストロークを処理できる自身が構築したテキストエディタを例に挙げました。
• システム的な失敗派: 他の開発者はLoenkoと同意し、ネイティブでテキストを「ただ動かす」ために必要な膨大な努力は、禁止的なほどに高いと示唆しています。@splittydevは、UIKit/SwiftUI用の5つの人気のあるGitHubコンポーネントを試した結果、すべてが「何らかのようには壊れていて、バグがあり、遅い」と述べています。

ハイブリッド・レンダリング：中間的な道

A recurring suggestion in the discourseは、ハイブリッド・アプローチです。アプリケーションのシェル（メニュー、ツールバー、ナビゲーション）にはネイティブフレームワークを使用し、リッチテキストの内容にはWKWebViewを使用するという方法です。

このアプローチは、HTML/CSSがGUIテキストレンダリングにおいて最も強力なシステムであることを認めています。@iamcalledrobが指摘したように、これは新しい発見ではありません。macOSの初期バージョンや初代iPhoneのUITextFieldは、実はWebKitをバックエンドとして使用していました。なぜなら「テキストは難しい」からです。

結論：適切なツールを選択する

議論の焦点は、必ずしもネイティブが「できる」かどうかではなく、テキスト主体のアプリにおいて、ネイティブがデフォルトの選択肢として「適切」であるかどうかです。Digital Audio Workstations (DAWs)や3Dモデリングソフトのような、高性能で専門的なツールには、ネイティブは不可欠です。しかし、現代の「チャット中心」のソフトウェアの時代において、ネイティブフレームワークと戦うコストは、そのメリットを上回る可能性があります。

コミュニティのコンセンサスが示唆するように、ブラウザエンジンは単にウェブサイトを構築するための手段ではありません。それは、現存する最も多額の資金が投入され、最も最適化されたテキストレンダリングエンジンです。柔軟なタイポグラフィとシームレスなMarkdownストリーミングをテキストとして扱うことが目標であるとき、、ときには最も「ネイティブ」な感覚の体験は、ウェブ・スタック上で構築されたものかもしれません。