ShopifyがReact Nativeからネイティブに回帰、LLMが再び開発コストを変えた
Shopify moves back to Native from React Native
Shopifyは2020年にReact Nativeへ全面移行し、その賭けは成功した。しかしLLMの進化により、SwiftとKotlinで同じ機能を二重に実装するコストが大きく下がった。同社は2025年後半から再評価を始め、AIエージェントを活用してネイティブアプリの再構築を進めている。Shopアプリは12週間で完全ネイティブ化され、Shopifyアプリも今年中に移行予定だ。
LLMが2020年の決定の核心的な前提を変えたため、私たちはモバイルスタックを第一原理から再評価した。
HNでの議論
469- Waterluvian
アプリを必要とする、あるいは持っているすべての企業をスペクトラム上に置くなら、どこかに線があって、おおよそ二つのグループに分けられる。ElectronやReact Nativeなどが理にかなうかどうか、というグループだ。これは単なる普通のエンジニアリング上の判断で、限られたリソースで問題を解決することに過ぎない。企業によって問題もリソースも違う。
テックコミュニティの人々は、こうしたツールの良し悪しについて絶対的な意見を持つことがかなり流行っていることにも気づいているだろう。無知から生まれる魔法のような思考——みんなネイティブに行くべきだとか、React Nativeはどこでも使うべき最高のものだとか、AIがこの線を完全に消し去るだとか。
こうした意見はほとんど価値がなく、面白いことから注意をそらすと思う。この記事のサブタイトルが言っているように、AIによってこの線が動いているということから。そしてそれはおそらく正しい。
- tonic_note
モデルはネイティブiOSアプリの生成がずっと上手くなった。RNの主な魅力は、Web開発者をモバイル開発に活用できることだった。前の会社で私がやっていたのはそれだ。スタートアップにはそれでいいが、最終的には専任のネイティブエンジニアが欲しくなる。各プラットフォームには、そのために最適化できる専任の技術の達人が本当に必要なのだ。
しかし今やコードはすべて生成されるので、RNアプリを持つことの利点はほとんどない……最初からネイティブで始めればいい。どうせ開発者はほとんどコードを書かないのだから。
- atonse
私たちも同じことをした——一晩で90%はできた。その後、数日かけて背景で磨きをかける調整をした。
私たちのアプリはもっと小さく、画面数は15〜20程度。午前0時30分ごろにcodexに目標を与えて始めたところ、React Nativeのコードに基づいてすべての画面を棚卸しし、androidとiOSのディレクトリを作成し、maestroを使い（このツールは数週間前の個人的なアプリビルドですでにセットアップしていた）、朝にはandroidとiOSの両方で全部動くようになっていた。私が寝ている間に約6時間かかった。
アプリははるかに小さく、瞬時に起動し、androidアプリは（ supposedly ）ネイティブに見える。 supposedly と言うのは、私はandroidのスマホを使わないからだ。しかしJetpack ComposeとKotlinを使っている。
そして私はSwiftもKotlinも知らない。正直、React Nativeの存在意義はもう見えない。Expoがとてもクールなエージェント的なことをやっているのは知っているが、ネイティブアプリを書けるのに、なぜそれが必要なのかわからない。
- pkaler
私は今、Cordova Streetを見下ろす机に座っている。Apache Cordovaの名前の由来となった通りだ。この議論をほぼ20年見てきた。
チームは最新のクロスプラットフォームフレームワークに飛びつき、各プラットフォームで最低共通項のアプリになる代わりに人件費を削減できると仮定する。
後者は真だが、前者は偽だ。
実際に起こるのはこうだ。チームはiOSエンジニア20人とAndroidエンジニア20人で始まる。React Nativeのようなものを採用する。すると最終的にプロダクトエンジニア20人とツーリング・フレームワークエンジニア20人のチームになる。
この20年で何度も見てきた。
- fnthawar2
当時成功したからといって、その決定に固執するわけではない。中核となる前提が変われば、それがまだ正しい判断なのかを問い直す用意がある。LLMは2020年の決定の背後にあった中核前提の一つを変えたので、私たちはモバイルスタックを第一原理から再評価した。
その結果、私たちはネイティブに戻ることになった。
- netshade
React Nativeから離れるよう勧めることには賛成だが、「LLMがなければ検討できないほど高コストな移行を可能にした」という話は正しくないと思う。
なぜなら、私は中規模のReact NativeアプリからSwift/Kotlinネイティブアプリへの作り直し移行に参加したからだ。技術作業の大部分は私がやった。作業の大半は2026年1月より前に、LLMのコード支援なしで行われた。ただし後の機能では間違いなくいくらか使った。
これを検討している人には、LLM支援を考慮に入れなくても、この移行は間違いなく検討に値すると言いたい。React Nativeの継続的な税——不要に難しいアップグレード、基盤となるコアフレームワークとのインピーダンスミスマッチ、信じられないほどばらつきのあるライブラリ品質——は、ビジネスが技術をゴールまで導くために本当に多くの時間を費やす原因になる。「ビルド、コンパイル、出荷、確実」の世界に戻れて本当に素晴らしい。Shopifyの記事が『わかっている』と思う根本原則の一つは、フィードバックサイクルの重要性だ。統合テストの話に早い段階で時間を投資したことは、サイクルタイムの短縮に役立ち、後にLLM支援のためのガードレールを提供することにもなった。
要するに、この決定はLLM支援を考慮に入れなくても検討に値するということだ。
- lmf4lol
昨日、寝る直前にAstraを私たちのElectronデスクトップアプリに向けて、iOS用のネイティブSwiftアプリを書いてくれと頼んだ。
そのElectronアプリには750のユニットテストと50ほどの統合テストがある。またmcp経由でElectronアプリにアクセスでき、クリックして調べることもできた。バックエンドコードへの読み取り専用アクセスもAstraに与えた。
3時間動いて、ほぼ機能完全な移植版を届けてくれた。今日、手動テストで3つのバグと1つのパフォーマンス問題を見つけたが、その後すべて修正してくれた。パフォーマンス問題を修正するために、いくつかの異なるビルドを作り、Xcodeでプロファイリングした。
12時30分ごろには、私たちの製品の完全なネイティブアプリ移植版がiPhoneとiPadにあり、チームに見せることができた。縦向きと横向きも正しく処理していた！
言うまでもなく、私は度肝を抜かれた。一方では大好きだ、これでクールなものを全部作れる。しかし他方では、自分の職人の技が完全に価値を失ったということだ。自分に言い聞かせるのは、環境を適切にセットアップしたのは自分だし、誰にでもできるわけではないと。でもそれは現実逃避だ。まったくの現実逃避……そして自分でもわかっている。
- underdeserver
そして私はCodexのデスクトップMacアプリを見ながら、なぜリストとチャットウィンドウとテキストボックスに579MB（圧縮）のダウンロードと4GBのRAMが必要なのかと考えている。
- jrochkind1
シミュレータの部分はよくわからない。おそらく実際にモバイル開発をしたことがないからだろう。
> シミュレータとの対話が必要な場合、CLIはリモートモードで接続し、レイアウトやアクセシビリティツリーを検査することなくコマンドでUIを操作できる。これにより blazing-fast なパフォーマンスとE2Eテストが可能になる。
わかっていないのだと思う。ユーザーが実際に対話するレイヤーで、アクセシビリティツリーとレイアウトをテストする必要は依然としてあるのではないか？
- asimovDev
次はReactを捨てて生のJavaScriptに戻るのか？
私はまだReact以前のGitHubを悼んでいる。色眼鏡かもしれないが、あれは使っていてとても心地よかった。