Shopify、React Nativeをやめネイティブへ回帰 海外で議論に

姉妹サイトの新着

他サイトの新着

ECプラットフォームのShopifyが公式ブログで、自社アプリ「Shop」の開発基盤をReact Nativeからネイティブ(Swift/Kotlin)へ戻したと発表した。この件がHacker Newsで取り上げられ、多くのエンジニアが反応した。焦点になったのは、コーディングエージェント(LLM)の普及によって、iOSとAndroidそれぞれのネイティブコードを別々に書いて保守するコストが下がったのではないか、という見方だ。一方で、大規模な書き直しには失敗のリスクもつきものだとして、過去にDiggが行った刷新を引き合いに、成功と結論づけるのはまだ早いという慎重な声も上がった。Kotlin MultiplatformやRust製の共通コアをネイティブ双方から呼び出す構成など、代替のアプローチも話題になった。

Shopifyが、React Nativeからネイティブへと回帰する

出典: shopify.engineering / 元記事はこちら

8 海外の名無しさん 2026-09-10 14:47
「GPT以前からエージェントでコードを書いていた」と自慢するのはなかなかの企業アピールだ…当時のエージェントってひどい出来だったはずじゃないか? それを言うなら「2016年から量子コンピュータで表計算やってます」と言ってるようなものだ
10 海外の名無しさん 2026-09-10 14:29
次はReactもやめて素のJavaScriptに戻るのか? React以前のGitHubがいまだに懐かしい。美化された記憶かもしれないけど、あの頃は使ってて本当に快適だった
46 海外の名無しさん 2026-09-10 14:51
>>10
それは文化の違いの方が大きいと思う。例えばdiffs.comはReact製だけど、体感でほぼ一瞬で動く
11 海外の名無しさん 2026-09-10 14:26
業界全体の流れになると思う。React NativeやFlutterをやめてネイティブに戻る動き
13 海外の名無しさん 2026-09-10 14:57
LLMがそのうち直接マシンコードを書くようになるまで、あとどれくらいだろうか
14 海外の名無しさん 2026-09-10 14:45
十分なリソースを割ける規模の会社ならネイティブでいい。そうでないならFlutterやReact Nativeなどを使う。単純な話だと思う
15 海外の名無しさん 2026-09-10 14:53
コーディングエージェントのおかげで、ネイティブにしない理由がなくなった
16 海外の名無しさん 2026-09-10 14:30
彼らの理屈は筋が通っている。半年後にフォローアップ記事を読んでみたい
48 海外の名無しさん 2026-09-10 14:47
>>16
技術的な観点からの移行の顛末が知りたいなら、それはもう公開されている(shopify.engineering/shop-app-migration)。内容はかなりしっかりしているから、半年やそこらで状況が変わるとは思えない
17 海外の名無しさん 2026-09-10 14:29
LLMが生成するコードへの見方が変わった副作用として、もうネイティブのコードを書かせる方が楽になったということなんだろう
19 海外の名無しさん 2026-09-10 14:29
React Nativeを使っても、ちょっと凝ったことや最適化をしようとすると結局ネイティブコードに降りる羽目になる。それなら最初からプラットフォームを直接使わない意味がない
50 海外の名無しさん 2026-09-10 14:56
>>19
たいていのアプリは大したことをしていない
20 海外の名無しさん 2026-09-10 14:30
ネイティブ。Metal。抽象化レイヤーは取り除け
22 海外の名無しさん 2026-09-10 14:27
また流行の輪が一周した
51 海外の名無しさん 2026-09-10 14:58
>>22
単なる流行とは思わない。React Nativeは昔からパフォーマンスとUXに多少のペナルティがあったが、それでも開発速度が上がる方が割に合うと多くの人が判断していた。LLMがそのトレードオフを変えた以上、各社が過去の判断を見直さないのはむしろ怠慢だろう
52 海外の名無しさん 2026-09-10 14:37
>>22
レコードみたいにぐるぐる回されてる気分だよ
23 海外の名無しさん 2026-09-10 14:43
自分が思うに、AIはReactをすごくよく理解できる。だからShopifyにとってはそれが利点になり得るはず
25 海外の名無しさん 2026-09-10 14:40
個人的には、今はSwift/KotlinのネイティブコードとUniFFI経由で共有するRustコードを組み合わせるのにいい時期だと思う
54 海外の名無しさん 2026-09-10 14:49
>>25
つまり3つの言語でコードをレビューして保守しろってこと? トークンの完全な無駄遣いに聞こえるし、最悪の場合は技術的負債を3倍の速さで積み上げるだけだ
26 海外の名無しさん 2026-09-10 14:30
SkiaやFlashListが廃れていくのは、React Nativeコミュニティ全体にとって大きな損失だ…
27 海外の名無しさん 2026-09-10 14:31
…React「Native」から、ね
29 海外の名無しさん 2026-09-10 14:36
いい判断だし理にかなっている
31 海外の名無しさん 2026-09-10 14:27
話としては面白いけど、トークン消費量はどれくらいだったんだ?
35 海外の名無しさん 2026-09-10 14:50
>>2
この手の評価もまだ早計だと思う。新しいアプリが実際に展開されてユーザーが満足するまで待った方がいい。おそらくうまくいくとは思うが、これだけの大規模な書き直しは脱線するリスクも十分あるから、まだ声高に成功だと言うのは早い。Diggのエンジニアたちも、自分たちの書き直しには誇りを持っていたはずだ
55 海外の名無しさん 2026-09-10 14:53
>>35
何かをするにもリスクはあるし、何もしないことにもリスクはある。少し話がそれるけど、組織というものは必要以上に「何かをする」方に偏りがちだという印象がある
38 海外の名無しさん 2026-09-10 14:42
>>3
それでもAIはソフトウェアエンジニアの仕事を奪っていないと言う人がいるんだよな…
57 海外の名無しさん 2026-09-10 14:48
>>38
これはAI以前だったらまずやらなかったタイプのプロジェクトだろう
58 海外の名無しさん 2026-09-10 14:51
>>38
これはものすごく退屈な作業だ。目新しさは何もなく、全部書き直してもまた1年後に書き直される運命。LLM向きの仕事であって、人間がやるべきことじゃない
59 海外の名無しさん 2026-09-10 14:45
>>38
一晩で移植できた。ただ、ゼロから作るとなるとかなり手取り足取りやらないと無理だと思う

