平台与移动端工程负责人在 2026 年把 iOS/macOS 构建迁到远程 Mac 时，常见误区是「先注册 Runner 再想办法」——结果标签语义混乱、并发把磁盘打满、密钥与签名上下文串线。本文面向已在 新加坡、日韩、港、美东、美西 等节点选定或即将选定机器的团队，给出痛点拆解、两张对照表、可粘贴的 workflow 片段、六步落地 Runbook 与三条硬口径；并与站内《多项目资源池》《SSH 与 VNC》互补，直接服务 CI 评审与租期落单。
自托管 Runner 的本质是把可执行的 macOS 环境暴露给编排平面：GitHub Actions 用仓库级与组织级 Runner，GitLab 用 Group/Project Runner 与执行器类型。若标签只写成 mac、ios 这类泛化词，workflow 会无序争抢同一台机器；Xcode 与 DerivedData 的 IO 热点叠加后，失败表现为随机超时而不是清晰的资源不足。📌 先把下面六类痛点拆开，再谈加机或升档 M4 Pro。
jobs 并行度若高于磁盘与元数据锁能承受的阈值，会出现全员变慢；需要把「单 Runner 最大并行 job 数」写进运维文档而非依赖默认值。clean 可能拖垮并行项目。.xcarchive 或依赖缓存的同步会把省下的机器钱换成带宽与人时。下面两张表把「Runner 角色」与「GitHub/GitLab 控制面差异」压成可评审结构；再给出 YAML 映射示例与落地步骤。
本篇与《多项目资源池》分工如下：后者讲队列与租期组合；本篇讲如何把一台远程 Mac 注册为 Runner 并让 workflow 稳定命中正确环境。表 1 用于与架构评审对齐。
| 维度 | 共享 Runner 池（多仓库/多团队） | 独占构建机（项目或发布线绑定） |
|---|---|---|
| 典型 job | Lint、单测、轻量 xcodebuild、不触发生产签名 | 归档、上传 TestFlight、多模拟器矩阵、长期签名流水线 |
| 标签策略 | 细粒度：macos-14、xcode-16、no-signing 等可组合标签 | 可加项目专属标签，禁止其他仓库 runs-on 命中 |
| 并发建议 | 保守并行 + 队列溢出转峰值机 | 并行度与磁盘监控绑定，优先稳定而非满载 |
| 密钥与账号 | 独立 CI 用户、独立钥匙串文件或分区策略 | 固定签名身份、轮换窗口与审计责任人 |
| 何时优先 | 多项目低耦合、可接受短暂排队 | 合规、客户交付或发布门禁要求可复盘环境 |
两者都能驱动远程 Mac，但密钥注入点、Runner 可见范围、缓存策略不同。下表用于平台组与研发统一术语（具体字段名以各平台当前文档为准）。
| 维度 | GitHub Actions（自托管） | GitLab Runner（shell/ssh 执行器） |
|---|---|---|
| 调度入口 | 仓库/组织 Runner + runs-on: [self-hosted, …] | tags 匹配 + Runner 注册级别（project/group/instance） |
| 密钥习惯 | Secrets/Variables、Environments；可结合 OIDC 换云侧短期凭证 | CI/CD Variables、Masked 变量；注意 Group 继承与保护分支 |
| 并发旋钮 | Job 级矩阵与 Runner 侧进程上限需自建约束 | concurrent 与 per-runner 配置；多 executor 慎用同一用户 |
| 典型坑 | 自托管默认可能继承交互式登录环境变量 | 同一机器多 Runner 进程争用 Xcode 许可或端口 |
# GitHub Actions：用标签把 job 绑到「能力」而非泛泛的 macOS
jobs:
ios_build:
runs-on: [self-hosted, macOS, xcode-16, m4-ci]
concurrency:
group: ios-${{ github.ref }}
cancel-in-progress: true
steps:
- uses: actions/checkout@v4
- name: Select Xcode
run: sudo xcode-select -s /Applications/Xcode_16.app
# GitLab CI：用 tags 映射到同一台远程 Mac 上的 Runner
ios_build:
tags: [macos, xcode16, m4-ci]
script:
- xcodebuild -version
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
提示：标签名应在内部 Runbook 登记「对应 Xcode 路径、是否允许签名、最大并行 job 数」，避免新人复制粘贴过时 workflow。
下列步骤假设你已根据《多地区节点与租期指南》初步选定区域；连接方式见《SSH 与 VNC 决策》。
下列指标可直接改成 Grafana/Datadog 字段名或周报表头。
若三项指标在独占机构机场景下稳定两周，再评估加第二台或改用 M4 Pro 做重并行矩阵。
补充实践口径：当 xcodebuild 与 Swift Package 解析同时跑满网络与磁盘时，P95 往往先被「索引与缓存写入」拖长，而不是编译器本身；此时在监控里同时打开「队列长度」与「磁盘 await」比只看 CPU 利用率更能定位该不该加机。另一点是与《买租 TCO》对齐——Runner 的在线小时数与租期账单应能解释「为什么这台机器必须独占」，否则评审会反复质疑共享池是否足够。
嵌套虚拟化下的 macOS 构建往往在 Metal、代码签名与 USB 调试上摩擦更大；个人笔记本合盖休眠与系统更新也会把无人值守变成随机失败。要把 Apple Silicon 当生产构建层，需要物理机独占、地区可选、租期可组合，并把 Runner 标签与并发策略写进合同范围内的运维基线。
仅依赖碎片化桌面或「临时借一台」很难为长期 Gateway、AI Agent 执行层或多仓库 CI 提供稳定 SLA：权限弹窗与不可控更新会持续消耗排障人时。MACCOME 提供多地区 Mac Mini M4 / M4 Pro 物理节点与弹性租期，适合作为自托管 Runner 的基线执行层与可验收峰值补充；读完节点选择、SSH/VNC 与多项目资源池类文章后，可在价格页对齐套餐并按区域公开页落单。
若仍处于试点阶段，建议先用短租在同一区域验证 artifact 路径与 Runner 标签，再决定是否把基线从月租扩展到季租，避免现金流锁在错误档位。
常见问题
应该先加 Runner 还是先收紧标签与并发？
多数团队应先冻结标签语义与单 Runner 并行上限，再观察队列与磁盘。需要对照单价与周期时，可打开 租赁价格说明，并结合《多地区节点与租期指南》选区。
GitHub 与 GitLab 在密钥治理上最该对齐的一点是什么？
两边都要避免长期密钥进仓库，并在 Mac 侧用独立用户隔离签名上下文；接入细节仍可对照《SSH 与 VNC 接入决策》与 帮助中心。
多项目并行时还需要读哪篇？
建议继续读《多项目资源池与租期组合》，把 Runner 角色与队列策略一并写进里程碑。