为什么要把 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 云的分钟费、排队与可定制对照表 + 推荐组合

本文要点