TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Shopify 棄用 React Native，AI 代理 12 週重寫 Shop App
Shopify 宣布結束六年的 React Native 路線，行動端全面返回 Swift 與 Kotlin 原生：AI 編碼代理壓低了雙平台各寫一套的成本，旗艦 Shop App 由 6 名核心工程師用 12 週重寫上架，Android 冷啟動砍半、當機工作階段約減為十分之一，FlashList 與 React Native Skia 進入交接期。
用 AI 摘要這篇文章：
9 月 10 日，Shopify 的工程部落格一次刊出兩篇長文：一篇宣布立場《Native is now the future of mobile at Shopify》，另一篇記錄實作《Migrating Shop app from React Native to native》。訊息很直接，六年多前全面押注的 React Native 路線畫下句點，旗下 App 將陸續回到 Swift 與 Kotlin 的原生開發。打頭陣的 Shop App 已經完成，從概念驗證到雙平台上架只花了 12 週。
這則新聞很容易被讀成「跨平台框架輸了」，但官方把理由寫得很節制：React Native 沒有變慢，也沒有失靈，變的是 AI 編碼代理把「同一個功能要寫兩次」的成本壓低了。當重複實作不再昂貴，跨平台框架當年用來換掉這筆帳的理由，就跟著變薄。
這件事值得細看的地方在於，它是大型公司親自刊出的「寫兩次成本重估」實錄：決策怎麼發生、12 週遷移怎麼壓出來、防範 AI 亂寫的工程長什麼樣、FlashList 這類被全球 App 依賴的開源庫接下來何去何從，兩篇文章都給了第一手細節。
一月才說前景光明，九月宣布返回原生
時間軸先看清楚。2020 年 Shopify 決定全面改用 React Native，理由有三：同一套功能不必在 iOS 與 Android 各寫一遍、讓沒有行動開發背景的工程師也能參與 App 開發、把追趕雙平台功能對齊的力氣省下來。官方形容這場押注「極為成功」，六年多來也確實把 FlashList、React Native Skia 這些庫回饋給了整個生態。
2025 年 1 月 13 日，工程總監 Mustafa Ali 還發表過一篇《Five years of React Native at Shopify》，結論是「React Native 的前景光明」，並承諾採用新架構（New Architecture）、重啟 React Native 工作小組。20 個月後，同一人在 9 月 10 日的文章裡宣布返回原生。官方對這段反轉的解釋不是框架出問題，而是「編碼模型已大幅進步」，核心假設變了，就回到第一性原理重算一次。
轉折點藏在 Shop App 的下一筆大投資。遷移實錄寫明：升級 React Native 新架構需要重新處理原生模組整合、渲染層，以及共用程式碼與平台特定程式碼的邊界。在承諾這筆投資之前，團隊決定先做另一個實驗：測試編碼代理能不能直接用 SwiftUI 與 Jetpack Compose 開發，同時讓雙平台行為保持一致。實驗結果改寫了決策。
鋪陳要往前拉：Shopify 並不是這一兩年才開始用 AI 寫程式。官方文章寫到，他們從 2021 年就用 LLM 協助開發，比 ChatGPT 問世還早一年，一開始拿來實作功能、調查與修正臭蟲、審查程式碼，隨著模型進步，交辦工作的複雜度也一路提高。到 2025 年下半年，原型實驗得出三件事：代理能以 iOS 版為參考直接在 Android 上實作，反向也行；能幫工程師在自己不熟悉的技術棧快速上手；透過共享規格、測試與檢查點，雙平台維持一致的維護成本大幅下降。當「寫兩次」不再等於「做兩次工」，天平就傾斜了。
官方對 React Native 的評價裡，最該抄下來的是這一句：「React Native 的 App 可以很快，我們的就是。」文章明說這次轉向，是因為代理削弱了共享實作的優勢，而原生開發貼近平台能力與第一方工具的優勢一直都在。這是一筆成本帳的重算，不是對框架的判決書。
一人一週的概念驗證，六人核心的 12 週衝刺
遷移不是從大軍團開始的。起點是一名工程師花一週，帶著編碼代理把既有 React Native App 盡可能移植成 SwiftUI 版本。結果離上架水準還遠，但足以證明貼近原功能的遷移做得到。官方特別點出代理的強項：有現成實作可以參考時，它們擅長移植既有功能、搭畫面骨架、串資料、實作動畫，並依視覺回饋調整版面。
另一個關鍵選擇是砍掉重練。2020 年遷入 React Native 時，Shopify 部分大型 App 走的是漸進路線，在原生殼裡逐頁替換；當時的盤算是，砍掉重練得花上好幾年，期間新功能也會停下來。這次團隊反其道而行，直接選擇全新重寫，把既有 React Native 版當成活的規格書，讓代理對照著重蓋：一方面代理本來就擅長照著參考實作，另一方面也趁機甩掉歷史包袱，用當下最好的做法重建。
正式遷移由 6 名核心工程師打造原生地基與主要使用者流程，各功能團隊在中途加入，驗證自己負責的區塊與邊界情況。Shop App 在官方描述中服務「數億消費者與數百萬商家」，這種規模的 App 換引擎，最怕的環節是無感升級的三條底線失守：使用者更新後不能被登出、推播通知不能斷、行為事件要照常拋出，因為下游系統靠這些事件運作，官方舉推薦系統為例。團隊也趁重寫做了斷捨離，刻意下架部分畫面、簡化另外一些。12 週後，新版通過 App Store 與 Google Play 審核上架。
成績單：啟動與穩定度大幅改善，iOS 體積沒有變小
官方比對了新舊版本，涵蓋啟動時間、工作階段穩定度、安裝檔體積、建置時間與渲染效能五個維度，量測口徑也寫得清楚：冷啟動從「點一下圖示」算到「首頁內容可見」為止。下表數字全部來自 Shopify 官方文章刊載值，未經第三方複核：
| 指標 | React Native 版 | 原生版 | 差異 |
|---|---|---|---|
| Android 冷啟動 | 4,433 ms | 2,233 ms | 縮短 50% |
| iOS 冷啟動 | 3,200 ms | 2,466 ms | 縮短 23% |
| 工作階段穩定度 | 99.5%+ | 99.95%+ | 當機工作階段約減為十分之一 |
| Android 安裝檔體積 | 293 MB | 184 MB | 減少 109 MB |
| iOS 安裝檔體積 | 67 MB | 68 MB | 增加 1 MB |
| Android release 建置時間 | 基準值 | 約縮短 75% | 省下測試與算力時間 |
| iOS release 建置時間 | 基準值 | 大致相同 | 無明顯變化 |
有幾個數字需要特別留意。Android 安裝檔縮了 109 MB（約 37.2%），但 iOS 反而多了 1 MB，兩端並不同步。工作階段穩定度從 99.5%+ 升到 99.95%+，官方換算成「當機的工作階段約減為十分之一」。畫面流暢度上，官方影片顯示原生版在 Pixel 裝置捲動商品訊息流時達到 120 FPS，並特別註明幾乎還沒做什麼優化，後續還有上調空間。
真正的主角是讓代理沒辦法亂寫的工程
把整個 React Native 專案丟給模型，叫它一次轉成 Swift，會發生什麼事？官方給的答案很直白：行不通，最後會得到一大堆無法維護、上不了線的程式碼。12 週衝刺能成立，靠的是背後一整套自建工程，而這部分對其他團隊的參考價值，比「換回原生」這個結論高得多。
Helix 是為這波返回原生遷移打造的檢查點系統。開發者指著一個畫面，Helix 讀完 React Native 原始碼後，提出一串小切片的檢查點，每個都能在幾分鐘內審完。每個檢查點要過四關：用測試證明行為、在視覺比對中與現行 App 一致、通過兩個專門挑毛病的對抗式審查代理、最後由人類點頭才能往下一個走。每次審查的回饋都會被記住，遷移愈到後面，這個迴圈愈能自主運作。
另一個瓶頸是驗證速度。代理改程式碼只要幾秒，在模擬器上驗證結果卻要花好幾分鐘，官方形容工程師簡直在當模擬器保母。解法是把商業邏輯與 UI 完全解耦，讓邏輯能在桌面端以無頭方式執行，代理透過 CLI 在毫秒級迭代，不必開模擬器；真正需要操作畫面時，CLI 再以遙控模式驅動模擬器。官方稱代理因此能連續自主工作數小時。
新舊版對帳則交給 Tardis。這套除錯工具讓代理結構化地讀取執行中 App 的事件、日誌與內部狀態，還能對 App 下指令。做前後對照時，它在指定檢查點同時擷取新舊兩版的截圖與事件流，比對事件名稱、數量與欄位內容，並自動容許時間戳記、頁面 UUID 這類本來就會不同的值。整套遷移流程另被封裝成 Pi 編碼代理的擴充模組，子代理各司其職：讀原始碼、記錄行為、準備平台計畫、實作功能、審查一致性；計畫的驗收與內容雜湊綁定，一旦改過計畫，先前的驗收就失效，避免審查與實作脫鉤。想把「讓 AI 照計畫施工」的流程搬到自己專案，市面上也有 VibeDoc 這類把想法變成開發方案的工具可以當起點。
即便有這些防護，官方仍寫得很明白：原生專業不可省。生成的程式碼可能滿足功能需求，同時引入重複、架構漂移或效能問題，最後還是靠程式碼審查、靜態分析、測試與效能檢查把關。
FlashList、React Native Skia、Restyle 的三種結局
Shopify 過去六年也是 React Native 生態的重要出資者，這次撤守對開源庫的影響，比 App 本身更貼近一般開發者。官方文章逐一交代了三套庫的安排：
- React Native Skia（高效能 2D 繪圖庫）：Shopify 贊助到 2026 年底，核心維護者 William Candillon 之後會 fork 儲存庫，以新名稱繼續發行，原儲存庫在過渡完成後封存。
- FlashList（高效能列表庫）：官方文章稱每週約 200 萬次下載，是 React Native 高效能列表的主流選擇。Shopify 會繼續修會破壞相容性的重大問題，長期託管正在與多家公司洽談。照 npm 的下載統計，最近一週（9 月 3 日至 9 日）實際下載約 108 萬次，與官方文章寫的「約 200 萬」有段差距，兩個數字並列在這裡，可以自行加權。
- Restyle（樣式庫）：使用者較少，確定走向封存，維持運作到 2026 年底為止，歡迎社群 fork 接手。
截至 9 月 11 日，三個 GitHub 儲存庫都還沒有被封存，Restyle 的最後一次更新停在 2026 年 2 月。如果你的 App 依賴這三套庫，2026 年底是最實際的檢查點：Skia 要留意新名稱的接續、FlashList 要盯託管最後落誰家、Restyle 則要提早準備自己的分支。
該跟嗎：先抄驗證架構，別急著抄結論
Shopify 的下一步，是把旗下最大的 Shopify App（300 多個畫面，加上桌面與鎖定畫面小工具、Apple Watch App、Siri 捷徑）遷往原生，官方稱今年內出貨，Point of Sale 與 Inbox 隨後跟上。衡量成功的指標也一併公開：產品交付速度、App 品質，以及代理能自主完成的工作量。
對多數台灣團隊來說，這則新聞真正可搬走的部分，與其說是語言選擇，不如說是驗證架構。Shopify 能讓 6 個人用 12 週重寫億級使用者的 App，前提是先建好了檢查點驗收、可無頭執行的商業邏輯、事件對帳這些讓代理自我驗證的基礎建設。如果你的專案連自動化測試都不齊，直接把雙平台重寫丟給一般的對話式 AI，比較可能得到官方文章警告的那種無法維護的程式碼。在新創驗證階段，React Native 或 Flutter 的快速出貨價值，並沒有被這則新聞否定。
文章也談了人的這一側：React Native 工程師轉換到 SwiftUI 與 Jetpack Compose 的學習曲線比預期平緩，宣告式 UI 的概念在兩邊相通，平台知識則由原生成員把關架構決策與審查。文章結尾同時開出行動工程師、基礎建設工程師與 AI 跟軟體工程交集角色的職缺，看得出重寫只是第一步，後面是一條長期路線。
比較務實的起點有兩個：把商業邏輯從 UI 抽出來，讓核心流程能在沒有介面的環境跑測試；再為關鍵路徑補上行為或事件的對帳方式。這兩件事無論你用什麼框架都成立，也是代理時代真正保值的那層資產。想在原生側補基本功，Swift 與 Kotlin 的語法對比可以從既有的程式語言對比資源入門；想先感受 AI 把口語想法變成 SwiftUI 原型的流程，也有 Ironsmith 這類開源工具可以直接裝來玩。
