Xcode 27 Beta 6 的發布說明已確認：UIKit Interface Builder 文件預設可以使用 toolchain 模式編譯，而不必下載 Simulator；同一份資料也確認 Xcode 27 僅能執行於 Apple Silicon Mac。官方發布說明 因此，不要在所有 iOS 27 CI 節點統一移除 Simulator。正確做法是把可脫離執行期的建構工作移到輕量節點，把應用程式測試、UI 測試與相容性驗證保留在完整測試節點，先以同一個專案雙軌試跑。
本文適合三類讀者：只負責編譯、靜態檢查與制品生成，希望縮減遠端 Mac 依賴的建構工程師；維護 XCTest、UI 自動化及多版本測試的測試團隊；以及正在調整遠端 Mac 節點池、快取與恢復策略的 DevOps 和研發平台負責人。
最後更新於 2026 年 9 月 8 日；技術資料核實自 Xcode 27 Beta 6 發布說明、Apple 的測試文件、Build Settings Reference 及 App Store Connect 文件。Xcode 27 與 iOS 27 目前仍應按 Beta 資料評估，正式版行為不能提前視為已確認。
[ SECTION_01 ] 先把 SDK、Runtime、模擬裝置與編譯模式分開
iOS 27 CI 是否需要 Simulator，不能只看專案是否包含 UIKit，也不能把「安裝 SDK」和「下載 Simulator runtime」當成同一件事。
- SDK：提供標頭檔、框架與編譯所需的介面。
- Simulator runtime：讓 macOS 啟動指定 iOS 版本的模擬執行環境。
- 模擬裝置：以某個 runtime 建立的 iPhone 或 iPad 測試目標。
- Interface Builder 編譯模式：決定 Storyboard、XIB 等介面文件由哪一種工具鏈處理。
- 測試 destination：決定測試要在 macOS、Simulator 或真機上執行。
Xcode 27 的新 toolchain 行為，針對的是 UIKit Interface Builder 文件的編譯階段。它不代表應用程式能在沒有執行期的情況下啟動，也不代表 XCTest UI 測試可以改在純建構節點完成。
Xcode 27 建構 iOS 專案可以完全不下載 Simulator 嗎？
如果任務只包含程式碼編譯、部分介面資源編譯、靜態檢查與制品輸出，答案是「部分可以」。前提是實際專案使用了 Xcode 27 已確認支援的 toolchain 模式，而且建構日誌沒有要求 Simulator destination 或 runtime。這項判斷不能套用到所有舊專案、所有自訂設定或直接呼叫 ibtool 的流程。
[ SECTION_02 ] 建構工程師：先驗證純建構邊界
對建構團隊而言，最容易出錯的地方是把一次成功的 build 當成整個遷移完成。成功建構只證明該次命令產生了可接受的輸出，不能證明測試、介面資源或日後的測試節點都已脫離 Simulator。
建議依照以下順序建立可回退的驗收流程：
- 固定 Xcode 版本、SDK、提交版本與簽名設定，避免候選節點和原節點同時改變。
- 在原有完整節點上執行一次純建構，保存完整建構日誌、產物清單與錯誤輸出。
- 在不預裝 Simulator runtime 的候選遠端 Mac 上重跑相同建構命令，觀察是否出現 destination、runtime 或模擬器服務請求。
- 檢查 Storyboard、XIB 及其他介面資源是否有編譯錯誤，並比對
.app、資源包與符號檔等輸出。 - 檢查 Target 的 Interface Builder 相關設定，尤其是
IBC_COCOATOUCH_COMPILER_MODE；設定定義應以 Apple 的 Build Settings Reference 為準。 - 對同一提交執行
build-for-testing，保留測試制品，確認建構階段沒有偷偷觸發 Simulator。 - 若專案必須回到 simulator 模式，記錄觸發條件、受影響 Target、設定檔位置及恢復命令，不能只在平台文件寫「必要時回退」。
若是直接呼叫 ibtool、使用自訂 Build Phase，或專案年代較久，預設模式未必代表整個流程都會採用新工具鏈。這也是為何需要同時檢查命令列、建構設定與實際產物，而不是只看 Xcode 介面中的成功狀態。Xcode Target 建構設定文件 可用來核對 Target 層級設定。
Interface Builder toolchain 模式會影響現有 Storyboard 嗎？
它可能改變 Storyboard 或 XIB 的編譯路徑，但不應直接推論為所有介面文件都需要修改。維護者應在真實專案中確認三件事：介面文件能否正常編譯、產物能否被應用程式載入、以及在實際測試 destination 上是否呈現一致。
如果舊專案依賴自訂建構設定，或資源在 Build Phase 中被額外處理，候選節點應保留完整日誌。一次成功不足以排除特定畫面、資源引用或後續測試階段的差異。
[ SECTION_03 ] 測試團隊：按測試宿主而不是測試名稱分流
「Unit Tests」並不是單一工作負載。相同的測試目標，可能只測試純 Swift 邏輯，也可能需要啟動應用程式宿主並呼叫 iOS 系統行為。
可以按以下方式分辨：
- 純 Swift 邏輯測試：若不依賴 UIKit 執行期、檔案系統特性或 iOS 平台行為，通常較適合先放到輕量建構節點驗證。
- 應用程式宿主測試：若設定了 Test Host，或測試需要載入應用程式進程，就必須確認宿主是否要在 Simulator 或真機啟動。
- 平台整合測試：涉及推播、背景執行、權限、相機、位置、Keychain 或其他 iOS 行為時，不能只依賴無執行期的編譯結果。
測試遷移前，應逐項核對測試 Target 的 destination、Test Host、SDK、測試制品及測試結果包。Apple 的測試執行與結果解讀文件說明了測試執行與結果判讀邊界；測試團隊也可使用 Test Plan 組織測試，將純邏輯測試與需要裝置執行的測試拆成不同組合。
哪些 iOS CI 工作仍必須安裝 Simulator runtime？
只要 CI 需要啟動 iOS 應用程式或驗證 iOS 執行期行為，就應保留相應的 Simulator runtime，或改用真機。這包括應用程式宿主測試、依賴 UIKit 執行狀態的整合測試，以及必須實際操作應用程式畫面的 UI 自動化。
這裡要區分「有 Simulator runtime」和「已有可用模擬裝置」。前者是執行環境，後者是測試目標。CI 節點即使已下載 runtime，也仍須確認測試 destination、模擬裝置初始化、資料清理及重啟後恢復流程。Apple 的模擬或實體裝置執行文件可作為 destination 驗證依據。
[ SECTION_04 ] UI 自動化團隊：完整測試節點不能被新編譯模式取代
XCTest UI Tests 的核心不是「能否編譯測試程式」，而是能否啟動被測應用程式、找到畫面元素並完成操作。新 toolchain 模式只處理部分介面文件編譯，無法取代應用程式執行環境。
UI 測試節點至少應驗證以下項目：
- Test Plan 是否指向正確的測試 Target。
- destination 是否明確指定所需的 Simulator 或真機。
- 測試是否真的啟動應用程式，而不是只產生測試 Bundle。
.xcresult是否包含測試步驟、失敗畫面或影片等證據。- 節點重啟後，runtime、模擬裝置與測試資料是否能恢復。
- 平行測試時，模擬裝置複製與資源競爭是否造成不穩定。
平行測試的容量結論不能靠網路文章中的固定數字推算。應在團隊自己的遠端 Mac 節點上記錄同時執行數、記憶體壓力、硬碟空間、測試耗時與失敗類型。若沒有本站實測或官方資料，便不應宣稱某種節點一定可以承載特定數量的模擬裝置。
[ SECTION_05 ] CI 平台團隊：三種節點拓撲與適用條件
以下對比可作為 iOS 27 CI 的初步決策工具。評分是本文針對維運複雜度、環境依賴與風險的相對判斷，不是 Apple 的官方性能測試。
| 拓撲 | 建構節點 | 測試節點 | 適用條件 | 綜合評分 |
|---|---|---|---|---|
| 單池保留 | 建構與測試共用完整遠端 Mac | 同一節點執行 Simulator | 專案規模較小、測試比例高、暫時不想改 CI 路由 | ★★★ |
| 雙池拆分 | 不預裝不必要 runtime 的輕量 Mac | 預先初始化 runtime 與模擬裝置的完整 Mac | 建構量大、UI 測試集中、希望分開快取與故障恢復 | ★★★★★ |
| 暫緩遷移 | 先維持現有完整節點 | 不改變測試鏈路 | Beta 行為尚未穩定，或專案仍有大量自訂 Interface Builder 流程 | ★★★★ |
雙池方案的關鍵不是單純刪除套件，而是讓產物能夠在另一個節點被可靠地執行。Apple 的技術說明提供了 build-for-testing 與 test-without-building 的工作方式；Build For Testing 與 Test Without Building 技術文件可用來設計「建構節點產出、測試節點執行」的鏈路。
兩個節點必須核對 Xcode 版本、SDK、簽名環境、測試制品、destination 與必要的測試資料。若建構節點和測試節點使用不同工具鏈，測試失敗時便難以判斷是程式問題、產物問題，還是環境差異。
對於需要長時間在線的團隊，也可先參考 NOVAKVM 的遠端 Mac 方案，但不應在尚未完成專案驗收前直接替換生產建構節點。
[ SECTION_06 ] 發布負責人：用雙軌證據決定是否精簡
發布負責人應選擇一個真實專案，而不是用空白 Demo 做判斷。專案至少應涵蓋 Storyboard 或 XIB、應用程式宿主測試及 UI 自動化，才能暴露「只建構成功」與「完整鏈路可發布」之間的差異。
建議將同一提交分成兩條軌道：
- 原完整節點：執行既有建構、
build-for-testing、test-without-building及 UI 測試。 - 候選輕量節點：執行純建構、介面資源編譯與制品輸出，觀察是否隱式下載或呼叫 Simulator。
- 測試節點：接收相同制品，執行應用程式宿主測試及 UI 測試。
- 回退測試：重啟節點、清理快取、重新登入建構服務後，再重跑關鍵工作。
- 發布驗證：確認產物仍能進入既有簽名及上傳流程。App Store Connect 的建構上傳文件可用來核對發布端的制品狀態。
只有在純建構任務持續通過、沒有隱式要求 Simulator、產物可被完整測試節點消費，並且重啟後仍能恢復時，才適合正式精簡對應節點。若任何一步需要人工補 runtime、改 destination 或重新生成測試制品，便應先保留原拓撲。
需要規劃遠端 Mac 建構節點和測試節點的團隊，可先閱讀 遠端 Mac 的環境驗收入口，把 Xcode 版本、快取、重啟與連線恢復列入驗收，而不是只檢查首次登入是否成功。
[ SECTION_07 ] 結論：先拆工作負載，再決定是否移除 Simulator
iOS 27 CI 的判斷矩陣可以濃縮成以下規則：
- 只做程式碼編譯、部分 UIKit 介面文件編譯、靜態檢查及制品生成：先測試輕量建構節點。
- 需要 Test Host、應用程式進程或 iOS 平台行為：保留 Simulator 或真機測試鏈路。
- 需要操作畫面、驗證 UI 狀態或輸出測試證據：使用完整 UI 測試節點。
- 使用自訂
ibtool、舊建構設定或不明確的資源流程：暫緩精簡，先建立回退入口。 - Xcode 27 或 iOS 27 Beta 行為出現變更：重新核對官方發布說明，不以媒體推測作為節點決策。
若目前方案是單一 Linux 或 Windows CI 主機加上零散的遠端呼叫，常見缺點是無法提供 macOS 專屬工具鏈、Simulator runtime 管理不一致，而且測試失敗後缺少可重現的遠端環境。若改用本地 Mac mini，則需要自行承擔硬體採購、長時間在線、故障替換與節點恢復。對只需在驗收期、Beta 期或特定建構窗口使用 Mac 的團隊而言，租用 NOVAKVM 的遠端 Mac，可按建構池或測試池所需週期建立可回退環境，先複製真實專案完成雙軌試跑，再決定是否擴大使用，通常比直接改動生產節點更穩妥。