1つのグラフ、複数のネイティブサーフェス：AIとクロスプラットフォームアプリの推測

クロスプラットフォームフレームワークは常に難しい約束を追いかけてきた。一度構築すれば、多くのプラットフォームにリーチできるというものだ。.NET MAUI、Flutter、React Native、およびそれ以前のハイブリッドスタックは、Web、iOS、Android、デスクトップアプリをリリースするコストを削減しようとしている。それらはプラットフォームの違いを共有コード、共有コンポーネント、または共有ランタイムレイヤーの背後にパッケージ化する。これには確かに価値がある。

しかし、AIは何を共有すべきかを変えるかもしれない。エージェントがより多くの実装を生成できるようになれば、最も価値のある共有アセットは1つのUIフレームワークではなく、1つの製品グラフになる可能性がある。

共有コードは実際の問題を解決する。重複を減らし、ビジネスロジックを4回書き直す必要をなくす。しかし、共有コードはプレッシャーも生み出す。アプリはネイティブに感じられなくなり、プラットフォームの動作がぎこちなくなることがある。チームは抽象化を回避することに、それを使用することと同じくらいの時間を費やす可能性がある。これはクロスプラットフォームフレームワークが間違っているという意味ではない。共有コードは共有製品意図ではないということだ。

より深い問いは、実際に何を共有すべきかということになるかもしれない。有用な共有レイヤーはUIフレームワークの上に移動するかもしれない。チームは1つのフレームワークにすべてのプラットフォームを適切に感じさせるよう求める代わりに、1つのグラフに製品の意味を記述させるかもしれない。どの機能が存在するか、どのエンティティとワークフローが重要か、どのサーフェスをユーザーが必要とするか、各サーフェスにどのウィジェットと状態が属するか、どのルールが動作を制約するか、どのアクセシビリティとローカライゼーションの約束が適用されるか、どの証拠がエクスペリエンスの動作を証明するか。

そこから、エージェントまたはジェネレーターは異なるネイティブ出力を生成できる。WebアプリはWebネイティブパターンを使用し、iOSアプリはiOSネイティブのナビゲーションとコントロールを使用し、AndroidアプリはAndroidネイティブの慣習を使用し、デスクトップアプリはデスクトップのアフォーダンスを使用する。共有レイヤーは最低共通分母のUIではなく、アプリマップになる。

iOSアプリで作業するエージェントは、汎用的なクロスプラットフォームの抽象化の中よりも、ネイティブiOS環境の方が効果的かもしれない。コンパイラ、シミュレータ、プラットフォームAPI、アクセシビリティツール、デザインの慣習はすべて、エージェントにより強力なフィードバックを与える。Android、デスクトップ、Webでも同じことが言える。エージェントはカスタム抽象化がプラットフォームにきれいにマッピングされるかどうかを推測する必要はなく、プラットフォームと直接作業できる。

しかし、それはエージェントが共有された意図の源泉を持っている場合にのみ機能する。それがないと、すべてのネイティブサーフェスは製品の独自の解釈になってしまう。iOSアプリが漂流し、Webアプリが漂流し、Androidアプリが漂流する。デスクトップは誰も完全には信頼しない奇妙なサーフェスになる。チームが製品の一貫性を保てる場合にのみ、ネイティブ出力は強力である。

可能な形状は「1つのグラフ、複数のネイティブサーフェス」である。グラフは製品を記述する。各サーフェスはその製品を正しいプラットフォーム言語で実装する。これは次のことを意味する：1つの機能がWeb、iOS、Android、デスクトップに現れる。各プラットフォームはネイティブのレイアウト、ナビゲーション、インタラクションパターンを得る。共有ルールはピクセルではなく動作を定義する。サーフェスレコードは各プラットフォームがユーザーに何を提供すべきかを記述する。エージェントは同じ意図からプラットフォーム固有のコードを生成または保守する。レビュー担当者は各出力をグラフと証拠と比較する。

これは「一度書けばどこでも動く」ではない。むしろ「一度仕様化すればどこでも実現する」に近い。実装は異なってもよいが、製品契約は異なるべきではない。

.NET MAUIのようなフレームワークは依然として重要かもしれない。それらは実際の問題を解決する。単一のコードベースを望むチームもいる。一部のアプリはプラットフォーム間で十分に類似しており、1つのフレームワークが適切なトレードオフである。一部の組織は複数のネイティブサーフェスをスタッフするよりもプラットフォームの妥協を受け入れるだろう。AIはそれを消し去らない。

しかし、別の道を開くかもしれない。エージェントが同じアプリマップから複数のネイティブターゲットを維持するのを助けることができるなら、チームはすべてのターゲットに対して1つのクロスプラットフォームUIレイヤーを必要としないかもしれない。これによりトレードオフが変わる。

質問は「どのフレームワークが最もコードを共有できるか」ではなく、「どの共有グラフが各プラットフォームをネイティブに保ちながら最も製品の一貫性を維持できるか」になるかもしれない。

Topogramは、チームがすべてのサーフェスを同じUI抽象化に通すことなく共有意図を望む場合に有用である。アプリマップは機能、エンティティ、サーフェス、ウィジェット、ワークフロー、ルール、決定、要件、タスク、検証を記述できる。Webサーフェスとモバイルサーフェスは同じ製品機能を指し示しながら、異なるレイアウト、インタラクション、証拠を指定できる。

これによりエージェントはより良い出発点を得る：このプラットフォームはどの機能を実装しているか？どの機能がそれを所有しているか？どの状態とルールが一貫している必要があるか？どの部分がプラットフォーム固有か？このサーフェスでどの証拠を通過すべきか？

そしてエージェントは共有製品マップを失うことなくネイティブ環境で作業できる。これが利点である：共有意図を持つネイティブ作業。

AIが実装コストを下げ続ければ、クロスプラットフォーム開発は1つのランタイムに依存することよりも、1つの調整された真実の源に依存するようになるかもしれない。一部のチームは共有コードが適切な制約であるため、依然として.NET MAUIのようなフレームワークを使用する。他のチームはエージェントが実装負荷の多くを担えるため、ネイティブサーフェスを選ぶかもしれない。その世界では、価値あるアセットはアプリコードだけではない。すべてのサーフェスに何が真実であるべきかを伝えるグラフである。

未来は1つのアプリがあらゆる場所で動作することではないかもしれない。それはすべてのサーフェスが自分が属しているように感じさせる1つのアプリマップかもしれない。