本文面向以 Linux CI 为主、需要发布 macOS 软件的开发者和平台工程师。文章沿制品生成、Developer ID 签名、公证提交、状态查询、票据装订与最终验证的时间线，判断哪些环节可以放在通用节点，哪些环节应保留真实 Mac，并给出仅 Mac、混合 CI 与按需 Mac 节点的选择条件。
本文面向以 Linux CI 为主、需要发布 macOS 软件的开发者和平台工程师。文章沿制品生成、Developer ID 签名、公证提交、状态查询、票据装订与最终验证的时间线，判断哪些环节可以放在通用节点，哪些环节应保留真实 Mac，并给出仅 Mac、混合 CI 与按需 Mac 节点的选择条件。
macOS App 公证需要 Mac 吗？如果流水线只负责向 Apple 提交已签名制品并查询结果，Linux CI 可以承担这部分工作；如果还要构建、Developer ID 签名、票据装订或本地验证，就应保留真实 Mac。
对多数团队，最快的落地方式不是把整条链路搬到 Mac，而是让通用 CI 负责编排、制品传递和状态记录，再让远程 Mac CI 完成 macOS 专属交付闭环。
这篇文章适合 3 类人：
很多团队把“上传到 Apple 公证服务”误认为“macOS 发布完成”。实际上，交付链路至少包括制品生成、代码签名、公证提交、状态查询、日志处理、票据装订和最终验证。
Apple 的官方流程建立在一个前提上：提交给公证服务的软件应先完成 Developer ID 签名。公证不是 App Review，也不能替代代码签名；它主要负责对软件执行自动化检查，并在通过后生成供 Gatekeeper 使用的票据。Apple 公证流程说明
| 阶段 | 主要输入 | 通用 Linux CI | 真实 Mac CI | 阶段验收结果 |
|---|---|---|---|---|
| 构建与归档 | 源码、依赖、Xcode 工程 | △ 取决于工具链 | ✅ 通常需要 | 可重复生成归档 |
| Developer ID 签名 | 待签名 App、权限配置、证书身份 | △ 需单独验证 | ✅ 推荐 | 签名身份和权限验证通过 |
| 公证提交 | 已签名 .zip、.dmg 或 .pkg |
✅ Notary API 可行 | ✅ notarytool 可行 |
获得提交标识 |
| 状态与日志 | 提交标识 | ✅ | ✅ | 保存状态和原始日志 |
| 票据装订 | 通过公证的最终制品 | ❌ 不应作为默认方案 | ✅ 使用 stapler |
最终文件完成装订 |
| 本地验证 | 最终分发文件 | △ 可做哈希和结构检查 | ✅ 推荐 | 制品可被 macOS 验证 |
真正的判断标准不是“能不能发送 HTTP 请求”，而是最终交付对象是否经过正确签名、装订和验证。Apple 的工作流也把 notarytool、Notary API、stapler 和本地验证分别处理，而不是把它们合并为一次上传动作。Apple 自定义公证工作流
如果流水线已经拿到一个结构正确、能够重复生成的待提交制品，Linux CI 可以承担哈希计算、归档传输、公证 API 调用和状态轮询。
但如果流水线从 Xcode 工程开始构建，情况就不同。包含 App Extension、Framework、插件、Helper 或命令行工具的 macOS App，需要在构建阶段确定目录结构、嵌套关系、权限配置和后续签名顺序。Apple 的分发文档也将 Xcode 归档、导出分发制品和外部签名流程分别处理。Apple 分发签名代码说明
因此，构建阶段的验收不能只检查“文件生成成功”，还应检查：
Linux CI 能不能承担 macOS 软件的公证提交？
可以，但需要把“提交”与“完整发布”拆开。Linux 节点可以通过 Apple Notary API 创建提交、上传制品、查询状态并取得日志；这并不等于它能够自然完成 Xcode 构建、Developer ID 签名、stapler 票据装订和 macOS 本地验证。
如果团队已经能从其他节点稳定生成正确签名的 .zip、.dmg 或 .pkg，可以先把 Linux CI 用作提交层。若制品仍需在流水线内构建和签名，就应把这些任务放到远程 Mac CI。
公证服务检查的是已经签名的 macOS 软件。Apple 的发布文档说明，直接分发的软件需要使用相应的 Developer ID 身份；App、磁盘映像和安装包等不同对象，也可能需要分别处理签名。Apple Mac 软件打包文档
签名阶段至少要验证 4 个边界：
Apple 还提醒，复杂产品不应简单依赖 codesign --deep 完成全部处理，因为不同嵌套代码可能需要不同的签名选项和权限。发布版本也要检查不适合生产分发的调试权限是否被清除。Apple 代码签名说明
| 签名与权限检查 | 专用远程 Mac | 共享 Mac 节点 | 外部签名步骤 |
|---|---|---|---|
| 钥匙串隔离 | 评分：★★★★★ | 评分：★★★☆☆ | 评分：★★★☆☆ |
| 适合无人值守 CI | 评分：★★★★★ | 评分：★★★☆☆ | 评分：★★☆☆☆ |
| 临时接入成本 | 评分：★★★☆☆ | 评分：★★★★☆ | 评分：★★★☆☆ |
| 故障定位清晰度 | 评分：★★★★★ | 评分：★★☆☆☆ | 评分：★★☆☆☆ |
| 适合高频发布 | 评分：★★★★★ | 评分：★★★★☆ | 评分：★★★☆☆ |
这张评分表比较的是权限和运维边界，不是编译速度排名。对于含有生产签名凭据的流水线，我们更看重执行账户、钥匙串状态、审计记录和重启后的恢复能力。
验收证据至少应包括：
codesign 对目标 App 和嵌套代码的验证结果；security find-identity 是否找到预期身份；如果团队正在准备独立的签名节点，可以将 远程 Mac Developer ID 签名环境 作为部署规划入口，但不要把租到一台 Mac 直接等同于签名环境已经合格。
notarytool 或 Notary API已有 Mac 节点时，通常优先评估 notarytool；由 Linux CI 统一编排提交和查询时，再评估 Notary API。
notarytool 适合在真实 Mac 上快速接入。它可以提交制品、等待结果、输出状态，并配合脚本保存日志和处理失败退出码。
Apple Notary API 则适合由 Linux 或其他通用节点调用。官方文档说明，Notary API 可以绕过 notarytool，直接通过服务端接口完成提交、状态查询、日志获取和历史提交查询。Apple Notary API 概览
两条路径的差异主要集中在运维责任：
notarytool：Mac 侧命令行接入更直接，适合已有 Mac 构建节点的团队；stapler 装订和本地 Gatekeeper 验证。Notary API 的提交接口会返回提交标识和用于上传的临时凭据。Apple 文档说明，这类临时上传凭据取得后 12 小时 过期，因此 CI 不应把它当作长期缓存的访问令牌。Apple Submit Software 接口
提交阶段应保存以下信息：
公证状态变为成功，不等于交付文件已经完成。对于 App、磁盘映像和扁平安装包，通常还需要根据最终分发格式完成票据装订，并对最终文件进行验证。
Apple 说明，票据可以在线交由 Gatekeeper 查询，但将票据装订到软件中，可以让用户在没有网络连接时完成相应验证。stapler 可以处理 App、Bundle、磁盘映像和扁平安装包，但不能直接把票据装订到 ZIP 文件；如果最终交付格式是 ZIP，应先对其中的 App 完成装订，再重新创建 ZIP。Apple 票据装订说明
哪些环节应固定放在真实 Mac 上？
如果发布链路包括以下任一动作，就应把相关阶段放在真实 Mac：
stapler staple；stapler validate 和 spctl 等本地验证；最终验收对象必须是实际分发文件，而不是中间归档。发布 .dmg 时验证完成装订后的 .dmg；发布 .pkg 时验证最终安装包；发布 .zip 时验证重新创建的 ZIP 以及其中的 App。
日志也不应只在失败时保存。Apple 建议公证成功后仍下载并检查日志，因为日志中可能包含下一次发布前应修复的警告。Apple 获取公证日志接口
状态查询依赖提交标识，日志接口返回的下载地址可能具有临时性，因此流水线应在任务结束前把日志复制到自己的制品存储中，而不是只保留一个外部地址。
在决定长期租用周期前，我们建议先做一次真实制品试运行：通用 CI 负责拉取源码、编排任务、传递制品和保存日志；远程 Mac CI 负责 macOS 构建、签名、装订和最终验证。
试运行不要只测试“绿色通过”，还要主动验证失败、重启和人工接管：
notarytool 或 Notary API 提交；可以按下面的条件分支确定部署方案：
对于需要长期运行的节点，还应额外验证：
如果重点是节点恢复、持续运行和远程接入，可以进一步查看 VNCMac 的远程 Mac 方案；如果团队还在比较一次性购买设备与按需使用节点，也可以参考 Mac 设备方案与远程使用选择。
macOS App 公证需要 Mac 吗？答案取决于团队把“公证”定义到哪一步：Apple Notary API 可以让 Linux CI 负责提交和查询，但构建、Developer ID 签名、票据装订及本地验证仍然属于真实 macOS 交付职责。
如果当前方案是 Linux 云主机加临时人工 Mac，常见缺点是：签名凭据难以隔离、人工接管容易遗漏、装订与验证难以稳定复现，而且重启后工具链和钥匙串状态不一定能恢复。相比之下，VNCMac 的远程 Mac 更适合先作为隔离发布节点完成一次端到端试运行，再根据构建频率决定按需使用或长期租用。
因此，建议先用真实制品验证“构建—签名—提交—装订—验证—重启恢复”这条链路。只有整条链路都能稳定通过，才应把远程 Mac CI 固定为生产发布节点；如果只需要提交和查询，则保留 Linux CI 加 Apple Notary API，避免为不需要的环节扩大 Mac 运维范围。