Shopify Native Mobileが復活、AIがトレードオフを変えた
Shopifyのネイティブモバイル開発がReact Nativeに取って代わろうとしている。コーディングエージェントが2つのアプリケーションを維持するコストを変えたことで、同社は6年間の戦略を転換した。ShopifyはiOSソフトウェアをSwiftで、AndroidソフトウェアをKotlinで構築する。エージェントが翻訳、テスト、レビューを十分に担えるようになり、別々のコードベースを実用的に維持できるようになったと同社は述べている。
この決定は、クロスプラットフォーム開発における最も強力な約束の一つに異議を唱えるものだ。React Nativeでは、iOSとAndroidでアプリケーション実装の多くを共有できる。Shopifyは、機能を二重に構築することを避け、Web開発者の参加を促し、両プラットフォームの足並みをそろえるためにこのモデルを採用した。
Shopifyは、React Nativeが遅い、あるいは失敗だったとは言っていない。同社によれば、このフレームワークは2020年のモバイルに関する決定で約束した利点を実現した。今回の転換は別の主張に基づく。AIが実装共有によって削減される労力を小さくした一方、ネイティブソフトウェアは各プラットフォームにより近いアクセスを引き続き提供するというものだ。
この違いはShopifyにとどまらず重要である。コーディングエージェントによって並行実装が手頃なものになるなら、エンジニアリングチームはコード再利用の測定方法を見直さなければならない。価値ある共有レイヤーは、ソースコードから仕様、テスト、デザインシステム、レビュー手順へと移る可能性がある。
Shopify Native Mobile、成功したReact Native戦略に代わる
Shopifyは、基盤となる経済的前提が変わったため、成功していたアーキテクチャを廃止する。
同社は2026年9月10日、ネイティブ開発への回帰を発表した。主なモバイル製品には、Shop、Shopify、Point of Sale、Inboxがある。Shopifyによれば、数百万人のマーチャントと購入者がこれらのアプリケーションを利用している。
同社は2020年にReact Nativeへ全面的に移行した。React Nativeは、JavaScriptとネイティブプラットフォームコンポーネントを使ってiOS・Androidのインターフェースを構築するMetaのフレームワークだ。Shopifyは、両OSにまたがる重複開発を減らす共通スタックを求めていた。
初期の成果はこの判断を裏付けた。同社は、後にShopとなるArriveで95パーセント、Compassで99パーセントのコード共有を達成したと報告している。また、ArriveをReact Nativeで書き直した後、あるチームは生産性が2倍になったと感じた。
その後、Shopifyは最大のマーチャント向けアプリケーションをこのフレームワークへ移行した。この製品には各プラットフォームで300以上の画面が含まれていた。段階的な移行は、完全な書き換えのために機能開発を止めるよりも、当初は安全に見えた。
この戦略には相当な組織的投資が必要だった。Shopifyは社内のReact Nativeプログラムを通じてネイティブ開発者を育成し、共有基盤を整備し、より広いエコシステムへライブラリを提供した。また、プラットフォーム固有の作業が必要な場合に、ネイティブコードとReact Nativeを混在させるプロセスも開発した。
2025年1月の時点でも、ShopifyはReact Nativeの将来を明るいものとしていた。5年間の振り返りではMetaの運営を評価し、共有基盤への継続投資を約束した。さらに、このフレームワークを利用する企業向けに再始動したワーキンググループも紹介している。
したがって今回の発表は、失敗した実験を遅れて否定したものではなく、真の方針転換を示すものだ。Shopifyによれば、React Nativeは時間を節約し、貢献できる人を増やし、機能の同等性を追求する労力を減らした。
しかし、これらの利点には継続的なコストも伴った。チームはパフォーマンスを最適化し、基盤コンポーネントを維持し、フレームワークの変更に追随し、外部依存関係を管理した。共有実装が大幅な重複作業をなくしている間は、Shopifyにとってそのコストは許容範囲だった。
コーディングエージェントがこの計算を変えた。Shopifyによれば、同社は2021年からソフトウェア開発に大規模言語モデルを利用してきた。初期の用途には、機能実装、バグ調査、問題修正、コードレビューが含まれていた。
2025年後半までに、同社はより複雑な作業をエージェントに任せるようになった。チームは、iOS実装がAndroid実装を導けるか、また逆のプロセスも同じように機能するかを検証し始めた。こうしたプロトタイプが、Shopifyを別個のSwift・Kotlinアプリケーションへと向かわせた。
同社の新しいネイティブ戦略も、中心的な欠点を認めている。ネイティブ開発では、チームがソフトウェアを二度構築し、維持する必要がある。Shopifyによれば、AIはこの負担を軽減したが、なくしたわけではない。
この動きが重要なのは、Shopifyがかつて大規模なReact Native導入について特に強力な証拠を示していたからだ。同社は小さな機能の周辺でフレームワークを使っただけではない。大規模アプリケーションを移行し、チームを育成し、インフラを構築し、メンテナーを支援し、再利用可能なライブラリを公開した。
現在、同じ企業が実装再利用はもはや同じ重みを持つべきではないと主張している。ここに本稿の中心的な緊張関係がある。ShopifyのReact Native移行の歴史はフレームワークが機能したことを示す一方、Shopifyのエージェントはそれを維持する事業上の根拠を弱めた。
コーディングエージェントがクロスプラットフォームチームに圧力をかける
直接的な圧力は、共有コードをモバイル効率の主要な尺度として扱う組織に及ぶ。
クロスプラットフォームフレームワークは、2種類のレバレッジを組み合わせる。開発者は振る舞いを一度だけ記述でき、企業はより少ない言語とツールを中心にモバイル開発を組織化できる。どちらの利点も、コーディング時間だけでなく調整コストを削減する。
Shopifyの主張は、最初の利点を直接的に弱める。エージェントは既存のiOS機能を調べ、対応するAndroid実装を生成し、振る舞いの同等性を検証する支援ができる。ソースコードは異なるが、人間による労力の多くを手作業で繰り返す必要はなくなる。
これにより、2つ目の利点に注目が移る。別々のプラットフォームには、依然として異なるビルドシステム、依存関係、リリース手順、テスト環境、専門的判断が必要だ。エージェントはこれらの作業を支援できるが、チームは出荷するすべての成果物に責任を負い続ける。
フレームワークのメンテナーは、より複雑な価値提案に直面している。ソフトウェア翻訳が安価になれば、「一度書けばどこでも動く」という訴求力は弱まる。クロスプラットフォームツールは、信頼性、反復速度、チームの流動性、エコシステムの質、調整オーバーヘッドの削減を通じて価値を示さなければならない。
モバイルエンジニアリングのリーダーも、別の方向から圧力を受ける。経営層はShopifyのSwift・Kotlin開発を、あらゆる企業が共有コードベースを放棄できる証拠と解釈するかもしれない。しかし、その結論はShopifyがエージェントを中心に構築したシステムを見落としている。
Shopifyはモデルにアプリケーション全体を一度で再生成させたわけではない。構造化されたワークフロー、レビューチェックポイント、テストツール、アーキテクチャ上の制約を整備した。経験豊富なエンジニアが、要件、プラットフォームの判断、プロダクション品質に引き続き責任を持った。
この移行は、非常に有利な入力からも始まった。動作するReact Native製品である。このアプリケーションは、画面、インタラクション、ナビゲーション、分析、データ挙動に関する実行可能な仕様として機能した。エージェントは製品全体を発明するのではなく、定義済みの振る舞いを翻訳していた。
この違いは、文書化が不十分なアプリケーションを抱える企業に追加の圧力を与える。AI生成の移植は、明確な参照動作と観測可能な結果に依存する。曖昧なレガシーシステムでは、バグの再現、エッジケースの見落とし、互換性のないパターンの創出といった機会がエージェントにより多く生じる。
開発者も影響を受ける。React Nativeはかつて、Web経験者がモバイル機能に取り組めるようにすることで、Shopifyの貢献者層を広げた。ネイティブコードは伝統的に、Swift、Kotlin、iOS、Androidに関する専門知識により大きな価値を置いてきた。
Shopifyによれば、現在ではエージェントがエンジニアの主要スタック外での貢献を支援している。馴染みのある宣言型インターフェースのパターンにより、SwiftUIとJetpack ComposeもReact Native開発者にとって学びやすくなった。SwiftUIとJetpack Composeは、アプリケーションの状態を通じてインターフェースを定義するAppleとGoogleのモダンなフレームワークだ。
これはプラットフォームの専門知識を不要にするものではない。ネイティブエンジニアは、ライフサイクルの挙動、アクセシビリティ、メモリ、バックグラウンド処理、プラットフォームの慣習、リリース制約を依然として理解している。生成されたコードは正しく見えても、アーキテクチャの乖離や微妙なパフォーマンス問題を生む可能性がある。
必要となる対応は、必ずしもフレームワークの移行ではない。チームは、共有コードがどこで実質的な節約を生むのかを再計算する必要がある。また、自らの環境において、エージェントが2つの実装間で品質を維持できるかを示す証拠も必要となる。
React Nativeチームにとって、最も強力な対応は理念的なものではなく運用上のものになる。更新に要する労力、依存関係の保守、クラッシュ率、起動速度、ビルド時間、プラットフォーム固有の例外を測定できる。これらの数値は、共有実装が抽象化レイヤーのコストに見合っているかを明らかにする。
ネイティブチームにとって、Shopifyの結果はAI生産性を実証する基準を引き上げる。コード補完だけでは不十分だ。信頼できるエージェント型ワークフローは、分析、アクセシビリティ、ナビゲーション、テスト、リリースの安全性、一貫した製品挙動を維持しなければならない。
したがって長期的な圧力は、両陣営に向けられる。クロスプラットフォームの支持者は、コード再利用を超える利点を定量化しなければならない。ネイティブの支持者は、エージェント支援による重複が、移行の熱気が過ぎ去った後も保守可能であることを証明しなければならない。
この転換はReact Nativeの性能ではなく、再利用に関するものだ
Shopifyの決定は、コード再利用と製品の一貫性を別のエンジニアリング課題として扱い、両者を切り分けている。
React Nativeは歴史的に、これらの目標を結び付けてきた。共有コンポーネントや機能は通常、両アプリケーションが実装の大部分を同じく実行するため、プラットフォーム間で似たように動作した。この関係により、各プラットフォーム版が乖離し得る領域は減少した。
Shopifyの新しいモデルは、共有インターフェースコードを手放しながら一貫性を維持する。チームは共通の仕様、テスト、デザインルール、分析契約、レビューチェックポイントを使用する。そのうえでエージェントが、各プラットフォームのネイティブフレームワークを使い、同じ意図された振る舞いを実装する。
これは単なるプログラミング言語の切り替えよりも深い転換だ。同社はソース・オブ・トゥルースを上位層へ移している。共有コードを主な製品契約として扱う代わりに、レビュー済みの意図と観測可能な挙動を契約として扱う。
このアプローチは、ネイティブの利点をいくつか維持する。開発者はAppleとGoogleがリリースするファーストパーティAPIを利用できる。共有抽象化との折り合いを付けることなく、プラットフォームの慣習に従える。また、アプリケーションとOSの間にあるフレームワークや依存関係のレイヤーも取り除ける。
この変更は、ShopがReact Nativeへの別の大規模投資に直面していた時期に行われた。このアプリケーションは、レンダリング、ネイティブモジュール統合、共有コードとプラットフォーム固有コードの境界を変更するフレームワークのNew Architectureを採用する必要があった。
その投資を行う前に、ShopifyはSwiftUIとJetpack Composeによる直接開発を試した。あるエンジニアは、コーディングエージェントを使ってShopの可能な限り多くをネイティブiOSプロトタイプへ移行するために1週間を費やした。
このプロトタイプはプロダクション対応ではなかった。しかし、画面、インタラクション、アプリケーションフローを十分に再現し、全面移行が実現可能に見えるものとなった。エージェントは、定義済みの機能と可視化された挙動を基に作業できる場合に最も力を発揮した。
その後、6人のエンジニアからなる中核チームがネイティブの基盤と主要なShopのユーザージャーニーを構築した。機能チームは途中から加わり、それぞれの領域を検証してエッジケースに対応した。Shopifyは概念実証から12週間以内に、ストアで稼働するネイティブアプリケーションへ移行した。
こうした数値が、この方針転換を現実的なものにした。従来型のグリーンフィールド・リライト、すなわち既存アーキテクチャを引き継がずに新たな実装を構築する方法では、数年を要する可能性がある。また、製品開発を停滞させ、長期にわたる機能同等性の問題を招くこともある。
Shopifyは以前、逆方向でその課題を経験していた。React Nativeへの段階的な移行では、iOS、Android、React Nativeという3つのアーキテクチャが並存する期間が生じた。2022年の説明では、当初のペースでは4〜5年を要したとされる。
同社はネイティブへの回帰にあたり、グリーンフィールドのアプローチを選択した。既存のReact Nativeアプリケーションをコーディングエージェントの参照元として使いつつ、新しいコードベースによって古いアーキテクチャ上の制約を取り除けると説明している。プロトタイプでは、従来より大幅に短期間でアプリケーションを再構築できる見通しが示された。
Shopの成果は、パフォーマンス面の根拠も提供した。Shopifyによると、ネイティブiOSアプリケーションではホーム画面の主要コンテンツが表示されるまでの時間が2,466ミリ秒となり、従来の3,200ミリ秒から改善した。起動時間は23％短縮された計算になる。
Androidでは、起動時間が4,433ミリ秒から2,233ミリ秒へと低下し、50％の短縮となった。Androidのリリースビルドも293 MBから184 MBへ縮小した一方、iOSのビルドは67 MBから68 MBへ増加した。
Androidのリリースビルド時間は約75％短縮された。Shopifyはまた、Pixel端末でのフィードスクロールおよびナビゲーション時に、ネイティブAndroidアプリケーションが毎秒120フレームに到達したことも示した。
セッション安定性は、従来少なくとも99.5％だったものが、ネイティブ版のリリース後には少なくとも99.95％へ向上した。Shopifyはこの変化を、クラッシュするセッションが10分の1に減少したものと位置づけている。
これらは独立したベンチマークではなく、同社が報告した比較値である。移行には製品の簡素化も含まれ、一部の画面は廃止され、他の画面は合理化された。そのため、すべての改善をネイティブ技術だけに帰することは難しい。
Shopify自身もそのような主張はしていない。同社はReact Nativeアプリケーションも高速であり、React Nativeは依然として優れたフレームワークだと明言している。中心的な論点は、エージェントによって重複作業が減少した後の、共有実装の相対的な価値にある。
この区別により、React Native対ネイティブという誤解を招く結論を避けられる。Shopifyは、すべてのアプリケーションに通用する普遍的なベンチマークを提示しているわけではない。同社のチーム、ツール、アーキテクチャ、製品規模においては、現在は異なるバランスが有利だと報告している。
Helixが示す、移行が単なるコード生成以上だった理由
Shopifyは、移行を管理された検証ループへ変えることで、ネイティブ実装の重複を管理可能にした。
同社は、一括変換では保守不能なコードが過剰に生まれることを突き止めた。事前に詳細な仕様を用意しても、アプリケーション全体の自動リライトを信頼できるものにはできなかった。出力は完成しているように見えても、一貫しないパターンや欠落した挙動を隠している場合がある。
Shopifyは、移行作業を小さなチェックポイントに分割するためにHelixを開発した。開発者がシステムに画面を指定すると、HelixはReact Native実装を読み取る。そして、人間が素早くレビューできる順序立てた作業手順を提案する。
各チェックポイントは、テストを通じてその挙動を実証しなければならない。次のチェックポイントが始まる前に、視覚比較、2回の敵対的なコードレビュー、人間による承認も受ける。フィードバックは蓄積され、時間の経過とともにワークフローの自律性が高まる。
この仕組みは、生の生成速度より重要である。ソフトウェア移行は、レビュー担当者が理解できる速度を上回ってエラーが蓄積すると失敗する。受け入れ済みの小さな単位に分けることで、新しいアプリケーションに入る未検証の挙動を抑えられる。
Shopifyはまた、個別のworktreeで複数のエージェントセッションを実行した。専門化されたサブエージェントが既存コードを調査し、挙動を文書化し、プラットフォーム別の計画を作成し、機能を実装して機能同等性をレビューした。開発を進める前に、エンジニアが要件と実装計画を承認した。
計画の承認は、レビューされた内容のハッシュに紐づけられた。計画が変更されると、それまでの承認は無効になった。この設計により、エージェントが承認後に別の計画を密かに実装する可能性を減らした。
ワークフローは、目に見えるインターフェース要素以上を検証した。Shopifyによれば、ソースレビューは状態、ナビゲーション、分析、アクセシビリティ、データの挙動まで対象とした。スクリーンショットだけでは把握できないため、これらの領域には移行で最も難しい失敗が潜みやすい。
分析データの維持は特に重要だった。レコメンデーションやその他のダウンストリームシステムは、想定どおりのイベントとコンテキストフィールドに依存していた。見た目が正しいアプリケーションでも、イベント名、回数、ペイロード間の関係が変われば、意思決定システムを損なう可能性がある。
Shopifyは、ライブのアプリケーションイベント、ログ、状態を構造化された形式で公開する別のツール、Tardisも開発した。エージェントはアプリケーションにコマンドを送り、問題を調査し、ナビゲーションを確認し、手作業を減らして修正を検証できた。
機能同等性のレビューでは、TardisがReact Native版とネイティブ版のアプリケーションから、名前付きチェックポイントにおけるスクリーンショットとイベントウィンドウを取得した。エージェントは、タイムスタンプや一意のページ識別子などの正当な差異を考慮しながら、イベントフィールドを比較した。
アーキテクチャはシミュレーターの遅延にも対応した。モバイル向けエージェントは、インターフェースの状態を理解するためにアクセシビリティツリーやスクリーンショットへ依存することが多い。数秒でコードを変更できても、シミュレーターを介したビルドとテストには数分を費やすことがある。
Shopifyは、この遅いループには頻繁な人間の付き添いが必要だと判断した。React Nativeのホットモジュールリロードは反復作業を改善したものの、シミュレーターのボトルネックを解消したわけではない。フィードバックが遅く脆弱なままであれば、モデル能力の価値には限界がある。
同社は、ビジネスロジックをインターフェースから分離することで対応した。ヘッドレスのビジネスロジックは、アプリケーションを表示せずに実行できる。Shopifyはそのロジックをコマンドラインインターフェース経由で公開し、エージェントがデスクトップ上でミリ秒単位で実行できるようにした。
これがShopifyのネイティブモバイル開発を支える仕組みである。エージェントが単に6人のエンジニアを生成コードで置き換えたわけではない。Shopifyは、マシンの参加を前提に、アプリケーションアーキテクチャ、フィードバックシステム、レビューフェーズ、テストへのアクセスを再設計した。
この取り組みは、見かけ上の経済性を変える。2つの実装を維持するコストが下がる一因は、組織が共有の検証システムに投資していることにある。共通資産はもはやインターフェースコードではなく、期待される挙動を記述し検証する仕組みになっている。
このモデルは、チームが技術的意思決定の検索可能な記録を構築する方法にも似ている。仕様、計画、レビュー結果、テスト結果は再利用可能なコンテキストとなる。engineering knowledge baseは、人間が文書全体を横断してこうした意思決定を追跡する助けになり得るが、リポジトリレベルのテストに取って代わるものではない。
このアプローチは、成熟したインフラを持つ大規模組織に有利である。Shopifyはカスタムツールを作成し、広範な自動チェックを維持し、経験豊富なエンジニアをアーキテクチャとレビューに配置できた。小規模なチームの場合、共有コードを通じて調整を提供するフレームワークから得られる利益の方が大きいかもしれない。
したがって、真の争点は共有実装と共有意図のどちらにある。React Nativeは再利用可能なソースコードに一貫性を直接組み込む。Shopifyの新しいプロセスは、仕様、計測、テスト、管理された変換を通じて一貫性を組み込む。
Shopifyの成果はReact Native対ネイティブの議論を決着させない
12週間でのリライト成功は、2つのネイティブコードベースがライフサイクル全体を通じてより低コストで維持できることを証明するものではない。
移行速度は、最初の指標にすぎない。より難しい検証は、両アプリケーションが独立して進化した後に訪れる。新機能、OSの変更、緊急修正、担当者の入れ替わりを経て、エージェントが実装の整合性を保ち続けられるかが明らかになる。
機能同等性は依然として明示された要件である。Shopifyは、AndroidとiOSが常に整合していなければならないとしている。以前は、共有されたReact Nativeコードが、その条件の多くを構造的に担保していた。新しいプロセスでは、開発とリリースの統制を通じてそれを担保する必要がある。
これには複数の失敗モードがある。エージェントは、同等の挙動を持ちながら互換性のないアーキテクチャパターンを作る可能性がある。iOSの前提をAndroidへ持ち込むことも、参照アプリケーションに含まれるためにレガシーのバグを維持することもあり得る。
生成コードは、テストに合格しながら重複や技術的負債を増やす可能性もある。Shopifyは、アーキテクチャの乖離、ロジックの重複、パフォーマンス問題などのリスクを認めている。リポジトリのガイダンス、lint、静的解析、パフォーマンスチェック、人間によるレビューは引き続き必要である。
したがって、ネイティブの専門知識は重要性を失うのではなく、むしろ増す。エンジニアは、生成されたSwiftがAppleの慣習に従っているか、生成されたKotlinがAndroidのアーキテクチャに適合しているかを判断しなければならない。また、モデルが忠実に再現したものの維持すべきではない挙動も見極める必要がある。
Shopの移行は、安定した参照実装の恩恵を受けた。新規製品の開発は異なる問題を生む。どちらのプラットフォームにも受け入れられたバージョンがない場合、エージェントは既知のソースから挙動を変換できない。チームはまず、両方の実装に向けて意図を十分明確に定義しなければならない。
製品探索はその作業を難しくし得る。デザイナーとエンジニアは、初期バージョンを使いながら頻繁に挙動を洗練させる。共有React Nativeコンポーネントであれば、その改善はただちに両プラットフォームへ適用されるが、ネイティブチームはそれを2回反映し、検証しなければならない。
パフォーマンス比較にも注意が必要である。ShopifyはShopをクリーンな基盤上に再構築し、製品の一部を簡素化した。ネイティブフレームワーク、依存関係の削減、画面の廃止、アーキテクチャの整理はいずれも、報告された改善に寄与した可能性がある。
測定値は独立したテスト機関ではなくShopifyによるものだった。本番デプロイメントを説明しているため価値はあるが、普遍的な比率として扱うべきではない。アプリケーションごとに、起動経路、ネイティブ統合、チーム構造は異なる。
React Nativeには、コーディングエージェントでも消せない利点が残る。共有実装は、ビジネスロジックが乖離し得る箇所の数を減らす。そのエコシステムは、ライブラリ、デバッグの実践、デプロイメントツール、大規模なReact開発者コミュニティも提供する。
Shopify自身も、こうした強みを強調してきた。以前の移行では共有基盤が生まれ、開発者がアプリケーション間を移動しやすくなった。同社はまた、React Nativeによってチームがプラットフォーム差異を絶えず調整することなく価値を提供できたとしている。
オープンソースへの移行は、別の不確実性を加える。Shopifyは2026年末までReact Native Skiaを支援する予定で、その後はメンテナーのWilliam Candillonが新しい名称で継続する。元のリポジトリはいずれアーカイブされる予定だ。
FlashListは異なる道筋をたどる。Shopifyによると、この高性能リストライブラリは週あたり約200万回ダウンロードされている。同社は、他組織との長期的な管理体制を協議しつつ、重大な互換性問題を修正する意向だ。
Restyleは利用者基盤がより小さく、アーカイブされる予定である。Shopifyによれば、2026年末までは機能し続け、別のメンテナーへの引き継ぎ支援が行われる可能性もある。これらの移行は、Shopifyのライブラリに依存する開発者にとって、実務的な計画作業を生じさせる。
またこれは、主要ユーザーの離脱が、その技術自体の信頼性を損なわなくてもエコシステムに影響を与える理由を示している。React Nativeは、有力な採用企業からのエンジニアリング投資、実地検証、組織的な支援を失う。コミュニティによる運営でその貢献を補うことはできるが、引き継ぎが成功しなければならない。
同社のより広範な移行は、なお完了していない。最初に移行するアプリケーションはShopだ。主要なShopifyアプリケーションには、300を超える画面、ウィジェット、Apple Watchアプリケーション、コンプリケーション、Siriショートカットが含まれている。
Shopifyによれば、そのアプリケーションは2026年後半にネイティブ版としてリリースされ、その後に残りのアプリケーションが続くという。これらのプロジェクトは、より幅広いプラットフォーム統合とマーチャントにとって重要なワークフローを含むため、Shopよりも厳しい検証となる。
それまでは、責任ある結論は限定的だ。Shopifyは、エージェント支援によるネイティブ移行が、1つの主要アプリケーションに対して迅速に機能し得ることを示した。しかし、モバイルポートフォリオ全体にわたる長期的な保守コストは、まだ明らかにしていない。
Shopifyの賭けが成り立つかを示す3つのシグナル
次に必要な証拠は、再現性、継続的な同等性、安定したオープンソースへの引き継ぎを示すものでなければならない。
最初のシグナルは、主要なShopifyアプリケーションのネイティブ版リリースだ。300を超える画面と広範なApple統合を備えるこのアプリケーションは、Shopより難しい移行となる。機能を維持した予定どおりのリリースは、Shopifyの手法が拡張可能だという主張を強めるだろう。
そのリリースでは、日程そのもの以上に品質が重要だ。起動時のパフォーマンス、セッションの安定性、ビルド時間、アクセシビリティ、分析データの継続性、マーチャントのワークフローは、React Native版と同等か、それ以上であるべきだ。遅延した、あるいは品質にばらつきのあるリリースは、迅速なグリーンフィールド移行の正当性を弱める。
2つ目のシグナルは、独立した機能開発が始まった後も同等性が維持されることだ。Shopifyは、レビューの遅延を増やさずにiOSとAndroidが同等の機能を継続的にリリースできることを示さなければならない。移行のスループットよりも、複数のリリースサイクルにわたる証拠が重要になる。
この検証は、Shopify Swift Kotlin開発の核心に触れる。エージェントは完成した機能を変換できるが、プロダクトチームは実装中にも要件を変更する。分析データと挙動の一貫性は、共有ソースコードの代わりに共有仕様を長期的に用いられるかどうかを示すだろう。
3つ目のシグナルは、ShopifyのReact Nativeライブラリの将来だ。React Native Skiaの円滑なフォーク、FlashListの持続可能な運営、Restyleに関する明確な指針は、Shopifyが責任を持って撤退を管理しているという主張を裏付けるだろう。
保守の混乱は、異なる物語を示す。それは、アーキテクチャの変更が1社のリポジトリを超えるコストを課すことを証明する。そのコストは、Shopifyの以前のコミットメントを前提に計画を立てた開発者に及ぶことになる。
エンジニアリング責任者は、この判断を模倣する前にこれらのシグナルを注視すべきだ。また、クラッシュ、起動時間、アプリケーションサイズ、ビルド時間、フレームワーク保守、同等性のための作業について、自らのベースラインも確立すべきである。
そのうえで、実際の機能を用いた範囲を限定したプロトタイプを実行できる。テストには、分析、アクセシビリティ、ナビゲーション、エラー状態、プラットフォームの慣習を含めるべきだ。生成されたコード行数だけでなく、レビュー時間と欠陥の発見も測定すべきである。
Shopifyのネイティブモバイル開発が重要なのは、エージェント時代における再利用の考え方を再定義するからだ。これは、React Nativeとネイティブのどちらが優れているかについて、普遍的な答えを示すものではない。代わりに、厳しい問いを提示する。実装コストが低下するなら、エンジニアリング組織はどこに信頼できる唯一の情報源を置くべきなのか。
チームはこの問いに、プロダクション環境で得られた証拠で答えるべきだ。エージェントが複数のリリースを通じて、レビューと保守に要する総工数を削減するかを追跡する。そうであれば、分離されたネイティブアプリケーションはより魅力的になる。コード生成の改善よりも調整コストの増加が速いなら、共有実装にはなお存在意義がある。
