發生了什麼：一則六年的回頭宣布
Shopify 工程團隊在官方部落格的新文章〈Native is now the future of mobile at Shopify〉中宣布：旗下的行動 App 將從 React Native 遷回 Swift 與 Kotlin 原生開發。文章副標把理由寫得毫不迂迴：「Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.」
這段官方說明翻成白話就是：編碼智能體改變了「把行動 App 做兩遍」的成本，所以 Shopify 回到原生。值得注意的是，官方把這次轉向的驅動力明確歸給 coding agents——能讀懂整個程式碼庫、自主規劃並動手修改程式碼的編碼智能體——而不是 React Native 的效能或品質出了什麼新問題。換句話說，被改變的不是工具的好壞，而是「划算與否」這本帳本身的算法。
這則宣布的份量，來自當事人的身分。Shopify 是 React Native 陣營最具知名度的大型企業採用者：2020 年它公開宣示所有新行動 App 都改用 React Native，之後花了好幾年把旗下最大的 App 遷移過去，如今同一個官方部落格宣布走回頭路。來回一趟，正好六年。
2020 年的那筆帳：React Native 當時解決什麼問題
要理解這次回頭，得先回到 2020 年，看當年那筆帳是怎麼算的。原始宣布的措辭同樣斬釘截鐵：「After years of native mobile development, we’ve decided to go full steam ahead building all of our new mobile apps using React Native.」這段原始宣布說的是：在多年原生開發之後，全速前進，所有新的行動 App 都用 React Native 打造。
跨平台框架解決的核心痛點是「重複」：同一個功能，iOS 用 Swift 寫一遍，Android 得用 Kotlin 再寫一遍，商業邏輯相同、工程成本翻倍。React Native 讓團隊用同一份 JavaScript 程式碼同時產出兩個平台的 App，還能把公司裡為數眾多的網頁開發人力直接投入行動開發。Shopify 在五年回顧文章中仍然肯定這層人才槓桿，文中寫道網頁開發者用 React Native 開始做行動開發，比直接投入原生 iOS 與 Android 容易得多。
在遷移路上，這條路線也曾被官方記錄為進行中的工程。遷移實錄的開頭描述了當時的具體狀態：「Today, the main tab-based navigation screen in Shopify Mobile is written in Kotlin and Swift」——當時 Shopify Mobile 的主標籤導覽畫面，仍是原生的 Kotlin 與 Swift，團隊的策略是把一個個領域逐步搬進 React Native。也就是說，六年後的回頭，不是一場失敗工程的退場，而是一筆在兩個時間點都算得清楚、但答案不同的帳。
機制：coding agents 把「寫兩次」的代價壓下來
官方副標裡最關鍵的一個詞是「costs」——成本。這句話背後的經濟學值得攤開來看。
跨平台框架的價值主張，本質上是一種成本交換：付出「抽象層的稅」——橋接層的維護、框架大版本的升級、與原生生態系之間的各種落差——換取「不必把每個功能寫兩次」的節省。在工程師人力昂貴、重複實作成本高的年代，這筆交換很划算。
coding agents 改變了等式的兩邊。一方面，重複實作的邊際成本大幅下降：同一份規格，讓智能體在 Swift 與 Kotlin 各完成一次，成本遠低於過去全由工程師手寫；另一方面，抽象層的稅並沒有消失，框架演進與原生模組的維護仍是固定支出。當「寫兩次」不再昂貴，跨平台換來的節省就跟著縮水，而原生開發的既有優勢——完整的作業系統能力、第一時間採用新 API、少一層抽象的除錯負擔——相對變大。這正是官方文章標題「Native is now the future」的邏輯：不是 React Native 變差了，而是原生的相對成本被 AI 壓低了。
值得留意的是，這個現象並不只發生在框架選擇。先前的程式語言與 coding agent 實測就發現，模型在不同語言上的表現，與該語言生態的資源多寡相關。當 AI 成為寫程式的主要產能，工程決策的權重自然會從「人的效率」移向「模型的效率」——而模型對主流語言與原生路徑的掌握，通常更有利。
開源足跡：降溫早有跡象，但不是全面撤退
回頭看，Shopify 對 React Native 的投入降溫並非一朝一夕。在 GitHub 上，Shopify 維護的 React Native 效能監控套件 react-native-performance 已經封存並宣告不再維護：儲存庫在 2025 年 11 月 26 日轉為唯讀，README 明確寫著「@shopify/react-native-performance is no longer maintained」，套件被標記為 deprecated。
不過，把單一儲存庫的封存解讀成「Shopify 全面撤出 React Native 生態」並不準確。同一個 GitHub 組織下的繪圖庫 react-native-skia 仍公開在線上，持續有議題與版本活動。比較合理的解讀是：與自家 App 直接相關的基礎設施率先收斂，而通用型、被外界廣泛依賴的開源專案，走向還需要時間觀察。對讀者來說，這也提醒我們：一座倉庫的封存是訊號，不是判決。
影響：跨平台框架的招牌示範轉向原生
對產業而言，這則宣布的重量在於示範效應。過去幾年，「大型企業能不能把核心 App 押在 React Native 上」這個問題的答案，很大程度上就是 Shopify 本身：它公開分享遷移經驗、開源大量基礎設施、在技術社群現身說法。這個招牌案例轉向原生，對正在評估技術棧的團隊來說，等於參考點移動了。
對開發者與企業，實際的下一步可以更具體。已經在 React Native 上的產品不需要恐慌——這種規模的遷移本身就是多年工程，期間 App 照常運作與迭代；正在選型的團隊，則值得把「coding agents 的滲透程度」正式納入評估：你們的智能體工作流是否成熟到能穩定維護兩份原生程式碼？團隊人才結構是網頁還是行動為主？這些問題的答案，比追隨任何一家公司的選擇都重要。
給技術決策者的三個問題
把 Shopify 的論證轉成自己團隊可用的檢查表，至少有三個問題值得誠實回答。
第一，重複成本的真實數字是多少？統計過去一季的雙平台功能開發量，如果智能體工作流已經能讓兩份原生實作的成本貼近一份跨平台實作，跨平台的原始動機就弱了一大半。
第二，抽象層的稅付了多少？框架升級、原生模組橋接、效能排查——這些工時若已佔團隊固定支出的大宗，那麼跨平台其實是在同時付兩種成本：重複的稅與抽象的稅。
第三，人才與智能體的槓桿在哪一邊？2020 年 Shopify 的前提是公司裡有大量網頁開發人力可以槓桿；如果你的團隊已主要由智能體產出程式碼、人員專注在審查與設計，那麼「人的語言熟悉度」這項跨平台優勢的分量，也會跟著下降。
限制與後續觀察
最後必須畫出這則報導的邊界。官方文章公開的資訊仍然有限：宣布本身與理由論述是真實可查的，但遷移的範圍與時程、是否涵蓋所有行動 App、既有 React Native 程式碼如何處置，目前都沒有公開細節，不宜推測。
其次，這是單一大型企業在特定條件下的決策。Shopify 的規模、智能體工具鏈的成熟度、原生與網頁人力的比例，都不是多數團隊的處境；把結論直接外推到小型團隊或新創並不安全。而 coding agent 降低重複成本的實際幅度，會隨程式碼庫的性質、領域與測試涵蓋率而異，目前也沒有跨公司的量化數據可以引用。
值得追蹤的指標至少有三個：Shopify 後續公布的遷移節奏與範圍；react-native-skia 等其餘 Shopify React Native 開源專案的維護狀態；以及其他大型採用者、乃至 React Native 母公司 Meta，如何回應這本被 AI 改寫的成本帳。
