截至 2026 年 11 月 2 日，GitHub 已退役 macOS 14 Runner 的 macos-14、macos-14-large 和 macos-14-xlarge 标签；先按项目的 macOS、Xcode 和 CPU 架构要求筛选仍受支持的 Runner，再隔离试跑构建、测试与交付，不要直接改成 macos-latest。退役公告确认了日期和受影响标签；可用标签及镜像软件则要查阅当前 Runner 文档与镜像仓库。

仍在工作流中使用旧标签的 Apple 平台开发团队，应先盘点受影响任务并安排迁移。
负责签名、测试和发布的 CI 工程师，需要用真实流水线验证新环境。
DevOps 或研发平台负责人，可以据此设定切换准入与回退标准。

最后更新于 2026 年 11 月 8 日；退役日期核实自 GitHub 官方公告，可用标签与镜像信息核实自 GitHub-hosted runners 文档及 runner-images 仓库。

先盘点标签与任务覆盖

macos-14 系列标签已不能作为可运行任务的依据。GitHub 的退役公告列出上述三个标签，并给出迁移方向；但公告中的建议不是所有架构、规格或工具链组合都适用的承诺。迁移前还应以 GitHub 当前文档和镜像仓库的实际清单为准。

macos-14 Runner 退役后，工作流该选什么标签？
先判断工作流需要 Intel 还是 Apple Silicon，再根据项目的系统版本和 Xcode 基线筛选标签。当前镜像清单区分了 macos-15、macos-26 等 Apple Silicon 标签，以及 macos-15-intel、macos-26-intel 等 Intel 标签；较大型规格也有对应名称，但要核对账号可用性和 GitHub 文档，不要只凭名称推定资源规格。

从仓库工作流文件搜索 runs-on，把每个旧标签对应的任务登记下来：哪些任务只做编译，哪些会启动模拟器，哪些负责签名、归档或发布。再检查历史运行日志中的 Runner 标签、操作系统、Xcode 版本、架构与依赖安装方式，避免只替换主流水线而漏掉手动触发、发布分支或复用工作流。

macos-latest 会随 GitHub 的迁移计划指向新系统，并非固定版本别名。它适合主动接受系统更新、且有持续回归验证的项目；若发布构建依赖可复现的环境，应先选定具体系统标签，并显式检查 Xcode 选择逻辑。

核对系统与 Xcode 工具链

Runner 标签描述的是执行环境，不等于项目所需的工具链已经就绪。系统版本、Xcode、SDK、编译器以及模拟器运行时之间存在兼容条件；例如，Apple 的 Xcode 26 发布说明要求运行环境至少为 macOS Sequoia 15.6。项目若仍依赖更旧系统或特定 SDK，不能仅因新 Runner 能启动就判定迁移完成。Apple 的 Xcode 26 发布说明与Xcode 系统要求可用于核对版本和兼容性。

从 macOS 14 迁移到 macOS 15 或 macOS 26，要先验证哪些条件？
对照项目明确锁定的 Xcode 和 SDK 版本检查系统要求，并在候选镜像的软件清单里确认对应版本是否存在。还要区分正式版与 Beta：Apple 发布说明标注的版本状态应与团队发布要求一致，不能把预览版能编译当作生产环境已兼容。GitHub 镜像会更新，迁移验收时应记录实际运行的镜像和工具链，而不是依赖旧日志中的结果。

在隔离分支或临时工作流中打印环境基线，便于对照前后差异：

- name: Record runner baseline
  run: |
    sw_vers
    uname -m
    xcodebuild -version
    xcode-select -p
    xcodebuild -showsdks

如工作流需要特定 Xcode，应明确选择并确认命令行工具指向预期版本；不要把镜像默认 Xcode 当成项目配置。

验证架构与原生依赖

Intel 构建任务在旧标签退役后怎么安排？
如果项目必须产出或验证 Intel 原生二进制，或依赖尚未确认支持 Apple Silicon 的工具、预编译库和脚本，应优先验证当前文档列出的 Intel Runner 标签；若依赖已支持 arm64，则可另行试跑 Apple Silicon 标签，但不能把一次成功启动视为完整兼容证明。当前镜像仓库分别列出 Intel 与 arm64 标签，迁移时必须查清实际执行架构。

逐项检查依赖，不要只看主程序是否能编译：

  • 对预编译库和命令行工具检查二进制架构，例如使用 file 或 lipo -info。
  • 重新执行依赖安装、原生模块编译和单元测试，留意脚本中是否写死 Intel 路径或依赖特定包管理器前缀。
  • 对涉及模拟器的任务确认目标设备与运行时存在，并运行实际测试，而非只验证 xcodebuild 能列出工程目标。
  • 对架构尚未明确的私有依赖，单独记录其支持范围；无法确认时保留兼容架构的执行路径，不要直接切断旧构建方式。

