截至 2026 年 9 月 5 日，GitLab 官方 Hosted macOS Runner 公開映像列出的是 macOS 15/Xcode 16 與 macOS 26/Xcode 26，尚未列出 Xcode 27；Apple 則已發布 Xcode 27 Beta 系列，可在GitLab Hosted macOS Runner 官方映像文件與 Apple Xcode 27 Release Notes核對。因此，本週不要把 Hosted Runner 當成 Xcode 27 生產遷移的唯一環境：讓託管節點繼續承擔現有穩定工具鏈與非敏感驗證，另以自託管 Mac 承擔 Xcode 27 試點、私網任務及正式簽名。
SECTION 01 誰需要先看這份選型判斷？
如果你正在制定 Xcode 27 適配計劃，需要確認 GitLab 託管映像的支援邊界，本文會提供可核對的版本與容量條件。
如果你負責程式碼簽名、內部依賴、網路隔離或企業採購，也可以用本文判斷哪些工作不能直接送入 Hosted Runner。
本文同樣適合需要比較託管計算用量、自託管 Mac 維運成本與節點備援責任的技術總監及研發效能負責人。
SECTION 02 先分清四種「版本狀態」
GitLab Hosted macOS Runner 的 Beta 狀態、單一 macOS 映像的生命週期、Xcode 本身的發布階段，以及自託管 Runner 應用程式版本，並不是同一件事。
截至本文核實日期，官方文件將 Hosted runners on macOS 標為 Beta，公開映像包含 macOS 15/Xcode 16 和 macOS 26/Xcode 26，沒有 Xcode 27 映像。這只代表官方目前沒有提供可直接選用的 Xcode 27 託管映像，不代表 Xcode 27 本身不能在其他 Mac 環境執行。
Apple 已發布 Xcode 27 Beta 系列，但 Beta 可用性不等於 GitLab 已完成映像、Runner 相容性、Simulator Runtime 和企業簽名流程的整體驗證。你應將「Apple 已發布」和「GitLab 已託管」放在兩個不同的驗收欄位。
注意：不要用媒體報道或社群猜測推算 Xcode 27 映像的上線日期。本文只把 GitLab 官方映像文件和 Apple 官方 Release Notes 當作版本可用性的依據。
這個版本落差直接導出第一個決策：現有 Xcode 26 工作流程可以繼續評估託管方案，但 Xcode 27 生產遷移需要獨立自託管 Mac Runner，至少先完成 PoC。
SECTION 03 GitLab Hosted macOS Runner Xcode 27 的環境控制邊界
託管映像的優點是交付速度和維護責任較低，但「可以選擇某個映像」不等於你能控制該映像何時更新、何時退役，以及 Simulator Runtime 和預裝工具的變更窗口。
自託管 Mac 則相反：你可以自行安裝 Xcode 27、指定命令列工具版本、保留特定 Simulator Runtime，並將依賴工具寫入環境清單；但這也代表你要負責更新、修復、磁碟清理、權限管理和節點一致性。
對企業而言，真正需要驗收的不是「今天能否成功建置」，而是同一提交能否在相同工具鏈下重複得到相同結果。建議為每個節點保留以下資料：
- 記錄 Xcode、Swift、SDK、Simulator Runtime 和命令列工具版本。
- 將依賴工具與安裝方式寫入可審查的建置設定。
- 為託管映像與自託管 Mac 分別保存環境清單。
- 以同一提交重跑編譯、單元測試和封裝任務。
- 比較產物雜湊、測試結果、警告和簽名狀態。
- 在映像更新或 Xcode Beta 轉換時重新執行基線驗證。
這也是 GitLab CI/CD 選型中最容易被忽略的條件：短期成功不代表長期可重現。你可以參考 GitLab Runner macOS 安裝文件理解自託管 Runner 的安裝邊界，也可先查看 VPSNIX 的支援中心確認遠程 Mac 交付與管理問題，再將安裝、權限和版本驗收分開記錄。安裝完成只代表節點可接收工作，不代表工具鏈已完成企業驗收。
SECTION 04 簽名、權限與任務隔離應怎樣分流？
正式發布任務比一般編譯更敏感，因為它會接觸 Apple Developer 憑證、Provisioning Profile、Keychain、發布帳號和可追溯的產物流程。
Hosted Runner 適合放入一般編譯、公開測試和不含生產憑證的驗證任務。正式簽名則要逐項確認：
- 憑證是否以短生命週期方式注入，工作結束後能否清理。
- 任務是否擁有管理員權限，其他工作負載是否可能接觸工作區。
- Keychain、Profile 和臨時檔案是否有明確的建立與銷毀步驟。
- 是否保存足夠的任務、操作者和產物稽核紀錄。
- 安全團隊是否接受託管節點的隔離模型和資料邊界。
自託管專用 Mac 能提供較清楚的節點歸屬、固定 Keychain 和內部稽核邊界，但責任也轉回企業：你必須清理工作區、限制 Runner 標籤、隔離簽名任務、輪換憑證，並處理節點失陷或誤用後的撤銷流程。
因此，預設分流應是：普通編譯和測試進入託管池；Xcode 27 試點、正式簽名和高敏感任務進入通過審計的專用自託管 Mac。不要因為某個託管任務能執行簽名命令，就直接推定它符合你的發布政策。
SECTION 05 私網、內部依賴與資料邊界
能夠從 GitLab 拉取程式碼，並不代表 Runner 能存取完整企業依賴。常見阻塞點包括私有套件庫、內部 API、固定出口 IP、代理伺服器、公司 DNS、白名單和資料駐留要求。
你應先畫出網路流向，而不是在 Pipeline 失敗後才猜測原因。最少要列出：
- 原始碼與子模組的來源端點。
- Swift Package、CocoaPods 或其他依賴的制品庫。
- 測試所需的內部 API、資料庫和服務模擬器。
- 簽名服務、通知服務和產物儲存位置。
- 出口 IP、代理、DNS 和防火牆規則。
- 每個端點傳輸的資料類型與保存期限。
若工作負載依賴固定出口或不能離開企業網段，通常應回退到自託管 Mac。若只需要公開依賴、公開測試和不含敏感資料的驗證，託管節點才有較高的彈性價值。
驗收證據應包括網路流向圖、端點清單、實際失敗日誌，以及安全團隊簽字記錄。只憑「程式碼可以拉下來」作為合規證據，不能覆蓋制品、測試資料和發布服務的實際邊界。
SECTION 06 佇列與容量要用任務組合核算
Hosted Runner 的成本和產能，不能只看單次建置時間；自託管 Mac 也不能只看晶片規格。企業真正要測量的是等待時間、執行時間、快取命中、失敗重試、空閒容量與故障恢復。
建議將工作負載拆成四類：Pull Request 編譯、測試、正式歸檔，以及需要重試或人工介入的簽名任務。測試時要使用真實任務組合，而不是一次乾淨建置；否則會低估佇列、快取失效和歸檔流程對節點池的影響。
GitLab 的計算用量規則應直接對照官方 Compute Minutes 文件，企業帳單則應以實際消耗為準。自託管方案要另外記錄節點租賃或採購、儲存、維護、備援、人力與停機損失。
可用以下變數建立容量模型：
W：指定週期內的總計算工作量。P：高峰時段的並行工作量。E：單一節點在真實任務組合下的有效產能。R：重試、失敗和維護造成的容量折損。B：備援與故障恢復所需的保留容量。
穩定基線可用 W ÷ E 估算，峰值則應以 P 和 B 重新檢查；這些是模型變數，不應在沒有企業實測時預填節點數或分鐘數。你也可以使用 Runner Fleet Dashboard 文件觀察 Runner 狀態，但儀表板指標仍需和企業自己的任務分類及恢復紀錄配合解讀。
SECTION 07 用決策條件清單確定混合節點池
在採購或申請資源前，按以下分支處理：
- 若現有工具鏈仍是官方託管映像，且任務不含私密憑證，則先保留 Hosted Runner，避免為穩定工作負載提前承擔自託管維運。
- 若需要 Xcode 27、固定 Simulator Runtime 或特殊命令列工具，則建立隔離的自託管 Mac Runner，先做同一提交的 A/B 驗證。
- 若任務需要私有制品庫、固定出口或內部 API，則優先放在可通過網路審查的自託管節點。
- 若只做普通編譯、公開測試或短期峰值驗證，則使用託管節點，並把計算用量與佇列納入月度監控。
- 若需要 App Store 正式簽名，則只有在安全團隊確認隔離、憑證、Keychain、清理與稽核條件後，才可考慮託管；否則回退到專用自託管 Mac。
- 若單一節點故障會阻塞發布，則把備援節點、恢復時間與未完成任務重跑納入 TCO，而不是只比較月租或計算分鐘。
- 若企業仍未確定 Xcode 27 映像的可用日期，則不要等待公告才開始，先以自託管 Runner 完成版本和安全 PoC。
SECTION 08 方案與 TCO 對照
| 指標 | Hosted macOS Runner | 自託管 Mac Runner | 混合節點池 |
|---|---|---|---|
| Xcode 27 即時可用性 | 截至 2026 年 9 月 5 日，官方清單未列出 | 可自行部署，但要自行驗證 | 以自託管承擔 Xcode 27，託管保留穩定版本 |
| 工具鏈控制 | 受公開映像與更新窗口限制 | 可固定 Xcode、Runtime 和依賴 | 按工作負載分配控制責任 |
| 私網依賴 | 需逐項核對出口、代理和白名單 | 可放入企業網路邊界 | 敏感任務走自託管 |
| 正式簽名 | 需通過企業安全審查 | 可建立專用 Keychain 與節點政策 | 生產簽名與一般測試分離 |
| 維運責任 | 映像維護較少，但需監測版本與佇列 | 企業負責更新、清理、修復與備援 | 需治理兩套生命週期 |
| 適合的負載 | 穩定工具鏈、非敏感測試、波動峰值 | Xcode 27、私網、固定環境、正式簽名 | 多數企業的過渡與長期方案 |
TCO 應寫成可追溯的變數模型，而不是填入未驗證的單價：
| 成本項目 | 託管方案 | 自託管 Mac 方案 |
|---|---|---|
| 計算或租賃費 | 依實際計算用量與企業帳單核算 | 依 Mac 租賃或採購、儲存與使用週期核算 |
| 維運人力 | 映像和佇列監控 | Runner 更新、Xcode 維護、清理與故障處理 |
| 安全治理 | 憑證注入、任務隔離、供應商審查 | Keychain、節點隔離、輪換、稽核與恢復 |
| 容量損失 | 等待、重試、計算用量波動 | 閒置容量、備援節點與維護窗口 |
| 中斷風險 | 版本缺口或託管服務狀態變更 | 硬體、網路、磁碟及人員故障 |
| 決策依據 | 官方計算規則與企業帳單 | 真實任務產能、恢復紀錄與維運工時 |
若你只是為短期 Xcode 27 PoC 添置節點，租用獨立遠程 Mac 通常比立即採購實機更容易控制試點週期與資本支出；你可以先查看 VPSNIX 的 Mac 方案與計價資訊，再把實際租期、節點維護和恢復責任放回同一張 TCO 表，而不是只看表面月費。
SECTION 09 目前方案與遠程 Mac 的取捨
只依賴 GitLab Hosted macOS Runner，現階段有三個實際缺點：Xcode 27 映像尚未列出、私網與固定出口不一定符合企業邊界，以及正式簽名的隔離和稽核責任仍需逐項確認。全部改成自購 Mac，則會增加硬體折舊、節點閒置、遠端維護和故障恢復負擔。
如果你的目標是先驗證 Xcode 27、私網依賴或專用簽名流程，VPSNIX 的遠程 Mac 可作為獨立 Runner PoC，讓你以真實 Pipeline、佇列和重啟恢復紀錄決定是否擴展節點池。這種做法不取代長期穩定重負載下的自有基礎設施，也不適合需要本地實體介面的工作；但對版本過渡、臨時容量和企業試點，通常比等待託管映像更新更直接。
先用本文的分流條件標記 Xcode 27、簽名和私網任務，再申請一台隔離節點完成驗證，會比一次性全量遷移更容易控制風險。