Expo SDK 56 + New Architecture 升級實戰：Fabric / TurboModules / Hermes V1 七步無痛遷移

83%。 這是截至 2026 年 1 月，所有用 EAS Build 出貨的 Expo SDK 54 專案啟用 New Architecture 的比例。換句話說，剩下 17% 還在用 legacy bridge——而從 SDK 55 開始，這 17% 已經沒有後退鍵了。

Expo SDK 55 把 newArchEnabled: false 這個 escape hatch 整個拿掉，SDK 56（2026 年 6 月剛釋出）更進一步重寫了 iOS 原生模組的 Objective-C++ 中介層，全部改走 Swift / C++ interop。意思是：你如果還在 Expo SDK 53 以下 / React Native 0.74 以下，升級的問題已經從『要不要做』變成『什麼時候做、怎麼做才不爆』——這是工程取捨題，已經不是決策題。

這篇是我們整理出來的 7 步無痛遷移 SOP，從 Hermes V1 切換、Fabric 啟用、TurboModules 自動轉換到實測效能改善，附對應指令、踩坑清單與量測數字。最後一段是『我們的取捨』——如果你是 tech lead，這段是你要拿去跟工程團隊對齊的對話材料。

升級拖了一年的 5 個真實理由

我們訪談過幾位實際在維護 RN production app 的工程師（以及自己內部討論過），歸納出『遲遲不升 New Arch』的真實原因——沒有一個是技術不夠強，全部是工程取捨。

1. 『升級沒有立即業務價值』：performance gain 是漸進的，產品經理看不到立即 KPI，排序永遠在 feature 後面。
2. 『怕第三方套件還沒準備好』：擔心 react-native-svg / lottie / reanimated 等熱門套件還沒升 New Arch 對應版本。
3. 『升完要重測 QA』：怕業務驗收 + QA regression 要 2-4 週。
4. 『沒人 own 這條 migration』：工程團隊沒人專責跟著 React Native release，新版本永遠是『下個 sprint 再說』。
5. 『以前升過 Hermes 翻車過』：SDK 48 或 49 時代某些套件對 Hermes 不穩定的記憶還在。

這五個理由都合理。但 2026 年 6 月的現實是：上面五件事的『風險』已經比 2024 年低 5-10 倍。 第三方套件的 New Arch 相容性截至 SDK 56 已經接近 100%；Hermes V1 在 SDK 56 變成預設引擎；EAS Build / Update 把『回滾』變得幾乎免成本——你升完發現有問題，OTA 灰度發布一個指令就能把流量 100% 切回舊版（這部分我們在 EAS Build + EAS Update 上架實戰 講得更細）。

先搞懂三個元件：JSI、Fabric、TurboModules 到底各做什麼

升級之前一定要先理解 New Architecture 把什麼換掉了——不然 debug 的時候你會在錯誤訊息裡看到陌生的字眼還以為是 random bug。

重點是這幾個元件是『一組』而不是『可以挑著用』。從 React Native 0.76 / Expo SDK 52 開始，打開 New Architecture 就是打開全部 5 個——你不能只啟用 Fabric 不啟用 TurboModules。這是 New Arch 的設計取向。

Hermes V1 跟前一代 Hermes 差在哪

Hermes 從一開始（2019 年）就是 Meta 為 React Native 寫的輕量 JS 引擎，目標是『開機快、佔記憶體少』。Hermes V1 是 2026 年初的新版本，主要差異在：

• Static Hermes：實驗性的 AOT 編譯模式，把 TypeScript 直接編成 native binary，性能跟 native 接近（目前還是 opt-in，但未來會變預設）。
• 更穩的 GC：garbage collector 換新演算法，記憶體峰值平均降 15-20%。
• 更好的 source map：生產環境 crash 報告 stack trace 更精準，debug 不再卡在 minified function name。

出處：Hermes V1 release notes（Meta 官方） 與 React Native New Architecture 文件。

七步無痛升級 SOP（含對應指令）

下面 7 步是我們建議的順序，前 3 步是『準備』，後 4 步是『執行』。整個流程在小專案（10 萬行 JS 以下）大約 4-8 小時，大專案可能 2-3 天。

Step 1：盤點目前所有第三方 native 套件

# 列出所有 react-native 開頭的 dependencies
cat package.json | grep -E '"react-native|expo-' | sort

拿到清單後，去 Directory of React Native libraries（社群官方索引） 一個一個查 New Arch 相容性。每個套件頁面右側會標 New Architecture: Supported / Untested / Unsupported。

Unsupported 的套件就是你升級的 blocker。 處理方式：1) 找替代套件、2) 升到該套件的最新版（多半已經支援）、3) 自己 fork patch（最後選項）。