托管镜像也有维护边界：镜像会更新，常用工具可能改变默认版本；GitHub-hosted Runner 的作业从干净镜像启动，依赖通常需要重新获取。缓存可帮助复用依赖，但它不能替代依赖可重新下载的能力，也不应存放密钥。

验收构建、测试与签名交付

Runner 标签换好后，怎样确认 Xcode 和模拟器测试正常？
以同一提交在旧基线记录和新候选环境中运行代表性任务，逐一比对 clean build、项目测试、模拟器目标、归档和签名结果。只有关键交付链路均有证据，才进入切换评审；单次构建通过并不能证明私有依赖、发布凭据或模拟器行为没有变化。

建议在隔离分支中复制生产工作流，并按阶段保存日志和产物信息：

  • ✅ 构建：清理构建产物后重新构建，确认没有依赖旧 Runner 缓存或本机残留。
  • ✅ 测试：运行项目实际采用的单元测试与模拟器测试，核对目标设备、测试结果及失败日志。
  • ✅ 归档与签名：验证 Archive、签名身份、配置文件和导出步骤；不要把凭据写入日志或缓存。
  • ✅ 发布准备：在不会触发正式发布的条件下验证产物命名、签名状态与上传前检查。
  • ⚠️ 复现能力：保存 Runner 标签、系统版本、Xcode 版本、架构、提交标识和关键产物信息，便于后续追溯差异。

迁移期间不要让试跑任务意外发布生产版本。可在临时工作流中限制发布步骤，确认凭据作用范围，并把“构建通过”和“允许交付”设为两个不同的判断。

如果采用矩阵同时测试候选标签，可通过 fail-fast: false 避免其中一个候选失败时取消其他候选；候选任务应设置为验证用途，不应因测试矩阵通过而自动越过发布审批。GitHub 的矩阵工作流文档说明了矩阵失败处理方式。

评估网络与运维约束

托管 Runner 与自有 macOS 执行环境的责任分配不同。托管 Runner 减少了机器维护工作，但私有依赖访问、缓存复用和工作流凭据仍需团队验证；自托管 Runner 可以由团队管理环境和网络接入，也意味着团队要承担机器维护、Runner 更新、网络连通性与隔离等责任。GitHub 文档要求自托管机器能够与 Actions 服务通信，并具备工作流所需的网络访问，详见自托管 Runner 网络与运维要求。

迁移时分别确认私有包仓库、源码子模块、证书或密钥服务在新环境中是否可访问；若网络策略依赖固定来源地址或特定内网路径，先核对候选执行方式能否满足要求，不要从旧 Runner 的运行记录推断新环境一定可达。缓存也要重新验证命中与失效行为，确保缓存不可用时仍能重新安装依赖；GitHub 文档明确区分依赖缓存与运行产物，并提醒不要在缓存中放置敏感信息，具体规则见依赖缓存说明。

按迁移条件决定切换或回退

下面的分支可作为准入判断，而不是对任一标签的通用推荐：

  • 若项目的 Xcode、SDK 和系统要求已在候选镜像中确认，且依赖支持该架构，选择对应的固定标签，先在隔离工作流完成构建、测试与交付验收，再切换主流程。
  • 若项目需要 Intel 二进制或尚未验证的原生依赖，先验证当前可用 Intel 标签；若找不到满足工具链基线的环境，保留独立兼容执行方案，不要直接迁往 arm64。
  • 若只是想跟随 GitHub 的系统更新，且团队有持续回归能力，可以评估 macos-latest；若发布稳定性依赖固定系统，则不要把它当成无风险替代。
  • 若签名、网络或模拟器验收仍有失败项，维持候选环境与生产环境分离，修复后再复测；不得以构建成功作为全部迁移准入。

切换前最后检查：✅ 所有旧标签已从工作流与复用配置中盘点；✅ 候选 Runner 的实际系统、架构与 Xcode 已留档；✅ 构建、测试、签名与归档均有同一提交的验收记录；✅ 私有依赖和凭据路径已确认；✅ 有明确的失败回退方式。团队也可先阅读 RUVCLOUD 的远程 Mac 环境说明，判断持续访问真实 Mac 是否能补足特定工具链验证或自有执行环境的需求。

macOS 14 Runner 退役后，直接追随 latest 容易带来工具链漂移；长期维护自有 Mac 则要承担硬件管理、系统更新和网络安全责任；通用 Linux 执行环境又不能替代 Xcode 与 Apple 平台签名链路。若团队只在迁移复验、临时构建或阶段性测试时需要真实 Mac，按需租赁可避免先购置硬件，也比把所有 Mac 运维责任都留给团队更灵活；可以查看 RUVCLOUD 远程 Mac 方案与计费信息，再按项目持续时间和实际环境要求评估。