遇到的症狀：Xcode 27 打包機硬碟被 Simulator Runtime 佔滿，但實際只做 Archive 和上傳。 最快解法：只負責編譯、Archive、簽名發布的機器先不要安裝 iOS Simulator Runtime；只有執行模擬器測試、SwiftUI Preview 或多版本驗證時，才安裝相符 Runtime。
先按任務切開 Xcode 27 的元件邊界
這篇適合三類人：只想讓遠端 Mac 執行 Release Archive、簽名和上傳的獨立開發者；使用 Storyboard 或 XIB、擔心沒有模擬器便無法編譯的 UIKit 維護者；以及需要 XCTest UI Tests、多版本回歸或 SwiftUI Preview 的小型團隊。
最容易造成浪費的錯誤，是把「專案支援 iOS」直接等同於「打包機必須安裝所有 iOS Simulator Runtime」。實際上，以下元件負責的事情不同：
| 元件 | 主要用途 | 純 Archive 是否必需 |
|---|---|---|
| Xcode 與平台 SDK | 編譯 App、產生 Archive、簽名及發布 | 是 |
| iOS Simulator Runtime | 在模擬環境啟動 iOS App 和測試 | 否，除非任務會執行模擬器 |
| 模擬裝置資料 | 指定裝置、系統版本及測試目的地 | 否，除非要啟動模擬器 |
| Interface Builder toolchain | 編譯 Storyboard、XIB 等 UIKit 文件 | Xcode 27 的預設模式下通常不因介面資源而強制需要 Runtime |
| xcodebuild 測試目的地 | 控制建置、測試、Archive 和 destination | 視 action 與 destination 而定 |
截至 2026 年 9 月 5 日，Apple 的 Xcode 系統要求頁面列出 Xcode 27 beta 4。本文只把已核實的 Beta 行為當作目前規劃依據，不把未來 RC 或正式版的預設行為寫成永久規則。
注意：平台 SDK、Simulator Runtime 和模擬裝置不是同一項元件。刪除模擬器資料，不等於刪除 SDK；保留 SDK，也不代表機器具備執行 iOS Simulator 測試的條件。
讓發布機維持最小元件集合
如果你的流程只有 xcodebuild archive、簽名、匯出和上傳，先以「任務依賴」而不是「專案名稱」決定安裝內容。Apple 的 Xcode 命令列工具參考涵蓋命令列建置與相關 action；真正需要確認的是你的 Scheme、腳本和 destination 是否暗中呼叫模擬器。
Xcode 27 不安裝 iOS 模擬器，能否正常完成 Archive？
可以，但前提是 Archive 流程沒有執行模擬器測試、模擬器專用腳本或依賴特定 Simulator destination。你應使用同一個提交版本，在乾淨環境執行一次完整 Release Archive，然後檢查 .xcarchive、簽名結果、匯出結果和上傳前驗證；不能只看到命令回傳成功便宣稱發布環境完整。
發布機至少要驗證以下內容：
- Xcode 版本與專案要求相符。
- 專案使用的 Apple SDK 可被
xcodebuild找到。 - Release configuration 能產生預期的
.xcarchive。 - Export Options、Team、簽名憑證和 Provisioning Profile 能正確配對。
- 上傳前驗證沒有因 Bundle ID、簽名或出口合規設定失敗。
- CI 腳本沒有呼叫
simctl、xcrun simctl或指定模擬器 destination。
只做 TestFlight 上傳，可以刪除模擬器嗎？
若工作流程確實只負責建置、簽名、匯出和上傳，通常可以先省略 iOS Simulator Runtime。可是，若上傳前的 Scheme 會觸發測試，或 CI 將 test、build-for-testing、test-without-building 串在 Archive 前後，就必須先檢查 destination 和測試目標，不能只因最終產物要上傳 TestFlight 便直接刪除。
讓 UIKit 專案用真實介面資源驗收
Storyboard 與 XIB 維護者的疑慮很具體：如果沒有 Simulator Runtime，Interface Builder 文件會不會無法編譯？Xcode 27 的新邊界是，UIKit 文件預設可使用 Interface Builder toolchain 模式編譯，因此「專案含有 Storyboard 或 XIB」本身不足以推導出 Runtime 依賴。
你需要檢查專案設定或腳本是否覆寫 IBC_COCOATOUCH_COMPILER_MODE。Apple 的 Build Settings Reference可用來核對設定名稱與目前可用的建置選項。若腳本強制採用 simulator 模式，便應把對應 Runtime 視為明確依賴，而不是修改所有打包機的共用配置。
Storyboard 專案編譯是否仍需要 Simulator Runtime？
在 Xcode 27 Beta Release Notes 所描述的預設 Interface Builder toolchain 模式下，僅為了編譯 Storyboard 或 XIB，通常不必下載 Simulator Runtime。但你必須以含有真實介面資源的專案執行 Archive，確認不是空專案或沒有使用介面的測試案例；若專案設定已回退到 simulator 模式，結論便不同。
建議用脫敏後的實際專案做三次檢查：
- 找出所有
.storyboard、.xib和相關 build setting。 - 以乾淨工作目錄執行 Release Archive，保留完整建置記錄。
- 解壓或檢視 Archive，確認介面資源已進入預期產物，再進行簽名及上傳前驗證。
經驗提醒：若團隊曾在舊版 Xcode 以腳本固定指定 simulator 編譯模式，先保留那段設定的變更記錄。直接全域刪除，可能令某個未被日常 Archive 覆蓋的 Scheme 在正式發布前才暴露問題。
讓測試人員按 destination 安裝 Runtime
測試維護者不能沿用發布機的判斷。真正會在 iOS Simulator 啟動 App 的測試，都需要可用且相符的 Runtime；這包括 XCTest UI Tests、指定模擬器的單元測試、互動式驗證，以及需要先建置再在模擬器執行的流程。
xcodebuild 哪些測試任務必須依賴模擬器？
當測試 destination 指向 iOS Simulator，或測試需要啟動模擬器中的 App、查詢模擬器狀態及執行 UI 操作時，便必須安裝相符 Runtime。build-for-testing 可能只產生測試產品，但如果後續 test-without-building 要在 iOS Simulator 執行，測試機仍必須具備對應平台和裝置。
可按以下方式拆分：
- 純 macOS 測試：只需要 macOS 測試環境，不應因 iOS 專案本身而自動安裝 iOS Runtime。
- iOS Simulator 單元測試：destination 指向模擬器時，需要相符 Runtime。
- XCTest UI Tests：需要啟動 iOS App 和互動介面，因此通常需要可用模擬器。
build-for-testing：先確認它只是產生測試產品，還是會被同一工作流立即執行。test-without-building：只要目的地是 iOS Simulator，就要把 Runtime 列為測試機依賴。
.xcresult，因為「專案能編譯」不等於「模擬器測試已通過」。
把 Preview 與多版本驗證移出發布機
SwiftUI Preview、互動除錯、不同 iOS 版本回歸和多裝置版面驗證，都是變動頻繁、需要立即啟動執行環境的工作。它們和穩定的發布 Archive 有不同維護週期，硬塞進同一台常駐打包機，會讓元件增刪、版本更新和測試失敗互相影響。
SwiftUI Preview 對開發工作站的依賴尤其明顯：你不只是編譯 App，還要啟動預覽、反覆修改介面並檢查不同狀態。這類工作不適合以「發布機沒有 Runtime 也能 Archive」作為判斷基準。
多版本相容測試也應獨立記錄：
- Scheme 或 Test Plan 要測哪些 iOS 版本。
- 每個 destination 使用哪個 Runtime。
- 測試是否包含 UI 操作、啟動流程或推播情境。
.xcresult是否已保存。- 缺少 Runtime 時，能否依照團隊文件恢復。
用清單完成一次冷啟動驗收
在決定租用或配置哪一類遠端 Mac 前，先以實際 Scheme、Test Plan 和發布腳本建立元件清單。以下清單的目的，是讓你在冷啟動後重新驗證，而不是只在空專案上跑一次成功建置。
- [ ] 記錄發布機實際執行的 action：Archive、export、upload，或另有 test。
- [ ] 記錄每個 Scheme 與 Test Plan 的 destination。
- [ ] 檢查腳本是否呼叫
simctl、模擬器專用指令或固定 simulator 模式。 - [ ] 檢查
IBC_COCOATOUCH_COMPILER_MODE是否被專案或 CI 覆寫。 - [ ] 使用含真實 Storyboard、XIB 或 SwiftUI 資源的提交版本。
- [ ] 冷啟動後執行一次乾淨 Release Archive。
- [ ] 保存
.xcarchive、簽名檢查、匯出結果和上傳前驗證記錄。 - [ ] 若有測試，保存
.xcresult，並確認測試機的 Runtime 與 destination 相符。 - [ ] 記錄缺少元件時的恢復方式，包括重新安裝、切換測試機或回退設定。
- [ ] 在 Beta、RC 或正式版更新後重做最小 Archive 與模擬器測試對照。
按團隊責任選擇單機或分離環境
完成驗收後，可以用以下兩張表快速作決策。評分是維運決策分數，不是 Apple 對產品的官方評級；分數越高，代表該方案越符合指定工作內容。
| 工作責任 | 發布機安裝 Runtime | 建議環境 | 決策評分 |
|---|---|---|---|
| 只做 Release Archive、簽名、TestFlight 上傳 | 否，先以實際腳本確認 | 精簡常駐發布機 | **5/5** |
| Storyboard/XIB 編譯與發布 | 通常否，先確認 Interface Builder 模式 | 精簡發布機，保留回退方案 | **4/5** |
| iOS Simulator 單元測試 | 是，按 destination 安裝 | 獨立測試機或測試節點 | **4/5** |
| XCTest UI Tests | 是 | 發布機與測試機分離 | **5/5** |
| SwiftUI Preview、互動除錯 | 是 | 開發工作站或獨立遠端測試環境 | **5/5** |
| 多 iOS 版本與多裝置回歸 | 是，按測試矩陣配置 | 獨立相容性測試環境 | **5/5** |
| 方案 | 適合誰 | 真正代價 | 風險控制 |
|---|---|---|---|
| 單一精簡發布機 | 低頻 Archive、穩定上傳 | 測試時需臨時切換或另找環境 | 發布前保留短期測試窗口 |
| 發布機加測試機 | 有 UI Tests 或多版本回歸的小團隊 | 需要維護兩套環境和權限 | 固定發布機，只在測試機更新 Runtime |
| 所有元件集中在一台機器 | 需要頻繁開發、Preview、測試和發布的人員 | 元件更新互相影響，故障邊界較難定位 | 將發布與測試 Scheme、權限和記錄分開 |
本站目前沒有提供可公開核對的「同一 UIKit 專案、無 Runtime 與有 Runtime」驗收實測資料，因此本文不填入磁碟節省量、初始化時間、硬體配置或租賃週期數字。這些項目必須以你的專案、Xcode 版本和遠端 Mac 實際記錄為準。
如果你目前用 Windows 或 Linux 主機加上不穩定的臨時轉發方案，常見缺點是無法直接執行 Xcode、簽名憑據和模擬器測試必須另找環境，而且每次發布都要重新處理連線與權限；即使已有一台本地 Mac，把大量 Runtime、測試和發布全部塞在同一台機器，也會增加磁碟管理和版本互相干擾的成本。對只需要短期驗證或持續發布的團隊，租用 MACGPU 的遠端 Mac，先以精簡發布環境完成真實 Archive，再按測試任務增加獨立環境，通常比一開始為不會執行的元件長期預留資源更容易控制。
若你已完成任務分類，可從 MACGPU 的 Mac 租用選項開始安排一段短期驗證週期：先驗證 Archive、簽名與上傳，再決定是否需要加入 Simulator Runtime。