2026年独占远程 Mac CI：仅装 Xcode Command Line Tools 还是完整 Xcode？归档、签名、Simulator 与 SSH 无头场景的决策矩阵 + FAQ
独占一台远程 Mac 跑 CI 时，「只装 Command Line Tools」能省磁盘与更新成本，但一碰到 iOS SDK、archive、Simulator 或图形会话假设，缺口会立刻暴露。本文用能力边界、场景矩阵与 SSH 无头注意点，帮你把安装决策写进 Runbook，并与团队对齐真需求。
先把边界说清楚：CLT 与完整 Xcode 各管什么
Xcode Command Line Tools（CLT）提供编译器、常用 Unix 工具、git、make 以及面向 macOS 目标的基础构建能力；体量远小于完整 Xcode，适合纯命令行、服务端 Swift、或只做 macOS 静态分析的流水线。
完整 Xcode（Xcode.app）携带 Apple 各平台 SDK（含 iOS/iPadOS/watchOS/tvOS/visionOS）、Simulator 运行时与 CoreSimulator、与 IDE 紧耦合的 xcodebuild 行为，以及 Archive、导出、部分签名与工程能力所依赖的工具链组合。对绝大多数 iOS 应用 CI 而言，这是事实上的默认选项。
实践中常见误区是：在仅安装 CLT 的机器上强行跑 xcodebuild -scheme … -destination 'platform=iOS Simulator'——若缺少对应 SDK 与 Simulator 栈，失败信息往往指向 SDK 或 destination 不可用，而不是「脚本写错一行」。
场景决策矩阵（独占远程 Mac CI）
下列结论面向独占节点（整台机器归你或归单租户）；若为多租户共享池，还需叠加并发隔离与磁盘配额，此处不展开。
| 场景 | 仅 CLT | 完整 Xcode | 备注 |
|---|---|---|---|
| 仅 macOS 目标构建 / 静态分析 | 通常可行 | 可选 | 需锁定 SDK 与 xcodebuild -version，避免系统升级漂移。 |
| iOS / tvOS 等移动 SDK 构建 | 不足 | 需要 | 需与目标系统版本匹配的 SDK；CLT 无法替代整套 SDK 布局。 |
archive + 导出 IPA / pkg |
不足 | 需要 | 依赖完整工具链与导出选项；签名素材另见下节。 |
| 单元测试（不启 Simulator） | 视目标而定 | 推荐 | iOS 目标通常仍需 Xcode SDK；macOS 目标可评估 CLT。 |
| UI Test / 需 Simulator 的测试 | 不足 | 需要 | 需安装对应 runtime；无头场景还要考虑会话与权限。 |
公证 notarytool / staple |
通常可配合 | 通常可配合 | 关键在 Apple ID / API 密钥与密钥链治理，与「是否装 Xcode.app」无简单一一对应。 |
一句话结论：只要流水线里出现「iOS SDK」「Simulator」「Archive 导出」中的任意一项，就应默认安装完整 Xcode，并把版本号（及是否多版本并存）写进基础设施清单。
归档与签名：装对 Xcode 只是第一步
完整 Xcode 解决的是 SDK 与构建工具；签名与描述文件仍依赖：证书与私钥是否落在构建用户的钥匙串、CODE_SIGN_IDENTITY / PROVISIONING_PROFILE 或自动签名配置是否与 CI 用户一致、以及导出方法（development/adhoc/app-store）是否与分支策略一致。
SSH 无人值守场景下，常见故障不是「没装 Xcode」，而是 非交互会话无法弹出钥匙串解锁 UI、或 security find-identity 在 CI 用户下看不到预期证书。应在 Runbook 中写明：钥匙串创建/解锁策略、证书导入方式、以及是否使用 App Store Connect API 密钥驱动导出与上传，避免把问题误判为「Xcode 没装全」。
Simulator：完整 Xcode + 运行时 + 无头注意点
Simulator 依赖 Xcode 携带的模拟器栈；仅 CLT 无法提供完整 simctl 工作流所需的运行时镜像。独占机器上请预先下载与业务匹配的 runtime，避免 Job 首次运行时临时拉取导致超时。
纯 SSH 无图形界面时，部分测试框架仍假设「可启动模拟器窗口」或依赖辅助功能权限；若遇不稳定，需在架构上评估：是否改为真机农场、是否接受 VNC/屏幕共享排障窗口，或把 UI 自动化限定在有图形会话的专用节点。这与在远程 Mac mini 上通过 SSH 搭建自动化与研发助理类工作流的职责切分思路一致：把「需要 GUI 假设」的步骤隔离到明确的一类 Runner 上。
SSH 无头场景：把可观测性写进同一套清单
独占远程 Mac 上，建议每次 Job 记录：xcodebuild -version、xcode-select -p、swift --version，以及当次 DEVELOPER_DIR（若显式设置）。多 Xcode 并存时，xcode-select 与 Runner 环境变量必须同源，否则会出现「本地 Mac 能编、CI 偶发换 SDK」的疑难问题。
若团队同时关心高峰期算力与节点独占策略，可对照iOS CDD 高峰期租用 Mac 的决策讨论，把「装 CLT 省盘」与「装全量 Xcode 保交付」放到同一套成本与风险框架里评估。
FAQ
只装 CLT，能否用 Homebrew 装齐 iOS 构建环境？
Homebrew 不能合法替代 Apple 官方 iOS SDK 与 Xcode 分发方式；面向 App Store 或真机签名的 iOS 构建仍应以完整 Xcode 与官方文档为准。
磁盘紧张，能不能只装 CLT + 精简？
若业务确属纯 macOS 或后端 Swift，可评估 CLT；一旦涉及 iOS Archive/Simulator，「精简」往往变成反复踩坑与排障时间成本。更稳妥的是：独占机用更大 SSD、或按项目拆分 Runner 画像（构建机 vs UI 测试机）。
多版本 Xcode 并存要注意什么？
统一用 DEVELOPER_DIR 或 xcode-select 在 Job 级钉死版本；避免不同 Job 并行时互相切换全局 xcode-select 导致竞态。
无头 SSH 下 Simulator 黑屏或起不来？
先区分是 runtime 未安装、权限不足，还是测试代码依赖 GUI；再决定是否引入有图形会话的节点或改用真机。不要仅通过「重装 CLT」尝试解决。
在 Mac mini 上，把 Xcode 决策跑稳
完整 Xcode、Simulator 与签名链条，对磁盘、内存与 IO 稳定性都敏感：独占远程 Mac CI 的价值在于「环境可钉死、噪声可重复」。Apple Silicon Mac mini 类机型在统一内存带宽与长期待机功耗上表现突出，适合作为 7×24 构建节点；macOS 与 Unix 工具链原生一体，SSH、xcodebuild 与钥匙串策略也更容易脚本化。结合 Gatekeeper、SIP、FileVault 等机制，面向无人值守场景的总体风险面也低于典型拼凑的 Windows 工作站。
若你正在规划独占远程 Mac CI 的镜像与安装基线，建议直接以「全量 Xcode + 明确版本矩阵」为默认，仅在确无移动 SDK 需求时再收缩到 CLT。若你希望把这条流水线落在静音、低功耗且可长期在线的硬件上，Mac mini M4 是当前性价比极高的起点之一；现在即可通过 SSHMac 选择与你的签名与并发模型匹配的独享机型，让归档与测试真正可预期。