macOS App 公证怎么做？2026 远程 Mac 发布清单

先按分发渠道选对公证路径

本文讨论的是从 App Store 以外的渠道直接分发 macOS 应用：使用 Developer ID 签名，并按适用流程提交公证。若计划在 App Store 上架，则应走 App Store Connect 的提交与审核流程；公证服务的自动检查不等同于 App Review，也不会替开发者完成上架审核。Apple 对分发方式的说明

Developer ID 签名和公证是不同环节。签名标识发布者，并帮助系统检测代码是否在签名后被改动；公证是 Apple 对提交软件进行自动检查，并生成可供 Gatekeeper 使用的票据。面向 App Store 外分发时，两项工作的作用不能互相替代。Developer ID 证书说明

发布前把团队权限与凭据边界理清

能登录开发账户，不代表当前账号有权创建或使用发布身份。先核对项目所属团队、签名身份是否匹配、负责签名的人是否获得团队授权，以及该身份的私钥是否确实可用于目标构建；如果团队权限或私钥归属说不清，先停止，不要临时复制他人的凭据到远程环境。Apple 对证书的创建与管理设有角色要求，证书类型也应与具体分发用途相符。

远程环境需要访问项目、构建工具和公证所需凭据，但不要把账户密码、私钥或团队访问令牌写进源代码、构建日志或共享脚本。使用前应确认谁能登录这台主机、凭据如何存取和撤销、发布完成后如何清除临时材料。若开发者本人无法确认权限，或团队政策不允许将密钥放入该环境，就改用获批的本地发布机或由获授权人员执行签名。

需要的不是“能开 Xcode”，而是能完成指定项目的发布闭环。若应用依赖私有仓库、签名证书、配置文件、子模块或构建期下载资源，出发前逐项确认远程 Mac 能以合规方式取得；只验证桌面可连接，无法证明构建依赖和发布身份都已就绪。

首次构建后检查签名与应用包

在 Xcode 中选择面向 Mac 的直接分发方式，完成归档后检查应用及其中嵌套的可执行代码。Apple 的公证要求涉及有效的代码签名、Developer ID 身份和 Hardened Runtime；应用是否需要特定运行时例外，还要根据它实际使用的功能判断，不能为了赶进度随意勾选权限。Hardened Runtime 配置说明

远程 Mac 上可先对导出的应用包做签名验证：

codesign --verify --deep --strict --verbose=2 "MyApp.app"
codesign -dv --verbose=4 "MyApp.app" 2>&1

第一条命令应完成验证而不报告签名错误；第二条输出可用于查看签名身份等信息。它们不是公证通过证明，也不会代替逐个排查构建内容。若输出指出某个框架、插件或辅助工具签名无效，应回到构建产物定位对应组件，不要只反复提交同一个包。

构建成功也不代表包结构正确。常见的隐性问题包括嵌套组件未签名、签名后又修改应用资源、使用了与直接分发不匹配的证书，以及 Hardened Runtime 所需配置不完整。Apple 要求为分发的可执行代码提供有效签名，并指出需要按应用实际功能设置运行时能力；因此，签名检查应覆盖最终交付的那一份应用，而不只是归档目录里的中间文件。

远程提交时保存提交编号与日志

应用签名核对无误后，可从 Xcode Organizer 选择 Developer ID 分发与上传，也可以用 notarytool 提交自定义打包的交付文件。采用命令行时，先把凭据安全地存入钥匙串，再以钥匙串配置名调用工具；不要把真实密码直接写进命令行历史或脚本。自定义公证工作流

xcrun notarytool submit "MyApp.zip" \
  --keychain-profile "notary-profile" \
  --wait

等待处理结束后，保存命令输出中的提交编号和最终状态，并下载日志：

xcrun notarytool log "<submission-id>" \
  --keychain-profile "notary-profile" \
  "notary-log.json"

