為什麼要把 GitHub 託管分鐘與 Xcode Cloud 分開討論？

二者優化對象不同：託管 Runner 解決 Git 事件驅動的通用 macOS CI；Xcode Cloud 強化與 Xcode 與 App Store Connect 的一體化。用一張三列表評審可避免把隊列問題誤判為證書問題。

專用 Mac 雲最常見的隱性成本是什麼？

磁碟爭用與過高並行導致的 p95 抖動。若缺少水位告警與並發上限，會把省下的分鐘費轉化為隨機失敗與排障人力。

兩周窗口如何判定該加第二臺節點？

當排隊佔比持續上升且並發分組已優化，或磁碟與內存告警多次觸發，或需要第二區域災備時，應水平複製標籤策略加節點，而不是繼續堆單機並行。

2026 年 iOS CI 三種算力來源怎麼選：GitHub 託管 Runner、Xcode Cloud 與專用 Mac 雲的分鐘費、排隊與可自訂決策表

平台工程與移動端負責人常被財務追問：為什麼已經買了 GitHub 分鐘，還要討論 Xcode Cloud，最後又冒出「專用 Mac 雲」？本文面向熟悉 VPS 與 Actions 的團隊，先回答「誰該為排隊付帳、誰該為可自訂付運維」；再用一張三列表把帳單口徑、隊列風險、流水線邊界一次對齊；最後給出三種可複製的組合劇本、五步落地參數，以及把兩週內失敗率與等待時間分開度量的 FAQ 結構化數據，幫助你把 2026 年的 CI 架構評審寫成可執行材料。

1. 導語摘要：三種算力分別優化什麼 KPI

先把對象說清楚：GitHub 託管 macOS Runner優化「Git 觸發後儘快拿到標準化 macOS 跑 YAML」，分鐘帳單與組織配額強相關；Xcode Cloud優化「Xcode + App Store Connect 的提交—測試—分發閉環」，分鐘帳單隨蘋果套餐走，定製受平臺邊界約束；專用 Mac 雲把 macOS 當可 SSH、可打標籤、可固定磁碟與出口的獨佔算力，帳單近主機租期加流量，換來並發、DerivedData、鑰匙串與企業出口的自控。誤區是把三者當替代：Runner 不管 TestFlight 深度集成；Xcode Cloud 也不等於任意 shell 與常駐自動化同機並行；專用池缺度量時「加並發」會把磁碟與內存爭用放大成隨機失敗。下文先拆痛點，再給三列表與組合劇本。

2. 痛點拆解：分鐘費、隊列、蘋果生態邊界與磁碟爭用

評審材料裡最常見的四類衝突如下：

分鐘費與排隊：託管分鐘若不分列「排隊 vs 編譯」，易誤判加並發即可省錢；Xcode Cloud 在檔位邊界也有排隊感知；專用池單機堆並行會把省下的分鐘費換成 p95 抖動。
生態集成 vs 自由度：Xcode Cloud 證書與 ASC 銜接省心但腳本矩陣有邊界；託管 Runner shell 更自由仍受鏡像與網絡約束；專用池可並存多 Xcode 與私有 registry，運維回到團隊。
磁碟與緩存：託管依賴 Actions 緩存語義；Cloud 由平臺託管；專用池可固定 DerivedData 但必須配磁碟水位告警，個位數 GB 可用時連結易隨機失敗。
合規出口：固定源 IP、代理鏈、PKCS 對齊優先專用池；純託管常在審計期暴露製品出站不一致。

3. 三列表決策矩陣：託管 Runner / Xcode Cloud / 專用 Mac 雲

下表對比帳單、隊列、可自訂與運維負擔，可直接進架構說明；混合是三列組合而非第四種算力。

