数据点： Apple 已说明，macOS 27 将是 Rosetta 支持 Intel 应用的最后一个版本；Intel-only 应用在运行 macOS 27 的 Apple silicon Mac 上无法继续依赖 Rosetta。(Apple 关于 Rosetta 支持变化的说明) 因此，macOS 27 Mac App 公证前验收不能止于签名或公证状态：直接分发要按最终交付物检查 Developer ID 签名、公证结果和用户侧启动；Mac App Store 分发则走商店提交链路，不套用同一套公证流程。先在隔离构建环境完成验收，再把通过验证的步骤用于正式发布。
适合谁看：直接向用户分发 Mac App、需要在发布前核对签名、公证与交付文件的独立开发者。
使用 DMG 或 PKG 的小团队，需要把镜像、安装包和应用本体分开验收。
没有本地 Mac，或需要固定发布环境的开发者，也可以据此判断远程 Mac 是否适合承载重复验收。
最后更新于 2026 年 11 月 6 日；核实依据：Apple 的公证指南、notarytool 工作流文档、分发说明和 macOS 发布信息。
macOS 27 Mac App 公证前验收，先按分发渠道划边界
直接分发与 Mac App Store 分发的安全检查并非同一条流程。Apple 将直接分发的公证用于 Gatekeeper 检查软件来源及是否被篡改；Mac App Store 提交则包含相应安全检查，不要求开发者机械地另做一遍直接分发用公证。(macOS 软件公证指南) (Apple 的应用分发说明)
| 分发场景 | 发布前要验收的对象 | 关键证据 | 不能据此推断 |
|---|---|---|---|
直接交付 .app 或 ZIP |
签名后的应用及实际发给用户的文件 | Developer ID 身份、notarytool 提交状态与日志、票据验证、启动记录 | 单独看到“Accepted”就证明交付包和启动都正常 |
| DMG | 最终 DMG，以及从镜像挂载出的应用 | 镜像提交与票据状态、挂载后应用签名、启动测试 | 镜像内应用通过公证就等于镜像本身已验收 |
| PKG | 安装包及安装后的应用 | 安装器签名、公证记录、安装结果、应用签名与启动记录 | 安装包通过公证就等于安装后的应用一定可用 |
| Mac App Store | 商店提交的归档及实际发布版本 | 提交和处理记录、线上版本与预期构建的对应关系 | 必须重复执行直接分发的 Developer ID 公证步骤 |
上述差异来自 Apple 对可提交公证对象及交付测试的说明：公证服务可以处理应用、磁盘映像和扁平安装包；如果应用放在镜像里的安装包中，签名与公证对象也需按实际打包结构确定。(公证工作流定制说明) (Mac 软件打包与分发说明)
决策条件：
- 若用户下载的是 DMG，就把 DMG 本身作为最终验收对象；否则只验证 DMG 内部的
.app，不发布。 - 若用户下载的是 PKG，就分别检查安装器包和安装后的应用；只检查其中一项时，回退到隔离环境补测。
- 若通过 Mac App Store 发布，就核对商店提交及实际发布链路；不要把直接分发的 Developer ID 公证步骤当作强制重复项。
- 若无法确定正式发布文件与已验收文件是否相同，暂停发布，重新对正式交付物走验收流程。
直接分发：签名、公证与启动必须连成一条证据链
Apple 要求直接分发的软件使用 Developer ID 签名；提交公证的 macOS 应用还必须启用 Hardened Runtime。该能力会限制部分运行时行为；应用确实需要例外能力时，应只配置其所需权限，并记录为何需要，而不是为了让构建通过而随意放宽。(Hardened Runtime 文档)
| 验收层 | 核对内容 | 建议留存的证据 |
|---|---|---|
| 签名身份 | 应用是否由预期 Developer ID 身份签名，嵌套代码是否一并有效 | 签名检查输出、构建版本与签名身份记录 |
| 运行时安全 | Hardened Runtime 是否启用，例外权限是否与功能需要相符 | 导出的 entitlement、审核记录 |
| 公证结果 | notarytool 对应提交是否被接受，日志是否有警告或问题 | submission ID、状态输出、JSON 日志 |
| 票据处理 | 最终交付对象是否已附加票据，验证工具是否通过 | stapler 输出、验证结果 |
| 用户侧运行 | 实际交付物是否能挂载或安装，应用是否能启动 | 测试系统版本、目标架构、操作记录 |
这里有几个常被混为一谈的边界：
- 签名不等于公证。签名确认开发者身份并帮助系统发现文件是否被更改；公证是另一个由服务端处理并返回结果的步骤。(代码签名服务说明)
- 公证成功不等于应用能启动。它不能替代在目标系统上的启动、权限、更新和关键功能测试。
- 构建主机能运行不等于目标系统兼容。Apple 的 macOS 27 发布说明提供对应 SDK 的测试信息；项目还需对自己的目标系统和架构做启动验证。(macOS 27 发布说明)
- Hardened Runtime 例外不是验收豁免。若应用依赖 JIT 或动态加载等能力，要确认对应权限确实必要；对无关二进制或共享组件的签名状态也要一起检查。
对于常见的命令行流程，先从 Xcode 导出可提交的文件，再用 notarytool submit 提交；记录返回的提交标识，等待结果后用 notarytool log 保存 JSON 日志。Apple 特别提示，即使提交成功也应检查日志，因为其中可能仍有值得修正的警告。
⚠️ 验收记录要能对应到同一个构建：应用版本、提交文件名或校验信息、submission ID 和最终交付文件都应可追溯。若公证后又改动应用内容或重新打包，不能把旧文件的验证结果直接移植到新文件。
DMG 与 PKG：分别验收容器和安装结果
DMG 和 PKG 的区别不只是文件后缀。验收应跟着用户实际下载、挂载或安装的对象走，而不是只看开发目录里的应用。
DMG 场景：先确认提交公证的是否为最终 DMG。完成处理后，按交付方式验证镜像票据，再挂载该镜像，检查其中应用签名并实际启动。若镜像里还有其他可执行内容，也要确认它们包含在预期的提交范围内。Apple 的打包说明指出，交付前应测试实际制作出的安装包、磁盘映像或 ZIP，而不是只测开发用副本。
PKG 场景：先检查安装器签名与公证记录，再从正式 PKG 安装应用，检查安装路径、安装后应用签名及启动结果。若实际交付的是包含安装包的 DMG，要按实际结构决定对哪个对象做公证与票据处理，不能把“PKG 成功”自动视为“DMG 已验收”。
ZIP 场景：notarytool 可以处理包含应用的 ZIP，但 Apple 说明不能直接把票据 stapling 到 ZIP 文件本身；应对归档内的相应项目处理票据，再重新制作最终 ZIP。此时要确认用户拿到的 ZIP 确实由已验证的项目生成。
更换文件名本身未必意味着文件内容变化，但重新导出、修改资源、替换嵌套组件或重新压缩都可能使“验收对象”与“实际发布对象”不再相同。项目应保留最终文件的识别信息，并在每次重新制作交付物后复核票据和启动测试。
Mac App Store：把验收重点放到商店链路
通过 Mac App Store 分发时，应用提交到商店的过程已经包含相应安全检查。此时应核对 Xcode 导出的归档是否是预期构建、提交处理是否完成，以及实际发布版本能否对应回该构建，而不是对着直接分发清单逐项硬套 Developer ID 公证。
有混合分发的项目要拆开记录：商店版和网站直发版如果使用不同的签名、构建设置、功能权限或打包方式，就应分别验收。商店流程的结果不能替代网站下载包的公证记录，网站版本的票据也不能证明商店线上构建正确。
macOS 27 的目标环境与远程发布流程
macOS 27 的兼容性验收要与公证验收分开。Apple 说明 macOS 27 将是 Rosetta 的最后一个支持版本，并建议开发者为 Apple silicon 提供原生支持；这意味着 Intel-only 应用不能在 macOS 27 的 Apple silicon 目标环境中依靠 Rosetta 启动。所以，公证通过并不能替代架构与目标系统测试。构建记录至少应说明使用的 Xcode、SDK、目标架构和实际测试系统；具体兼容范围以 Apple 当前资料及项目自身测试为准。
远程 Mac 可以承载重复构建与公证验收，但签名凭据、网络访问、构建产物传输和用户侧测试都要纳入流程。Apple 的自动化说明支持在脚本环境中使用 xcodebuild 导出归档，再调用 notarytool 提交；这说明可自动化的是流程衔接，不代表任意远程环境都已经具备所需条件。(Xcode 归档流程定制说明)
建议按以下顺序建立可复核的发布流程：
- 确定发布路径。记录渠道、正式交付格式和目标用户环境；先确认走网站直发还是 Mac App Store。
- 隔离构建。在专用构建环境生成归档，记录 Xcode、SDK、版本号与架构；不要把开发目录里的临时产物当作最终文件。
- 核对签名。检查 Developer ID 身份、Hardened Runtime 和所需 entitlement；保存签名检查结果。
- 提交公证并留证。调用
notarytool提交实际对应的文件，保存 submission ID、状态和 JSON 日志。凭据使用受控的密钥存储方式，不要明文写入脚本或日志。 - 处理并验证票据。按
.app、DMG 或 PKG 等交付类型处理票据，再验证该交付物本身；ZIP 不能直接附加票据，应按归档内项目的规则处理。 - 模拟用户取得文件。从隔离环境下载、挂载或安装最终交付物，验证启动和项目关键功能，并记录系统版本及测试架构。
- 冻结发布产物。将已验收文件与其构建记录对应起来；任何重新构建、替换内容或改变打包方式，都重新检查对应验收项。
如果远程环境不允许安全存放签名凭据、无法访问公证所需服务，或无法对最终交付物执行实际启动测试，就不应把它作为唯一发布验收环境。可查看数据与隐私说明，先核对远程环境是否符合项目的凭据管理要求；若还在评估独立 Mac 环境，也可参考Mac 远程租赁方案。实际可用的系统、工具链和配置，应以服务页面及项目实测为准，不能仅凭“远程 Mac”推定。
发布前 FAQ
Developer ID 签名后，如何确认公证成功？
以 notarytool 对应提交的状态为准，并保存 submission ID 与 JSON 日志；随后处理并验证最终交付物的票据。再从用户会取得的文件进行启动测试。只看到签名有效或上传完成，仍不足以证明公证已经完成，更不能证明应用在目标系统上能正常启动。
DMG 和 PKG 的验收要点有什么不同？
DMG 验收要覆盖镜像本身、挂载结果及应用启动；PKG 验收要覆盖安装器签名、公证状态、安装后的应用签名和启动。交付物的外层容器与内部应用是不同检查对象，按一个对象得到的结果不能自动替代另一个对象的检查。
Mac App Store 版也要走 Developer ID 公证吗？
不应机械套用网站直发的 Developer ID 公证流程。Mac App Store 提交链路包含相应安全检查，项目验收应聚焦提交归档、处理状态和最终发布版本；如果同时向网站提供独立安装包，则该直发版本仍应单独验收。
远程 Mac 能完成签名和公证验收吗？
可以在具备所需 Xcode、网络访问和受控签名凭据的远程 Mac 上完成构建、签名、公证提交与日志核验。最后仍需检查真正交付给用户的文件，并验证其在目标 macOS 环境中的启动；远程主机上的成功记录不能替代这一环节。
更换交付文件后，之前的验收还有效吗？
只要最终交付对象与已验收对象不再能明确对应，就应重新核对。重新导出、修改应用内容、替换嵌套代码或改用另一种打包格式，都可能改变需要验证的对象；应为新产物保留自己的公证状态、票据验证和启动测试记录。
macOS 27 Mac App 公证前验收的核心，是让签名、公证记录和最终交付文件指向同一个可复核的构建，再独立验证目标环境中的启动。自建实体 Mac 适合需要长期固定负载或物理接口的团队；临时测试则未必值得专门购置设备。对需要重复构建、公证和发布验收、但暂时不想维护本地 Mac 的开发者，远程租用 Mac 可作为固定发布环境的选项；是否合适，应先确认工具链、凭据管理和用户侧测试都能闭环。
常见问题
macOS 27 的 Mac App 发布前，哪些公证项目要逐项核对？
先确认分发渠道；直接分发时核对 Developer ID 身份、Hardened Runtime、签名完整性和 notarytool 返回状态。再检查提交对象是否与最终下载文件一致、票据是否附加，并从隔离环境挂载或安装最终交付物，实际启动应用。保存提交编号、日志和验证结果，不能只留一张成功截图。
Developer ID 签名完成后，怎样确认公证确实成功？
签名有效不代表公证成功。用 notarytool 查询该次提交的状态，保存 submission ID，并下载 JSON 日志查看状态、警告和错误；成功后按交付类型附加票据，再用 stapler validate 检查票据。最后对实际交付物做 Gatekeeper 评估和用户侧启动测试，形成可复核的完整记录。
DMG 和 PKG 的公证验收步骤有什么区别？
DMG 应以用户下载的镜像作为验收对象，检查镜像提交、公证票据、挂载后的应用签名和启动情况。PKG 则要分别核对包的安装器签名、公证状态，以及安装完成后应用本身的签名和启动。若只验证包内应用，不能据此认定 DMG 或 PKG 已完整验收。
从 Mac App Store 发布，还需要单独走 Developer ID 公证吗？
通常不需要把直接分发用的 Developer ID 公证流程原样套到 Mac App Store 应用上；商店提交本身包含相应安全检查。验收应转向商店提交的归档、处理结果、实际发布版本和用户获得的构建产物。留存提交与发布记录，并确认线上版本对应预期构建。
远程 Mac 可以完成签名、公证和发布前验收吗？
可以将构建、签名、notarytool 提交、下载日志、附加票据和交付物验证串成远程流程，前提是环境具备所需工具、网络访问和受控的签名凭据。远程验收仍需测试最终 DMG 或 PKG，并记录目标系统及架构；远程构建主机能完成公证，不等于已证明用户环境可以启动应用。
用 OrbVPS 远程 Mac 完成公证前验收
在持续可控的独享 Mac 上检查签名、公证结果与首次启动表现，按直接分发流程验证应用。