示例中的文件名、配置名和提交编号都需要替换成实际值。检查日志时区分错误与警告：出现错误就暂停交付，根据日志指出的路径和问题修复后重新构建；即使状态显示 Accepted，也要阅读日志，不能把“通过”理解成“无须检查”。跨时区发布时，把提交编号、构建版本、交付文件名、日志和操作人记录在同一发布记录中，方便下一位协作者接手。Apple 明确提供查询提交状态和获取提交日志的流程；若日志仍无法解释问题，可从对应问题排查文档继续定位。

FAQ：签名与远程提交的边界

远程 Mac 能否完成公证？可以，但要同时具备项目访问、适用的 Xcode 工具链、团队授权和有效凭据，并能把最终文件安全取回。仅能连接远程桌面或生成归档，都不足以说明发布条件已满足；应先在同一环境完成一次从签名到验证的演练。

Developer ID 和公证各自负责什么？Developer ID 签名关联发布者身份并验证代码签名；公证服务检查提交的软件，结果可让 Gatekeeper 查询。前者不是审核结果，后者也不是 App Store 批准。选择 App Store 渠道时，仍须单独完成对应的提交与审核。

怎样通过 Apple 公证提交应用？Xcode 用户可从 Organizer 选择 Developer ID 分发并上传；自定义流程可用 notarytool 提交打包文件、等待结果并获取日志。无论采用哪种方式，都要记录结果并处理日志中的问题，不要把上传成功当成公证通过。

固定票据并按客户收到的文件验收

公证通过、票据固定和最终可交付文件是不同状态。对于支持固定票据的应用、磁盘映像或安装包，应按实际分发对象运行 stapler，再验证固定结果；如果提交的是 ZIP，不能直接把票据固定到 ZIP 本身，应先处理其中可固定的项目，再重新打包。交付对象不同，检查对象也随之变化。

xcrun stapler staple "MyApp.dmg"
xcrun stapler validate "MyApp.dmg"
spctl --assess --type execute --verbose=4 "MyApp.app"

这些命令应针对准备交付的实际产物执行。然后从该文件重新解压或安装，在干净的测试环境检查首次打开；验证下载文件有没有损坏、应用能否启动、Gatekeeper 是否正常识别，以及客户需要的功能是否可用。Apple 也建议测试由实际安装包、磁盘映像或压缩包生成的应用，而非只在开发目录里运行源码构建。Mac 软件打包与分发说明

在旅途中发布，另外要留一条恢复路径：保留可追溯的构建版本、签名与公证日志、最终交付文件，以及能由获授权人员接管的项目访问方式。注意区分这些记录和秘密凭据；日志可以帮助排错，不应包含私钥或明文密码。若网络中断导致提交状态不明，应先按提交编号查询状态，而不是盲目重新签名并覆盖待交付版本。

按发布演练结果决定是否采用远程 Mac

远程 Mac 是否适合成为正式发布工作站，取决于项目在该环境中的实际验收结果，而不是能否登录。没有本站可核实的特定配置、地域节点或实测记录时，不应据此承诺性能、可用性或公证成功率。可将结论分为三种：

• 可直接纳入发布流程：签名身份可用，构建与依赖完整，提交日志可保存，票据和最终交付文件也通过用户侧验证。
• 先做短测：能完成部分步骤，但凭据管理、跨时区交接、网络中断恢复或最终文件取回仍未演练。
• 保留本地备用环境：项目依赖无法迁移、团队不允许远程存放必要凭据，或交付必须依赖远程环境无法满足的本地设备与接口。

与本地 Mac 相比，远程方案免去携带设备的负担，却增加了网络质量、远程文件取回、凭据边界和临时故障恢复等检查点；单靠 iPad 或轻薄本本地工作，也无法替代依赖 macOS 构建工具的发布步骤。若考虑采用 NodeMini，可先查看远程 Mac 的交付与租赁方案，再用自己的项目完成一次短测；也可从NodeMini 服务入口了解可选方式。实际可用性仍须以当时的服务信息和项目验收为准，不能把环境说明当作公证通过保证。