Step 2：升 Expo SDK 到目標版本

# 升到 SDK 56（New Arch 預設）
npx expo install expo@^56.0.0
npx expo install --fix

--fix 旗標會把所有 expo 相關套件升到跟新 SDK 相容的版本，是 SDK migration 的核心指令。建議跑完之後 commit 一版，方便對照 diff。

Step 3：開 New Architecture 開關

// app.json
{
  "expo": {
    "newArchEnabled": true,
    "jsEngine": "hermes"
  }
}

SDK 55+ 預設已經是 newArchEnabled: true，可以不寫；但寫出來明確一點，未來工程師看到不用懷疑。jsEngine 預設是 hermes，可以省略，但絕對不要切回 jsc——SDK 56 已經停止支援 JSC。

Step 4：跑一次完整 build，確認沒有 build-time error

# Android
npx eas build --platform android --profile development

# iOS
npx eas build --platform ios --profile development

這一步通常會抓出『某個第三方套件沒有 New Arch binding』類型的 build error。錯誤訊息會明確指到套件名稱，照 Step 1 的 plan 處理。

Step 5：跑完整 QA / 自動化測試

New Arch 的問題 90% 出在 runtime 行為差異，build error 只佔少數。 常見的有：1) UI 更新時序不同（同步 vs 異步 render）、2) 某些動畫 lib 在 Fabric 下行為改變、3) 自訂 native module 的 thread safety 假設失效。

我們的做法是：把這個 build 當『QA 階段』放到 internal distribution，讓 PM 跟 QA 工程師完整跑一遍 critical path（登入、付款、推播、deep link、最常用的 5 個 feature）。

Step 6：跑效能 benchmark

升級的價值要量化，不然下次升 SDK 還是會被擋。我們建議至少量測：

• 冷啟動時間（cold start）：從 launch 到首屏 interactive 的時間，用 Xcode Instruments / Android Studio Profiler。
• List 滾動 FPS：主要長 list 滾動時的 FPS，目標 60。
• Bundle size：AAB / IPA 體積對比升級前後。
• Memory peak：熱門路徑的記憶體峰值。

根據 Expo SDK 56 changelog 官方數據，Android 冷啟動快 40%、iOS build time 快 50%+。實際數字會因 app 而異，但量級差不多。

Step 7：用 EAS Update staged rollout 上 production

升級完的 JS bundle 用 EAS Update 灰度發布——5% → 25% → 50% → 100%，每個階段觀察 24-48 小時的 crash rate（用 Sentry 或 Bugsnag 之類監控工具）。任何階段 crash rate 比舊版本高超過 20%，立刻把 channel 回切舊 branch。

詳細流程在 EAS Build + EAS Update 上架實戰。

自己升 vs 外包升：兩條路的真實成本對比

前面 7 步聽起來不難，但實作上常常卡在『沒人 own』。如果你是中小企業老闆或產品負責人，問題會回到一個簡單的選擇：要工程團隊自己排優先序升、還是找外部團隊集中升完交回。

我們的觀察是：『升完之後沒人懂』是外包最常見的隱性成本。 所以如果走外包路線，合約一定要包含『升完之後 1 場 2-4 小時的 walkthrough』，讓內部工程師知道每一個變動點，下次自己升就有方向。

升級前 vs 升級後的可量化差異（SDK 53 → SDK 56）

下面這些數字來自 Expo 官方 changelog 與 Expo SDK 56 升級指南，再加上我們對照幾位 RN 社群工程師的實測——並非每個 app 都會看到完全一樣的數字，但量級會非常接近。

可量化的不只是效能。還有一塊隱性收益是『不再被舊架構卡開發效率』——你會驚訝有多少『RN 怪 bug』其實是 legacy bridge 的時序問題，升完之後它們會默默消失。

如果這次升級你不想自己一個人扛

Expo SDK 跨版升級是少數『做對了沒人會稱讚，做錯了會被質疑為什麼壞掉』的工程事——但它對 app 體質的影響其實很大。如果你的團隊缺一個有經驗的人帶一次完整 migration、或者想評估『要自己升還是外包』，我們很樂意 聽你聊聊現況。我們會直接告訴你『這個值得做嗎、自己做大概要多久、外包大概多少預算』，這個階段我們陪你一起想，後面真的要動手再談範圍跟費用。

如果你還在更前一步——還沒決定要不要用 Expo，可以先看 Expo Go 撞牆了怎麼辦？4 個訊號告訴你該轉 Development Build 跟 EAS Build + EAS Update 上架實戰，三篇一起讀比較有完整圖像。