押注 React Native 六年後，Shopify 回頭走原生路線：這次改變計算式的，是 AI

2026 年 9 月 10 日，Shopify Engineering 發布文章〈Native is now the future of mobile at Shopify〉，宣布行動端未來的方向重新回到原生開發：iOS 回到 Swift，Android 回到 Kotlin。距離 2020 年那句「React Native is the Future of Mobile at Shopify」，正好過了六年。

從原生出發，繞道 React Native，再回到原生。如果只看結果，這像是一場原地打轉。但把兩次決策放在各自的時空條件下看，就會發現前後兩次選擇其實都在回答同一個問題：同樣的業務功能，要用多少人力在兩個平臺上各做一遍。改變的不是答案，是計算答案的式子。

2020 年的算盤：一套程式碼，兩個商店

先回到 2020 年。當時 Shopify 的行動應用採傳統原生開發，iOS 與 Android 各自維護技術棧。同一個功能，工程師要用 Swift 寫一遍，再用 Kotlin 寫一遍；測試做兩輪，除錯做兩輪，Code Review 也是兩份。這就像一家連鎖店在兩個城市開分店，菜單相同，卻得僱兩組廚師、建兩間中央廚房，食譜還不能直接共用。

React Native 給出的方案是讓兩個平臺共用同一套業務邏輯，只留少量的平臺差異層。對一個功能迭代快速的電商平臺來說，這等於把兩間中央廚房合併成一間。此後幾年，Shopify 把多個應用與業務大規模遷移到 React Native，內部也建立了配套的開發基礎設施。

值得注意的是，這段押注並沒有以失敗收場。2025 年，Shopify Engineering 曾對五年實踐做過總結，明確表示 React Native 在公司內部是成功的，並對其未來保持正面態度。距離這份肯定，到宣布回歸原生，中間只隔了約一年。

也就是說，2026 年的轉向，並非對 React Native 專案的否定，也不是「跨平臺框架不行了」的證明。變化發生在另一個地方：寫程式這件事本身變了。

Coding Agents 動了哪一塊成本

React Native 在 2020 年解決的核心痛點，是「重複勞動」。Swift 已完成的功能，Android 要用 Kotlin 重寫；反過來也是。跨平臺框架用一套程式碼把這份重複直接消掉，代價是引入橋接層、平臺差異處理，以及對框架本身更新節奏的依賴。

到 2026 年，Coding Agents 進入了 Shopify 的內部開發流程。根據 Shopify 的說明，AI 可以讀取一個平臺已有的實作，把它當作上下文，輔助完成另一個平臺的對應開發。iOS 端寫好的功能，AI 參照著產出 Android 端的 Kotlin 版本；測試、程式碼審查、遷移等環節，AI 也開始參與。

用回中央廚房的比喻：過去兩間廚房要各自養廚師，所以合併成一間；現在有了一位能看著 A 庚食譜、快速抄出 B 庚版本的助手，兩間廚房分開經營的成本大幅下降，而合併廚房本身帶來的麻煩（菜色得遷就兩地口味、設備規格被迫統一）反而變成顯性支出。

跨平臺框架省下的人力，與原生開發多出的重複工時，這兩個數字之間的天平，被 AI 撥動了。當重複實作的邊際成本下降，React Native 帶來的共用效益就跟著縮水，而它的框架稅（效能損耗、升級相依、疑難雜症得等社羣或 Meta 處理）並沒有消失。

驗證的不是「AI 會寫程式」，是整條流程

Shopify 這次並非直接下注。團隊先以 PoC 驗證新的開發方式，而且驗證範圍超出「AI 能不能生成 Swift 或 Kotlin 程式碼」這個層次。生成之後的程式要能跑測試、要驗證 UI、要走 Code Review，最終由工程師確認。

這個順序值得做技術決策的人細看。很多團隊評估 AI 輔助開發時，停在「demo 能跑」就下結論。但真正決定可不可用的，是 AI 產出的程式碼進入既有工程體系後，測試、審查、維護這些下遊環節的成本有沒有一起降下來。Shopify 的 PoC 把整條流程納入驗證，等於是在問：如果 AI 生成的程式碼仍要人工逐一檢查、審查時間不減反增，那這條路就不成立。

驗證通過後，Shopify 才開始把開發方式往原生方向調整。這是一個「先改工具，再改路線」的順序，而不是先有結論再找理由。

技術選型沒有終身制

對一般開發者與技術主管，這件事最有用的啟示不在「該選 React Native 還是原生」，而在於：技術選型的前提條件是有儲存期限的。

2020 年選 React Native，是在「兩套原生程式碼的人力成本高」這個前提下做的理性決策。2026 年回原生，是在「AI 能大幅壓低跨平臺重複實作成本」這個新前提下做的另一個理性決策。兩者都對，只是世界變了。把任何一項技術選型當成一次到位、終身有效的答案，風險比選錯技術本身更大。

實務上可以從幾個方向檢視自己的處境。團隊目前的跨平臺方案，省下的工時主要落在哪一段？如果集中在「重複實作同一功能」，這正是 Coding Agents 最能壓縮的區間，值得做個小規模實驗量測前後差異。如果省下的是更深層的東西，例如單一技術棧帶來的招募與知識管理效益，那 AI 的影響就相對有限。

另外，Shopify 的規模也值得納入考量。它的行動端功能量大、迭代快，雙平臺重複工作的絕對成本高，AI 帶來的節省才足以改變天平。小型團隊或單一平臺的產品，套用同樣結論前，先算清楚自己的分母。

給技術決策者的三個觀察點

第一，看工具鏈的滲透率。AI 輔助開發在團隊內是真實進入測試與審查流程，還是只停留在補全程式碼的層次，會直接決定原生路線的成本結構是否真的變了。

第二，看框架稅的變化。React Native、Flutter 這類方案並不會因此退場，它們在快速原型、小團隊、非效能敏感場景的優勢仍在。但大型平臺重新計算效益後，跨平臺框架需要回答的問題會變多。

第三，看接下來一年其他大型應用團隊的動向。Shopify 是較早把「因為 AI 所以回原生」講清楚的團隊，如果陸續有規模相近的公司跟進，這就會從個案變成趨勢；如果沒有，那 Shopify 的經驗就屬於特定規模與業務型態下的特解。

六年前那份宣言的標題，和六年後這份的標題，只差了幾個字，中間隔著的是一次開發方式的換軌。對讀者來說，與其記住「哪家公司選了什麼」，不如記住這件事的結構：當生產工具的效率出現數量級變化，所有建立在舊成本結構上的選擇，都值得重新算一遍。