2025年1月、ShopifyのMustafa Aliは同社のエンジニアリングブログで、React Nativeの将来は明るく、Shopifyは今後も投資を続けると書きました。その1年8か月後の2026年9月10日、彼は同じブログに、ShopifyのモバイルアプリをすべてReact NativeからSwiftとKotlinに移すという記事を載せました。
Shopifyは、オンラインストアの開設と運営を支えるプラットフォーム企業です。React NativeはMetaが作った開発ツールで、アプリのコードを一度書けばiOSとAndroidの両方で動かせます。SwiftはiOSアプリを、KotlinはAndroidアプリを作るための専用の言語です。つまりこれからは、同じ機能をiOS向けとAndroid向けに1回ずつ、合わせて2回書くということです。
Shopifyが挙げた理由はひとつです。コーディングモデルが大きく進歩したことで、同じ機能をSwiftとKotlinで2回作るのが、以前ほど高くつかなくなりました。Shopifyはこの変化を「LLMs changed one of the core assumptions behind our 2020 decision（LLMが、2020年の決定を支えていた中心的な前提のひとつを変えた）」と書いています。
2020年、ShopifyはiOSアプリとAndroidアプリを1つのコードで作ると決めました
Shopifyが2020年にReact Nativeを全面採用した理由は3つありました。同じ機能を2回作らないこと、モバイル開発の経験がない開発者もアプリ開発に加われるようにすること、2つのアプリの機能をそろえるのにかかる時間を減らすことです。
Shopifyは、3つとも手に入れたと書いています。機能を1回作るだけで済んだので大幅に時間を節約でき、モバイルの経験がない開発者もアプリに貢献し、2つのアプリの機能をそろえる時間も減ったそうです。パフォーマンスの調整やフレームワークのアップデートへの追従には少なからぬ手間がかかりましたが、得たもののほうが大きかったといいます。Shopifyが覆したのは、失敗した決定ではなく、成功した決定でした。
パフォーマンスが理由でネイティブに移るわけでもありません。Shopifyは「React Native apps can be fast. Ours are.（React Nativeのアプリも速くできる。うちのアプリも速い）」とはっきり書いています。ネイティブに移るのは、エージェントによって1つのコードを2つのプラットフォームで共有する利点は小さくなった一方で、プラットフォームごとに作る利点はそのまま残っているからだそうです。別々に作れば、AppleとGoogleが提供するプラットフォームの機能や公式の開発ツールをより直接使えますし、コードとプラットフォームのあいだに挟まるフレームワークや依存ライブラリも減ります。
エンジニア1人がエージェントと組んで1週間、ShopアプリをiOSのコードに移してみました
最初にネイティブへ移したアプリはShopです。買い物をする人が注文を追跡したり支払いをしたりする、Shopifyの消費者向けアプリで、アプリストアのショッピングカテゴリでよく上位に入ります。このアプリはちょうど、React Nativeの新しいアーキテクチャへ移る大がかりな作業を控えていました。その作業にコストをかける前に、Shopifyはコーディングエージェントを使って、iOSとAndroidそれぞれの専用コードでいきなり作り直せるかどうかを試しました。
エンジニア1人が1週間、エージェントと一緒に既存のReact Nativeアプリを参考にしながら、移せるだけの機能をiOSアプリに移しました。1週間でリリースできる水準にはなりませんでしたが、機能をひとつずつそのままiOSアプリに移せることは確かめられました。エージェントが特に力を発揮したのは、参考にできる既存の実装があるときです。すでにある機能を新しいコードに移し、画面の骨組みを作り、データをつなぎ、アニメーションを入れ、画面を見ながらレイアウトを整えました。
本番の移行は、中心メンバー6人が担いました。6人がアプリの土台と主要な利用の流れを作り、機能ごとのチームが途中から加わって自分の担当領域を検証し、抜けていた例外ケースを埋めました。既存のユーザーには、いつものアップデートと同じように感じてもらう必要がありました。ログインが切れてはいけませんし、プッシュ通知も変わらず届かなければなりません。レコメンドのように、アプリが送るイベントを受け取って使う別のシステムがあるので、分析イベントも以前と同じ内容で送る必要がありました。その一方で、一部の画面はあえて廃止し、一部はシンプルに整理しました。Shopifyによると、概念実証からアプリストアでの公開まで12週間かかりました。
2020年に1つのコードを選んだ2つ目の理由は、モバイル開発の経験がない開発者もアプリ開発に加われるようにすることでした。今回は、1つのコードがなくても開発者が両方のプラットフォームの開発に加われました。React Nativeの開発者は、iOSとAndroidのUIフレームワークであるSwiftUIとJetpack Composeに、予想よりすんなりなじんだそうです。画面を宣言的に書くやり方がReactと似ていて、エージェントも、開発者が自分の主戦場ではないプラットフォームに早く慣れて貢献できるよう手助けしたといいます。それでもネイティブの専門家は引き続き欠かせませんでした。生成されたコードは、機能の要件を満たしていても、重複や設計から外れた構造、パフォーマンスの問題を持ち込むことがあったとShopifyは書いています。
アプリ全体を一度にネイティブへ書き直させると、出荷できないコードが大量にできました
Shopifyがまず警戒したのは、いちばん簡単そうに見える方法でした。エージェントにReact Nativeのコードを丸ごと渡し、ネイティブで一気に書き直させる方法です。最初にできるだけ情報を集めて仕様書とタスクファイルにまとめてから実装させても、保守できないコードが大量にでき、リリースできなかったといいます。
そこでShopifyは、最大のアプリであるShopifyアプリをネイティブに移すために、Helixという社内ツールを作りました。Helixは、最初の出力が正しいとは期待しません。エンジニアが画面をひとつ選ぶと、Helixはその画面を小さなステップに分けて順番を提案し、エンジニアはその順番を数分で確認して承認します。最初のステップはたいてい画面の骨組みで、後になるほど範囲が広がります。ステップごとの説明を数語に絞っているのも、意図して選んだやり方です。Helixの記事には「Nobody can effectively review a wall of generated text.（生成された長文の壁を、まともにレビューできる人はいない）」とあります。
各ステップは4つの関門を順番に通過してはじめてコミットされ、そこで次のステップが始まります。
- 動作テスト
旧React Nativeのコードを読んでステップごとに作ったテストのうち、該当するものをすべて通過しなければなりません。 - 画面の比較
新しいアプリと旧アプリを同じ状態でキャプチャし、Geminiに細部まで妥協しないデザインレビュアーの役を任せて、違いを画面上の位置と深刻度まで含めてすべて書き出させます。コードで直せる違いがあれば、原則として次へは進めません。 - 粗を探すコードレビュー2本
互いに文脈を共有しない2つのレビュー用エージェントが、Shopifyが文書で定めたアプリ構造の基準に沿っているかを確認します。指摘はすべて直さなければならず、2つとも承認するまで繰り返します。 - エンジニアの承認
エンジニアがコードと動いているアプリを見て判断します。このフィードバックは記録されて次のステップに生かされ、承認された結果が積み重なるほど、人の手を介さずに進められる範囲が広がります。
関門は助言ではなく、通過条件です。落ちたらエージェントはフィードバックを見て直し、もう一度チェックを受けます。何度でもやり直せますが、結果が十分よいと自分で判断して先へ進むことはできません。Helixの記事はこの方式を「An attempt is allowed to be wrong. It is not allowed to ship until it isn't.（試みは間違っていてもいい。間違いでなくなるまで出荷されないだけだ）」とまとめています。
コードを2つに増やすのは複雑さを2倍にすることだ、という反論も根強くあります
この発表はHacker Newsで1,200ポイントを超え、900件以上のコメントがつきました。反論も多く出ています。AIがあるから複雑さはタダだと思い込む罠だというコメントがあり、そのコメントは、AIも人間と同じく複雑なコードを前にすると迷うと付け加えていました。技術的な理由もないのにショッピングアプリで同じものを2回作るのか、という批判もありました。React Nativeのように1つのコードで複数のプラットフォーム向けアプリを作るツールを自分で開発しているある開発者は、コストがかさむので数年のうちにまた共通のツールへ戻ってくるだろうと予想しています。その人が競合ツールの作り手であることも、あわせて見ておく必要があります。
エンジニアを大勢抱える大企業だからこそできる選択だ、という反論もありました。Shopアプリは6人が中心となってネイティブに移しましたが、その後ろには機能ごとのチームと、エージェント用の社内ツールを別に作った人たちがいました。ShopifyがとりわけAIを前面に押し出してきた会社だという点もあります。CEOのTobi Lütkeは2025年4月、「Reflexive AI usage is now a baseline expectation at Shopify（AIを反射的に使うことは、いまやShopifyでは当然の前提だ）」と書いた社内メモを自ら公開しました。今回の記事にも、ChatGPTが登場する1年前の2021年からLLMでソフトウェアを作ってきたと書かれています。発表記事とHelixの記事は、どちらもモバイルとAIのエンジニアの採用案内で締めくくられています。
最大のアプリは、まだネイティブへの移行の途中です。画面が300を超え、ホーム画面のウィジェットやApple Watchアプリまで備えたShopifyアプリで、Shopifyは年内にリリースするとしています。
共有コードが守っていた機能の一致を、これからは確認の工程で守ります
1つのコードで作っていたころは、2つのアプリの機能は自然とそろっていました。同じコードが両方で動いていたからです。ShopifyはShopアプリをネイティブに移したあとも、「Android and iOS must be at feature parity at all times（AndroidとiOSは常に同じ機能をそなえていなければならない）」という原則をそのまま残しました。そして、以前は共有コードが守っていたこの原則を、これからは開発とリリースの手順で守ると書いています。
その手順の中心にあるのが確認です。エージェントが手を入れたアプリがきちんと動くかを見るには、シミュレーターの中のアプリの状態を、画面構造の情報やスクリーンショットから読み取る必要があります。Shopifyは「It doesn't matter how good the model is if it can't test its work quickly（自分の作業をすばやく確かめられないなら、モデルがどれほど優秀でも意味がない）」と書いています。そのためShopifyは、アプリの動作を画面から切り離し、コマンドラインから直接呼び出せるようにアプリの構造を変えているところです。
Shopifyによると、エージェントがコードを直すのにかかるのは数秒ですが、その結果を確かめるには数分かかります。
2020年のShopifyは、コードを1つにまとめ、書いて管理するコードの量を減らすことに力を注ぎました。コードを書いて直す仕事をエージェントに任せられるようになったいま、Shopifyが力を注いでいるのはコードの量ではなく、AIが作った結果を確かめる時間です。
さらに深掘りしたい人へ
