プラットフォームネイティブUI
各OSのUIフレームワーク・APIを直接使用して構築されたUI。Electron・Flutterなどのクロスプラットフォームフレームワークとはトレードオフの関係にある。
クロスプラットフォームUIとの対比
クロスプラットフォームアプローチ
全プラットフォームで統一されたUIを一つのコードベースで実現する。
- 例：Electron、Flutter、Qt、Tauri
- メリット：開発コスト削減、一貫したUI
- デメリット：各OSの慣例に従えない、OS固有機能の活用が困難
プラットフォームネイティブアプローチ
各プラットフォーム向けにUIレイヤーを別々に実装する。
- 例：macOS（Swift/AppKit/SwiftUI）+ Linux（GTK4）+ Windows（Win32/WinUI）
- メリット：OS統合の恩恵を最大限に受けられる
- デメリット：開発コスト増、プラットフォームごとの実装が必要
ネイティブUIが提供するもの
macOSを例にすると：
- Proxy Icon（タイトルバーのアイコンをドラッグしてファイル移動）
- Secure Keyboard Entry（パスワード入力の自動検出）
- システムのタブ・ウィンドウ管理との統合
- アクセシビリティ（VoiceOverなどOS標準ツールとの連携）
- システムフォントレンダリングの正確な再現
ゼロコンフィグ性との関係
プラットフォームネイティブUIは、ゼロコンフィグ設計と親和性が高い。OSの慣例に従うことで、ユーザーが「学習コストなしに使える」状態を作りやすい。クロスプラットフォームUIでは、OSの慣例から外れた独自の操作体系を学ぶコストが生まれる。
共通コアとの分離
Ghosttyのアーキテクチャのように、ターミナルエミュレーションロジック（共通コア）とUIレイヤーを分離することで、プラットフォームネイティブUIの恩恵を受けながら、コアロジックの重複を避けられる。