他サイトの新着

40 海外の名無しさん 2026-09-10 14:42
>>3
自分も同じ結論に至った。エージェント型のワークフローのおかげで、2つのネイティブコードベースを同期させ続ける手間が大きく下がった
60 海外の名無しさん 2026-09-10 14:48
>>40
こちらも同じ結論。今好んで使っている構成は、iOSとAndroidはネイティブにして、共通のコア部分をRustで書きuniffi経由で公開するというもの
41 海外の名無しさん 2026-09-10 14:44
>>3
自社アプリに含まれる独自技術が、学習データに吸い上げられても構わないということなのか?
61 海外の名無しさん 2026-09-10 14:57
>>41
他の人も言っている通り、価値があるのはコードそのものじゃない。それに今はLLMプロバイダーにも他の選択肢がある
62 海外の名無しさん 2026-09-10 14:46
>>41
ほとんどの会社やアプリの価値は顧客との関係にある。つまり価値があるのはコードじゃなくてデータベースの方だ
43 海外の名無しさん 2026-09-10 14:24
>>5
これから1年で、大企業が同じことをするケースをたくさん見ることになると思う
65 海外の名無しさん 2026-09-10 14:33
>>43
むしろ、もっと早く増えていないことの方が意外だ。LLMのおかげで複数のネイティブアプリを保守するのが急に現実的になった。この流れがElectronのようなものを置き換え始めるのを見てみたい
70 海外の名無しさん 2026-09-10 14:47
>>59
以前勤めていた会社では、iOSとAndroidのネイティブ版を作って保守するために専任のSwift/Javaエンジニアを雇っていた(既存のWebアプリの機能を移植するような仕事が中心だった)。実際にそうしていた。でももう今はそうじゃない
75 海外の名無しさん 2026-09-10 14:50
>>70
それはかなり珍しいケースだと思う。たいていの会社は代わりに互換レイヤーを使うものだ
73 海外の名無しさん 2026-09-10 14:34
>>63
その前提はかなり古い。App Storeの審査時間はここ数年、たいてい24時間以内で終わっている。それにKMP(Kotlin Multiplatform)のおかげで、ネイティブの殻にWebViewを押し込むような、最悪のユーザー体験を強いるやり方に頼らなくても、クロスプラットフォームが現実的な選択肢になっている
76 海外の名無しさん 2026-09-10 14:58
>>73
KMPを使うには、チームがKotlinに慣れていることが前提になるんじゃないか?

この話題の背景と論点

React Nativeは開発速度を優先する代わりに、パフォーマンスやUXで多少の妥協を伴う、というのが従来からの前提だった。今回のスレで主流だったのは、コーディングエージェント(LLMによる自動化)の普及で、iOS/Androidそれぞれにネイティブコードを書いて維持するコストが下がった、という見方だ。ただし、こうした大規模書き換えは短期的に「うまくいった」ように見えても、半年〜1年後に問題が表面化することがあり(Diggの例が引き合いに出された)、現時点で成功か失敗かを判断するのは早いという慎重論も根強い。React Nativeの代替としてKotlin MultiplatformやRust+UniFFIによる共通コア方式も候補に挙がったが、言語やチーム体制の面でのコストが別途かかる点も指摘されている。読者が注意すべきは、この移行が「AIがReact Native自体を時代遅れにした」という単純な話ではなく、開発コストの構造が変わったことで各社が既存の技術選定を再検討している、という文脈で語られている点だ。

※本記事は5ch(Hacker News)スレッド「Shopify moves back to Native from React Native」より抜粋・要約して構成しています。

この記事のリアクション

他サイトの新着

まだコメントはありません。

コメントする

誹謗中傷・個人を特定する書き込みは削除対象です。投稿は承認後に表示されます。

相互リンクサイト新着記事