「寫兩遍」的成本被重新定了價：Shopify 回到原生，是一場被重新設計過的技術決策

2026 年 9 月 10 日，Shopify 宣布把行動端技術棧從 React Native 遷回 Swift 與 Kotlin。到了 10 月 27 日，這則消息又在掘金上被一篇長文重新翻出來討論，標題下的問題很大：AI 會不會幹掉 React Native。與其跟著這個問句走，不如先把這次決策本身當成一件被設計過的物件來看。它有清楚的輸入、明確的評估流程，還有一組被重新定價的成本欄位。

2020 年的三個理由，2026 年還剩多少

Shopify 在 2020 年全面轉向 React Native，當時要解決的是三件事：同一個功能不要開發兩遍、讓開發者可以跨技術棧工作、少花時間補齊兩端差異。這三件事在過去六年都成立，他們自己也曾多次公開肯定這個選擇，2025 年 1 月 AI 編碼工具已經開始普及時，他們仍表示會繼續投入。

真正的變化發生在成本結構上。同樣一個功能，過去用 React Native 寫一遍的成本，明顯低於用 Swift 和 Kotlin 各寫一遍；現在這個差距縮小到不再足以決定技術選型。把「寫兩遍」的隱含價格重新算一次，才是這次遷移的起點。

這與我們先前分析的Shopify 遷移介面與 Helix 系統的 checkpoint 設計是同一件事的另一面：遷移本身也被做成了可審查的工程流程，共享的規格說明、測試與審查檢查點，讓兩端一致性有了被量測的依據。

智慧體在流程裡的位置

來源文章提到一個容易被略過的細節：Shopify 從 2021 年就開始用 LLM 開發軟體，比 ChatGPT 問世還早一年，最初用於實現功能、修 bug 和審查程式碼。到了 2025 年底，他們做了一次具體驗證：借助 LLM，用 Swift 和 Kotlin 重建了幾款大型應用中的核心部分，結果是智慧體可以參考 iOS 版本實現 Android 功能，反方向也成立。

這裡的重點並非「原生開發變成只維護一份程式碼」。兩個平臺仍要分別開發、分別維護。變化在於實現、程式碼轉換、測試與審查這些工作，有足夠多的部分被智慧體承接，讓過去那個決定性的成本項，退化成一個普通成本項。剩下的收益則是原生的老優勢：更直接地使用平臺能力與官方工具，少背框架適配與第三方依賴的維護負擔。來源也明確指出，效能並非這次切換的決定性因素。

開源庫的退場排版

一個技術決策的設計完整度，往往看它如何處理尾端。Shopify 對三個開源庫給出了不同的安排：React Native Skia 贊助到 2026 年底，主要維護者 William Candillon 計畫 fork 倉庫後以新名稱發布，過渡完成再歸檔原倉庫；每週下載量約 200 萬次的 FlashList，會繼續修復相容性關鍵問題，同時與其他公司討論長期維護；用戶較少的 Restyle 則直接歸檔。

三種處置對應三種使用者規模，這套退場安排本身就是一份介面：誰能等、誰不能等、誰必須自己想辦法，被清楚分層。

「AI 幹掉框架」是問錯了對象

回到那個熱榜問句。React Native 沒有變差，來源也一再強調它仍是優秀框架、Shopify 的應用跑得也快。被改寫的是選型公式裡的一個係數：當重複實現的成本被智慧體壓低，跨平臺框架的核心賣點就跟著貶值。受影響的也不會只有 React Native，任何以「寫一次、跑兩端」為主要價值主張的方案，都面對同一個重新定價的問題。

所以該問的不是 AI 會不會幹掉哪個框架，而是當「寫兩遍」的價格標籤被換掉之後，你手上的技術決策，還剩下哪些欄位是真的。Shopify 給出的答案是：平臺能力、官方工具、依賴負擔。這些欄位本來就在，只是過去被成本那一欄蓋住了。