流水线报错提示 arm64 Runner 没有固定 UDID，开发签名或真机测试因此停住。
先别急着换节点：GitHub Actions arm64 Runner 固定 UDID 缺失，不会自动阻断一般 iOS 构建、模拟器测试或面向 App Store 的发布。先确认缺的是 Mac 主机标识还是 iPhone 测试设备标识；只有任务确实依赖固定 Mac 标识，才评估替代节点。
适合负责 GitHub Actions、macOS Runner 选型和代码签名的 IT、平台工程负责人。
如果你正在排查构建失败、开发签名或真机验收，下面的任务分类和检查清单可以直接用于流水线复核。
最后更新于 2026 年 10 月 4 日；UDID 与 Runner 能力核实自 GitHub 较大 Runner 文档及 Apple Developer 设备注册文档。发布前仍应检查官方 Runner 标签和预览状态是否有变化。
01 先定位失败环节，而不是先换 Runner
GitHub 文档说明，arm64 macOS Runner 没有静态 UUID／UDID；文档同时列出 Intel macOS Runner 的静态 UDID 选项。这个限制说的是 Runner 所在的 Mac 主机，不是你的 iPhone 测试设备。Apple Developer 资料则说明，开发或 Ad Hoc 配置文件需要已注册的设备。两种标识服务于不同对象，不能互相替代。
| 当前任务 | 通常是否要求固定 Runner Mac UDID | 优先核查项 |
|---|---|---|
| 编译 iOS 应用并生成归档 | 通常不要求 | Xcode 构建结果、签名方式、归档是否生成 |
| 运行 iOS 模拟器测试 | 通常不要求 | Runner 是否提供所需模拟器运行环境，测试是否完成 |
| 给注册的 iPhone 安装开发版 | 不能只看 Runner UDID | iPhone 是否已注册、开发配置文件是否包含该设备 |
| 在实体 Mac 上测试 Mac 应用 | 可能涉及 Mac 设备注册 | Mac 目标、开发配置文件、计划测试的主机 |
| 上传构建并提交商店发布 | 通常不以固定 Runner UDID 为前提 | 分发签名、上传结果、App Store Connect 构建记录 |
这是任务分流表，不是对每个项目构建配置的保证。把失败步骤定位到“编译、签名、安装、上传”中的具体一环，再看对应的验收证据。GitHub 将托管 Runner 描述为由 GitHub 托管的虚拟机；Apple 的 App Store Connect 构建上传流程围绕构建文件和处理状态展开。不要把开发配置文件的设备注册规则泛化到所有商店上传任务。
02 Mac 主机与 iPhone 的设备标识不能混用
Runner Mac 的 UDID 指向执行 CI job 的 Mac 主机；iPhone UDID 指向实际安装、运行应用的 iPhone。模拟器是软件测试目标，既不是实体 iPhone，也不会因为 Runner 是 arm64 就变成已注册设备。
Apple 允许在开发者账号中注册设备，并说明创建开发或 Ad Hoc 配置文件需要注册设备；注册设备需要提供设备名称和设备 ID。Apple Silicon Mac 用于开发注册时，Apple 还要求提供 provisioning UDID。判断签名条件时，要先确认目标平台与设备类型，不能只凭 UDID 这个字段名推断。
GitHub-hosted macOS Runner 缺少固定 UDID，会影响 iOS 开发签名吗？
先看签名目标。iOS 开发签名用于将应用安装到已注册的测试设备；这一步要核实的是实际测试设备是否已注册、配置文件是否包含目标设备，以及证书是否匹配。arm64 Runner 的 Mac 标识缺失，不能代替对这些项目的检查，也不能直接当作 iPhone UDID 缺失。
Apple 对开发和 Ad Hoc 配置文件分别列出要求；创建开发配置文件时要选择设备，创建 Ad Hoc 配置文件时也要选择测试设备。相对地，App Store Connect 的上传流程围绕构建文件处理。请勿因为流水线包含签名步骤，就推断所有签名或商店发布都依赖固定 Runner Mac UDID。
| 签名／分发目标 | 设备注册检查 | 建议通过证据 |
|---|---|---|
| 开发版安装到 iPhone | 核实目标 iPhone 已注册且包含在开发配置文件中 | 安装成功、应用启动、设备与 profile 信息一致 |
| Ad Hoc 安装到测试设备 | 核实测试设备列表与配置文件中的设备相符 | 目标设备安装成功、测试记录可追溯 |
| 上传 App Store Connect | 不要把开发设备列表要求直接套用到上传任务 | 上传处理完成、构建版本可在后台核对 |
Apple Developer 账号里的设备列表、配置文件和测试设备清单也需要维护。禁用设备不会增加当年的可用设备名额；若更换测试机或调整名单，应核对配置文件是否需要更新或重新生成。(Apple 配置文件管理文档说明了编辑、下载或重新生成配置文件的场景。)
03 真机测试需要独立的实体设备链路
GitHub-hosted Runner 能否直接连接 iPhone 做真机测试？
不要把 GitHub-hosted Runner 当作已经接好你手边 iPhone 的 Mac。GitHub 文档说明，托管 Runner 由虚拟机执行；你应按实际工作流确认设备连接方式，而不是从“任务运行在 macOS 上”推定存在 USB 连接或设备访问能力。需要实体设备测试时，把设备连接、测试执行和结果回传作为单独的验收链路。
可选方案包括由你管理并连接设备的自托管 Mac Runner，或另行管理的设备测试环境。自托管 Runner 能让你控制硬件和工具，但操作系统与软件更新也由你负责；Runner 在线只说明它可以接收任务，不代表设备权限、证书保管、环境隔离或测试结果都已达到生产要求。GitHub 的自托管 Runner 参考文档列明了主机运行与通信要求。
04 固定 Mac UDID 的适用边界
固定 Mac 标识可能是目标平台、开发配置文件或测试方式的准入条件，但不能据此认定所有 GitHub Actions 构建任务都受影响。GitHub 当前较大 Runner 文档列出 Intel macOS Runner 的静态 UDID，并说明 arm64 macOS Runner 没有静态 UUID／UDID；若确需静态 UDID，文档建议使用 Intel Runner 并将其 UDID 添加到 Apple Developer 账号。采用该选项前，先核实所选 Runner 标签、架构和当前可用状态。
| 节点路径 | 适用判断 | 主要权衡 |
|---|---|---|
| 保留 GitHub-hosted arm64 Runner | 普通构建、模拟器验证、分发上传等任务没有固定 Mac UDID 依赖 | 继续使用现有流水线，但先核对工具与架构兼容性 |
| 采用文档列出的 Intel macOS Runner | 任务证据表明确实需要静态 Mac UDID，且该节点符合目标流程 | 需确认当前标签、可用性及工具链要求；不因此自动解决 iPhone 连接问题 |
| 自托管或专用远程 Mac | 需要受控主机、特定 Mac 环境，或需要自行连接实体设备 | 你负责节点更新、权限隔离、设备接入、凭证管理和恢复预案 |
GitHub 文档指出，自托管 Runner 可以由你部署和管理。对于包含非可信代码的工作流，尤其要防止密钥和内部资源暴露，并避免不安全地复用 Runner 环境；GitHub 的自托管 Runner 安全说明明确要求限制 Runner 对内部资源的访问，并避免跨运行复用不安全的环境。
05 按流水线证据完成准入验收
把判断写进一次可复现的流水线试点。按下面的顺序执行，避免只凭某条报错或 Runner 标签作采购决策：
- [ ] 定位失败步骤。 记录 job、Runner 标签、目标平台，以及失败发生在编译、签名、安装、测试还是上传阶段。
- [ ] 记录目标设备。 标明任务目标是模拟器、iPhone，还是 Mac；需要实体设备时，记录设备连接方式和设备标识归属。
- [ ] 审查签名输入。 核对证书、Keychain、App ID、开发／分发配置文件和设备列表；不要把签名私钥无边界地放进可被非可信代码访问的 job。
- [ ] 分开验证结果。 构建成功只证明产物生成；签名验证、测试设备安装、测试通过和 App Store Connect 上传应分别留下证据。
- [ ] 核对 Runner 支持状态。 对照 GitHub 当前文档确认架构、标签、静态 UDID 说明和预览状态；发生变化时重新评估流水线路由。
- [ ] 审查主机隔离。 若引入自托管节点，检查谁能触发任务、哪些密钥可用、Runner 是否会残留工作区或被不可信任务复用。节点可登录不等于生产安全。
- [ ] 根据失败证据决定扩容。 只有在固定主机标识、实体设备连接或受控签名环境确实阻断目标任务后，再试点专用 Mac；保留不受该限制的托管任务，避免不必要的整体迁移。
06 按工作负载选择节点
如果失败只出现在普通编译或模拟器测试，先修正 Runner 标签、工具兼容性或任务配置；不要因为 arm64 节点没有固定 UDID 就迁移整条流水线。如果问题来自真实设备注册、实体设备连接或特定 Mac 主机签名，才把相应节点纳入隔离试点，并用设备安装、签名验证和发布制品记录判定通过。
在这些边界明确之前，直接采购 Mac 会增加设备管理、更新、凭证保护和闲置容量成本；把所有任务继续放在托管 Runner 上，则可能无法满足实体设备接入或主机环境控制要求。若你需要临时或阶段性的专用 Mac 测试环境，可按团队的访问方式和使用周期了解 CALMVPS 的远程 Mac 方案，并先对照 套餐与计费信息评估是否适合该流水线。若当前任务只是构建或模拟器验证，保留现有 Runner 并按清单验收，通常比仅因 UDID 一词整体换节点更稳妥。