若你習慣用 VPS 思維管算力，卻在 React Native／Expo 上被「EAS 佇列、原生模組、憑證形態」卡住，本文把託管建置與獨佔 macOS 平面放進同一張對照表：先拆痛點，再給決策矩陣與六步落地清單，最後落到可稽核的自託管節奏。讀完你會清楚何時應繼續用 EAS、何時該把 iOS 建置遷到像買節點一樣租來的遠端 Mac上。
Expo Application Services（EAS）把憑證、上傳與雲端建置封裝得很好，適合標準路徑。但當你的儲存庫出現大量原生修補、私有 Pod、或要把建置日誌與命令稽核寫進合規包時，託管池的黑箱排隊與映像邊界會變成阻力。下面六條來自實際除錯會議的歸納，用來判斷你是否需要第二套「可 SSH 的建置平面」。
佇列語意不透明：尖峰時段同一工作流可能在佇列中等待數十分鐘；若發佈窗口被業務方鎖死，這種不確定性會直接轉成上線事故風險。託管池無法像獨佔機那樣把「最大併發」寫進內部 SLA。
原生依賴鏈路過長：react-native-config、Firebase、地圖與藍牙等模組一旦需要自訂 Podspec 或預編譯腳本，映像快取命中下降，單次建置時間波動大；除錯時你拿不到主機層 shell 去對照 xcodebuild -showBuildSettings 的完整輸出。
憑證與簽名模型分裂：團隊若同時使用 EAS 託管簽名與內部 match／自建 CA，容易出現「本機 Archive 成功、雲上偶發失敗」的雙軌漂移；根因往往是鑰匙圈脈絡與 CODE_SIGN_IDENTITY 組合在託管映像裡無法完全複刻。
磁碟與 DerivedData 水位不可控：大型 monorepo 在託管機上更容易觸發清理策略，導致快取熱層被沖掉；對需要反覆跑 UI 測試與 Archive 的團隊，這代表不可預期的長尾耗時。
與既有 CI 標籤體系割裂：你已經為後端與 Web 在 GitHub Actions 裡定義了 labels、併發上限與自託管 Runner，卻把 iOS 單獨託管在另一套編排裡──維運心智被硬性拆成兩半，排班與 on-call 成本上升。
稽核欄位不足：金融、醫療或合規出海常要求「誰、在什麼 IP、對哪臺建置機執行了哪些指令」；若託管側無法匯出與內部 SOC2 對齊的原始 SSH／工作階段日誌，你就需要用獨佔節點補齊證據鏈。
若你命中其中 兩條以上，建議繼續讀對比表與落地步驟；若僅偶爾建置、原生疊很薄，可優先把 EAS 用滿，不必過早自建平面。更多「如何把 Runner 接到獨佔機」的細節，可參考站內 GitHub Actions 自託管 Runner 專題，本文專注 RN／Expo 語境下的邊界劃分。
把兩套方案放在同一張表上，不是為了否定 EAS，而是讓評審會用統一語言討論「佇列、映像、簽名、稽核」四件事。下表預設你的團隊已能熟練使用 eas.json 設定檔，並具備基礎 macOS 維運能力。
| 維度 | EAS Build（託管） | 獨佔遠端 Mac 自託管 |
|---|---|---|
| 交付速度（冷啟動） | 高，省去機器採購與系統安裝 | 中，需一次性完成 SSH、Ruby／Node 指紋與 Runner 註冊 |
| 佇列與併發可控性 | 受平臺池化影響，尖峰不可預測 | 獨佔 CPU／磁碟，可寫死併發上限與清理窗口 |
| 原生疊複雜度 | 適合標準 Expo 託管工作流 | 適合深原生、自訂 Pod、預編譯腳本與本機修補鏈 |
| 簽名與憑證策略 | 與 EAS 託管憑證深度整合 | 可與 match、自建 KMS、分環境鑰匙圈完全對齊 |
| 日誌與稽核 | 以平臺日誌為主，顆粒度受產品限制 | 可蒐集完整 xcodebuild 與 shell 工作階段，滿足內稽 |
| 維運心智 | 低，偏「服務化 CI」 | 中高，接近「像管 VPS 叢集」 |
「託管建置解決從 0 到 1；獨佔節點解決從 1 到 N 的可預期性與可稽核性。」
落地時常見折中是：日常組建與 PR 仍走 EAS，把 Release Archive、UI 測試矩陣、以及需要反覆試錯的 native 迭代遷到獨佔遠端 Mac。這樣可以把最貴的「人天」壓在可控環境裡，同時保留託管側的整合便利。
下面矩陣依「團隊規模 × 原生深度 × 合規強度」給出可操作結論。它不是要取代你們的容量規劃表，而是協助在架構評審裡快速對齊優先順序。
| 訊號 | 繼續以 EAS 為主 | 導入獨佔遠端 Mac |
|---|---|---|
| 原生依賴 | 僅少量社群模組，無自訂 Pod | 有私有 Pod、二進位閉源 SDK、或需要自訂編譯旗標 |
| 發佈節奏 | 週更／雙週更，可容忍佇列波動 | 日更或強時間盒發佈，需要寫死併發與窗口 |
| 合規 | 無強稽核欄位要求 | 需要 SSH／指令層稽核、固定出口或隔離 VPC |
| 既有 CI | iOS 與後端流水線完全解耦 | 希望 iOS Job 與 GitHub Actions／GitLab 共用 labels 與快取策略 |
// eas.json 片段：用 profile 把「託管建置」與「外置自託管 Job」分流
{
"build": {
"preview": { "distribution": "internal", "channel": "preview" },
"release-selfhosted": {
"extends": "production",
"env": { "EXPO_USE_FAST_RESOLVER": "1" },
"ios": { "image": "latest" }
}
},
"submit": { "production": {} }
}
注意：一旦你在同一分支混用託管與自託管，務必在 README 裡寫清「哪條 profile 會觸發哪套憑證」，否則新同事會在鑰匙圈與 EXPO_TOKEN 之間反覆踩坑。
矩陣之外還有一條硬經驗：不要把「能跑」當成「可重現」。託管映像升級往往於背景進行，若你沒有在儲存庫裡釘死 Xcode 與 Node 小版號，RN 原生側會在一次無感升級後集體轉紅。獨佔節點的優勢是可以像鎖核心版本一樣鎖 xcode-select 與 Ruby Bundler，並把指紋寫進 CI 合約。
以下步驟假設你已能本機 npx expo prebuild 產生 iOS 專案，並需要在獨佔機上跑 xcodebuild 或 Fastlane。它刻意對齊 VPS 維運習慣：帳號、金鑰、磁碟水位、日誌回傳四件事一次打通。
凍結工具鏈指紋：在遠端 Mac 上記錄 xcodebuild -version、node -v、ruby -v、pod --version，寫入儲存庫的 BUILD_ENV.lock；任何升級必須走 PR，避免「有人 SSH 手滑升級」。
為 CI 建立非登入互動使用者：避免用個人 Apple ID 工作階段跑批次任務；給 Runner 或 SSH Job 獨立使用者與鑰匙圈分區，和站內 可重現建置 清單裡的 Keychain 隔離策略對齊。
拆分 DerivedData 與 Pods 路徑：依儲存庫或分支掛獨立目錄，例如 ~/DerivedData/$REPO/$BRANCH 與 ~/PodsCache/$REPO，把清理策略寫成 cron 而不是依賴系統暫時回收。
把 iOS Job 接回主 CI：在 GitHub Actions／GitLab 裡用 self-hosted labels 指向獨佔機，和 Android Job 共用一套審批與併發閘道；需要圖形化除錯時再用受控 VNC 視窗，而不是長期開著桌面。
產出物與日誌回傳：用受控物件儲存或內網產物庫保存 .ipa、dSYM 與 xcodebuild 原始日誌；對金融客戶可額外開啟指令層工作階段錄影，滿足事後鑑識。
做兩週對照實驗：挑 5 條具代表性的分支，同時記錄 EAS 與獨佔機的 P50／P95 建置耗時與失敗類型；若獨佔機在原生重依賴場景穩定領先且佇列方差更小，就可以把 Release 流量切過去。
提示：若團隊仍在評估地區與磁碟檔位，可先閱讀 租賃價格說明，把「併發 × 磁碟水位 × 出口地區」三維寫進採購附件，再與上面六步清單合併驗收。
xcodebuild 會在連結階段隨機失敗。把 iOS 建置繼續完全綁在託管池上，短期最省人力；但當原生依賴、稽核欄位、以及與既有 Actions／GitLab 的統一排程成為硬約束時，黑箱佇列＋不可釘死的映像會持續放大不確定性。反過來，自建 Mac 叢集若缺少磁碟治理與指紋策略，也會迅速退化成難以維運的遺產堆疊。
綜合來看，需要7×24 可預期佇列、可稽核指令工作階段、與既有 Runner 標籤體系一致的 RN／Expo 交付團隊，較適合把重負載放在獨佔 macOS 平面；託管 EAS 則繼續承擔輕量整合與對外協作。對於希望把執行環境當成可寫入合約的節點、減少排隊方差並服務 iOS CI／CD 與常駐自動化的場景，NodeMini 的 Mac Mini 雲端租賃通常是較穩健的解方。
當你要把 iOS 建置當成可擴容節點：需要固定磁碟與併發、可匯出的指令層日誌，或原生依賴鏈無法適配託管映像時，獨佔遠端 Mac 較合適。可先對照租賃價格說明做小規模試點，再決定是否把 Release Job 全量切過去。
會，因此必須拆分 profile 與鑰匙圈邊界：託管路徑只用 EAS 託管簽名，自託管路徑用 match 或企業 KMS；並在 README 寫明切換條件。更多連線與權限題目可參考幫助中心的 SSH 與帳號章節。
Runner 篇講 labels、快取與佇列；本文講 RN／Expo 在 EAS 與獨佔平面之間的分工。若你已在遠端 Mac 上註冊 Runner，可直接把本文的六步清單當作上線驗收擴充項。