維度	GitHub 託管 macOS Runner	Xcode Cloud	專用 Mac 雲（自託管 Runner）
帳單口徑	按執行分鐘計費，易隨高峰疊加	按蘋果套餐與工作流分鐘計費	主機租期 + 流量，適合長時佔 CPU
隊列風險	組織配額與共享池爭用	檔位與並發上限相關	由自有標籤與 executor 決定，風險轉為資源爭用
可自訂深度	YAML + 鏡像允許範圍內的 shell	與 Xcode 工作流強綁定	任意 shell、launchd、磁碟布局、出口策略
證書與籤名	按官方 secrets 模型	可走蘋果託管路徑降低鑰匙串心智	無人值守 match / API Key / 內網 PKCS 對齊
典型最佳信號	PR 輕驗證、波動並發、少運維	以 ASC 發行為中心的團隊	重 Archive、企業網、複合負載、穩定 p95

                實踐提示：README 寫明分支與標籤：release/* 專用、默認 PR 託管、夜間回歸 Cloud；concurrency 防 DerivedData 重入。
            

4. 落地步驟：從度量到組合上線的五步

建議按下述順序推進。

分列度量：隊列等待、編譯分鐘、重試分鐘分別打點；Cloud 記工作流排隊；專用池記磁碟與內存峰值。
定組合劇本：小團隊 Cloud + 少量託管；峰值託管 PR + 專用 Archive；企業網專用為主託管為輔。
基線與標籤：SSH 核對 xcodebuild -version，磁碟建議 ≥40GB；標籤含區域與 Xcode 小版本。
並發與清理：按內存峰值定並行；DerivedData 分路徑；清理鉤子寫入 Runbook。
擴容判據：排隊超窗或磁碟內存告警或雙區災備時水平加節點，複製標籤而非堆單機並發。

在 GitHub Actions 中用條件路由：PR 走託管，release/* 走專用標籤並加 concurrency：

jobs:
  ios-pr:
    if: github.event_name == 'pull_request'
    runs-on: macos-14
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build
  ios-archive:
    if: startsWith(github.ref, 'refs/heads/release/')
    runs-on: [self-hosted, macOS, ARM64, pool-prod]
    concurrency:
      group: ios-archive-${{ github.ref }}
      cancel-in-progress: false
    timeout-minutes: 120
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -configuration Release archive

5. 可引用技術信息：評審與復盤硬指標

下列條目可在容量規劃或事故復盤材料中直接引用（具體以合同與實測為準）：

磁碟閾值：開啟緩存後 DerivedData 數日可佔數十 GB；連續可用 <10GB 時連結易隨機失敗，應硬告警。
內存與並行：單路 Archive 常見峰值約 12～18GB，用以估算單機並行 xcodebuild 上限。
網絡 RTT：頻繁 fetch 與二進位依賴時，區域過遠線性放大總時長；PoC 分列 p95 構建與隊列等待。
失敗分層：籤名、依賴、OOM、上傳四類打標籤，指導調配額、磁碟或並發。

6. 三種推薦組合與何時加第二臺節點

組合 A：Cloud 覆蓋提交與 TestFlight，託管分鐘接輕 PR；排隊侵蝕窗口時再加專用機跑 Archive。組合 B：PR 走託管，release/* 與 notarytool 走專用池；峰值周臨時加節點攤薄閒置。組合 C：專用池為主託管為輔，出口代理一次對齊審計。若只堆託管分鐘或把 Cloud 當萬能腳本機，會持續付排隊、磁碟語義與跨工具鏈返工三類隱性成本。辦公室自購 Mac 有電力與升級負擔；無度量的單機自託管則難穩 p95。對需要 Apple 工具鏈與可預期並發、又要像管 VPS 一樣可控算力的團隊，租賃 VPSMAC 的 M4 Mac 雲節點通常更易把重任務與緩存策略落在獨佔 NVMe 與固定出口上，並把上架收斂到小時級 SSH 交付。要把開通與對接壓到接近 API，請繼續閱讀站內 Mac 雲 90 秒 API 與 CI/CD 對接實踐完成閉環。

2026 年 iOS CI「三種算力來源」怎麼選才不虧？GitHub 託管 macOS Runner、Xcode Cloud 與專用 Mac 雲的分鐘費、排隊與可自訂對照表 + 推薦組合

本文要點