**症状：** 你的 Intel Mac 还能稳定运行现有 iOS CI/CD，但新 SDK 验证和 Xcode 27 已经无法继续沿用旧架构。 **最快解法：** 不要原位升级，也不要一次性退役；暂留 **Xcode 26.6 生产池**，同步建立 **Apple Silicon 的 Xcode 27 验证池**，完成双跑、签名、依赖和故障回退验收后，再分批迁移。截至 **2026 年 8 月 24 日**，Apple Developer Releases 页面列出的最新 Xcode 27 版本是 **Xcode 27 Beta 5**，发布于 **2026 年 8 月 10 日**；其发布说明明确写明：Xcode 27 只能安装并运行在 Apple Silicon Mac 上。([developer.apple.com](https://developer.apple.com/news/releases/?utm_source=openai))
谁该看这篇： 如果你仍以 Intel Mac 运行 iOS 生产流水线，需要制定架构迁移计划，这套时间轴可以直接作为项目 Runbook。 如果你负责脚本、预编译二进制、签名链路或构建资产采购，也可以用文中的准入清单判断：哪些节点能迁，哪些节点只能暂留，哪些节点应该退出。
先锁定边界：Xcode 27 迁移不是一次换机
Apple 已在 Xcode 27 Beta 5 发布说明中确认，Xcode 27 只能安装和运行在 Apple Silicon Mac 上；同时，Xcode 27 Beta 5 要求 macOS Tahoe 26.4 或更高版本。这些是当前 Beta 的官方边界，不代表正式版日期、最终系统要求或所有企业项目兼容结果已经确定。(developer.apple.com)
Xcode 26.6 则于 2026 年 6 月 25 日发布，官方说明显示它要求 macOS Tahoe 26.2 或更高版本。截至本文更新日，Apple 没有在上述资料中给出 Intel Mac 上 Xcode 26.6 的统一退役日期，因此你不能把“Xcode 27 已进入 Beta”直接等同于“今天必须关闭 Intel 构建机”。(developer.apple.com)
因此，迁移项目要拆成三个不同层次：
- Xcode 版本迁移： 从 Xcode 26.6 到 Xcode 27。
- CPU 架构迁移： 从 Intel 的 x86_64 环境到 Apple Silicon 的 arm64 环境。
- 资产退役： 决定旧 Intel 节点何时停止承载生产任务，以及如何销毁账号、凭证、缓存和构建数据。
迁移前四周：把 Intel 构建资产盘点到任务级
不要按照“现有有几台 Mac，就采购几台 Apple Silicon”估算替代容量。构建机真正承载的是任务队列、签名用途、并发峰值和失败恢复路径。
先为每台 Intel Mac 建立资产清单，至少包含以下字段：
| 盘点字段 | 需要记录的内容 | 不记录的风险 |
|---|---|---|
| 节点身份 | 主机名、系统版本、芯片架构、节点标签 | 新旧节点被错误混用 |
| 流水线用途 | PR 验证、单元测试、归档、发布、定时任务 | 迁移顺序无法分层 |
| Xcode 状态 | 当前版本、默认开发者目录、命令行工具路径 | xcode-select 指向错误版本 |
| 签名用途 | Development、Ad Hoc、App Store、企业内部签名 | 归档成功但导出失败 |
| 依赖清单 | Swift Package、CocoaPods、脚本、插件、二进制 | arm64 下出现隐藏阻断 |
| 队列数据 | 任务标签、并发上限、峰值时段、平均排队情况 | 替代节点容量不足 |
| 恢复方式 | 远程重启、Runner 自启动、磁盘清理、人工介入 | 节点重启后长期离线 |
intel-xcode26、apple-silicon-xcode27、signed-release 等任务标签。官方文档说明，任务只有在操作系统、架构和自定义标签同时匹配时，才会被路由到对应节点；节点离线或没有空闲匹配节点时，任务会继续排队，排队超过 **24 小时**还可能失败。([docs.github.com](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow?utm_source=openai))
这意味着标签不是装饰信息，而是迁移期间的安全边界。标签写错，可能让依赖尚未验证的任务直接进入 Apple Silicon 池；标签写得过宽，则可能让 Xcode 26.6 和 Xcode 27 任务争抢同一台机器。
依赖清单要按架构分类
对每一个外部依赖，记录以下判断：
- 是否提供 Apple Silicon 原生版本；
- 是否只能以 x86_64 运行；
- 是否可以通过 Rosetta 作为短期过渡；
- 是否会参与编译、链接、测试或签名；
- 是否存在源码构建方案；
- 负责人是谁，阻断等级是高、中还是低；
- 长期替代方案和最晚处理日期是什么。
Scripts、Build Phases和自定义 Shell 脚本；- 内部下载的 CLI 工具和压缩包；
- 预编译静态库、动态库、插件和测试工具；
- 依赖安装脚本中的架构判断；
- 使用
uname、arch或固定路径的逻辑； - 依赖缓存目录和派生数据目录；
- 需要登录 Keychain、证书或 Provisioning Profile 的步骤。
迁移前两周：先让 Apple Silicon 节点在非生产队列运行
试点节点不要一接入就承载正式发布。先建立隔离节点，只接收非生产任务，并且不要复制长期管理员账号、共享 Keychain 或全部生产凭证。
试点阶段至少完成以下配置：
- 安装目标 macOS，并记录系统构建号。
- 安装 Xcode 27 Beta 版本，固定
DEVELOPER_DIR或等价的 Xcode 选择机制。 - 重新注册 CI Runner 或 Agent，建立新的 Apple Silicon 标签。
- 重建依赖安装步骤，不直接复制 Intel 节点的缓存目录。
- 配置工作区清理、Derived Data 清理和临时文件回收。
- 设置远程重启后的无人值守启动与 Runner 自动恢复。
- 为试点节点配置最小权限的测试签名凭证。
- 保存每次失败的完整日志，包括架构、工具路径和退出码。
xcodebuild archive 创建归档，再用 xcodebuild -exportArchive 导出分发产物。你的试点验收也应保持这个边界，不能只验证“能编译”，还要验证归档内容、导出选项和签名结果。([developer.apple.com](https://developer.apple.com/documentation/xcode/creating-distribution-signed-code-for-the-mac/?utm_source=openai))
代表性项目至少应覆盖：
- Swift 与 Objective-C 混合代码；
- 单元测试、UI 测试和测试计划；
- Debug、Release 与归档配置；
- 内部 Package 或预编译二进制；
- 证书导入、Provisioning Profile 选择；
- App Store、Ad Hoc 或内部分发导出；
- 失败后重新执行与节点重启恢复。
切换前一周：用双跑验证构建、签名和产物
双跑的原则是：同一提交、同一依赖锁定状态、同一构建参数，分别进入 Intel 与 Apple Silicon 池。不要只比较构建耗时，因为企业发布真正关心的是结果可用性和失败后的可恢复性。
| 验收层级 | Intel 池与 Apple Silicon 池都要比较 | 通过门槛 | 失败后的动作 |
|---|---|---|---|
| 编译 | 编译错误、警告、模块接口、链接结果 | 关键目标全部成功，差异有记录 | 定位工具链或架构条件 |
| 测试 | 单元测试、UI 测试、测试计划、模拟器目标 | 失败用例可解释且非架构回归 | 回退到 Intel，保留失败样本 |
| 归档 | .xcarchive 结构、产物清单、符号文件 | 归档目录和关键产物完整 | 检查脚本、路径和构建设置 |
| 签名 | Team、证书、Profile、Entitlements | 签名身份和权限一致 | 隔离 Keychain，重新导入凭证 |
| 导出 | exportOptionsPlist、导出类型、校验结果 | 能生成目标分发包 | 检查导出选项与签名链路 |
| 发布前检查 | 包体、版本号、校验和、上传前脚本 | 结果与基准任务一致 | 禁止进入正式发布队列 |
| 恢复 | 节点重启、Runner 重连、任务重试 | 无人工登录即可恢复 | 暂停放量，修复启动流程 |
签名链路必须单独验收
Apple 将证书、身份和密钥归入 Keychain Services 的管理范围；Keychain 可用于保存密码、证书和加密密钥。对构建机而言，这意味着“把旧节点整个用户目录复制到新节点”不是可靠的迁移策略，凭证导入、访问权限和清理动作都应独立记录。(developer.apple.com)
你应为签名验收建立独立结果：
- 新节点是否只拥有完成测试所需的凭证；
- 非签名任务是否无法访问发布凭证；
- Keychain 解锁是否能在无人值守流程中稳定完成；
- 归档后的签名身份、Entitlements 和导出类型是否符合预期；
- 任务结束后，临时证书、Profile 和工作目录是否被清理；
- 节点回收时是否能删除本地账号、凭证、缓存与日志。
⚠️ Rosetta 只能作为兼容性过渡，不能自动证明整条流水线已经完成架构迁移。凡是涉及预编译二进制、构建插件、测试工具或脚本解释器的任务，都应记录“原生运行”与“Rosetta 运行”的差异。
切换窗口：先迁非签名任务，再迁正式发布
切换不要按“节点上线即全部转流”执行，而应按风险从低到高分批推进：
- 第一批： PR 验证、静态检查、非签名编译。
- 第二批： 单元测试、UI 测试和定时构建。
- 第三批： 归档、符号文件处理和内部测试分发。
- 第四批： Ad Hoc、App Store 或正式发布任务。
- 旧 Intel 节点仍在线且使用 Xcode 26.6；
- 旧节点的证书和 Profile 尚未被误删；
- 工作区和依赖缓存仍可重新生成；
- 发布任务没有同时在两个架构池中重复执行；
- 失败任务能够被重新排队到明确的兼容池。
建议把每个节点的状态分为三类：
- ✅ 保留： 仍承载明确的 Xcode 26.6 任务，并且有必要的回退价值。
- ⚠️ 限制： 只接受兼容性验证、旧版本维护或非关键任务。
- ❌ 退出： 已完成迁移，且已完成账号、凭证、数据和资产销毁。
迁移后首月：用证据决定购买、租赁还是混合部署
由于当前没有可直接引用的 MACGPU 后台交付记录、真实节点可用配置和代表性构建实测数据，本文不预填节点数量、租赁价格、地域交付时间或性能提升比例。你在正式采购前，应把这些数据从实际试点记录中补齐，而不是用硬件宣传参数推算企业产能。
可以用下面的评分表做最终决策：
| 评估项 | 购买 Apple Silicon | 按需租赁 Apple Silicon | 混合部署 |
|---|---|---|---|
| 长期稳定重负载 | 适合 | 需要核算长期单价 | 核心池适合 |
| 短期 Xcode 27 验证 | 前置投入较大 | 适合快速试点 | 适合保留旧池 |
| 峰值队列弹性 | 扩容周期较长 | 更容易临时补充 | 兼顾稳定与弹性 |
| 物理设备接口需求 | 更可控 | 需确认远程接入边界 | 关键设备本地保留 |
| 维护与故障恢复 | 由企业承担 | 需核对服务承诺与恢复流程 | 按任务风险拆分 |
| 资产退役压力 | 形成折旧与闲置资产 | 减少一次性采购 | 需要管理两套资产 |
你可以先通过 MACGPU 的 Apple Silicon Mac 方案申请隔离验证节点，再把自身项目的队列、失败率、环境准备和重启恢复记录纳入采购评审。如果团队对地域延迟或跨区域访问敏感，也应结合 不同地域的 Mac 节点方案比较实际连接路径，而不是只看芯片名称。
最后，执行以下准入清单；任何一项没有证据，都不要把对应任务迁入正式 Apple Silicon 池：
- [ ] 已为每台 Intel Mac 建立任务、Xcode、签名和依赖清单。
- [ ] 已冻结生产池环境，并保存安装清单、构建日志和基准任务。
- [ ] 已建立隔离的 Apple Silicon 试点节点。
- [ ] 已为新节点重新配置 Runner、Agent、标签和任务路由。
- [ ] 已验证 Swift、Objective-C、测试、归档和内部依赖。
- [ ] 已逐项识别 x86_64 工具、二进制、插件和脚本。
- [ ] 已完成 Intel 与 Apple Silicon 的同提交双跑。
- [ ] 已验证签名、归档、导出和发布前检查。
- [ ] 已验证节点重启后的无人值守恢复。
- [ ] 已为每个迁移阶段保留可执行的 Intel 回退路由。
- [ ] 已记录 Rosetta 过渡项及其长期替代方案。
- [ ] 已用真实队列和恢复记录核对替代容量。
- [ ] 已决定 Intel 节点是保留为 Xcode 26.6 兼容池、限制用途，还是退出。
- [ ] 退出节点前已完成账号、凭证、缓存、日志和本地数据销毁。