数据 → 解法： Apple 表示，公证扫描通常少于 1 小时，但这不是交付时限保证。(Apple 公证 macOS 软件说明) 所以，Claude Code 可以协助执行发布命令，但签名、公证票据和最终产物必须以 macOS 工具链的实际输出验收；涉及 Apple 签名凭据的任务，应放在权限受控、结束后可清理的 Mac 环境中。
这篇指南适合没有常驻 Mac、需要准备 macOS 发布的独立开发者。
也适合希望将 Claude Code 纳入可审计构建流程的发布工程师。
如果你负责签名凭据或远程执行环境，重点看凭据边界与放行条件。
发布渠道：先分清 Mac App Store 与 Developer ID
两条发布路线的签名身份和验收流程不同，不要将它们拼成一套流水线。Mac App Store 分发使用 Apple Distribution 身份并提交到 App Store Connect；独立分发给用户则使用 Developer ID Application 身份，并按 Apple 的公证流程准备产物。Apple 说明，两种分发方式对应不同流程，应按目标渠道选择签名身份和验收方式。(macOS 分发签名文档)
| 发布选项 | 签名与交付 | 你需要重点验收 |
|---|---|---|
| Mac App Store | 使用 Apple Distribution 身份，上传到 App Store Connect | 上传构建的接收状态、版本与团队记录；上传不等于审核通过或正式上架 |
| Developer ID 独立分发 | 使用 Developer ID Application 身份；准备面向用户的分发文件并公证 | 签名有效、公证状态与日志、票据装订状态、最终分发文件可验证 |
App Store Connect 上传后，构建还需经过处理才会出现在相应记录中；应核对上传构建的官方说明。Claude Code 可以协助检查设置、整理命令、运行测试或生成日志，但证书身份选择、凭据授权以及最终发布决定都应由责任人把关。Claude Code 的 CLI 提供工具权限与确认相关选项；不要为了无人值守而默认跳过权限提示，再把签名和发布权限一并交给 Agent。(Claude Code CLI 权限选项)
环境准备：把构建证据留在产物旁边
云端 Mac 的价值不只是能运行 macOS 命令。你还需要确认工具链和构建输入可复现，避免 Agent 报告“构建成功”，却没有留下可检查的归档或应用包。
交给 Claude Code 之前，先记录以下信息：
- 构建入口： 是 Xcode 工程、Swift Package、
make，还是项目自己的构建脚本。 - 工具链选择： 使用哪个 Xcode 或命令行工具；多套 Xcode 共存时，确认当前选择。
- 构建输入： 依赖锁定文件、构建配置、目标架构、Bundle ID 和版本号。
- 产物位置： 约定归档、
.app、日志与导出包保存到哪个目录。 - 执行身份： 哪个用户运行构建与签名；不要让签名步骤切换到无法读取预期钥匙串的账户。
如果项目使用 Xcode，可把下面命令中的 scheme、配置和路径换成项目实际值：
xcodebuild \
-scheme "YourScheme" \
-configuration Release \
-archivePath "build/YourApp.xcarchive" \
archive
归档命令退出成功并不是唯一证据。确认 .xcarchive 确实生成，检查其中的应用、版本标识和构建日志；再按分发方式导出待签名或已签名产物。若使用外部构建系统，先明确哪个任务负责签名、哪个步骤负责打包，别让 Agent 根据猜测补齐构建约定。前文的 Apple 分发签名文档也说明了 Xcode 工程与外部构建系统可能采用不同的签名步骤。
凭据隔离：让工作流可授权、可撤回
签名证书和公证凭据的风险，不只在于误传到公开仓库。它们也可能进入 Agent 提示词、Shell 历史、调试输出、缓存目录或保留时间过长的工作空间。把密钥放进环境变量，并不自动意味着子进程或日志无法接触它。
| 凭据方案 | 适用场景 | 主要风险与控制点 |
|---|---|---|
| 受控钥匙串中的签名身份 | 需要在 Mac 上执行签名的发布任务 | 只向任务用户提供必要身份；不把证书密码写入仓库或命令行历史；任务结束检查钥匙串访问权限 |
notarytool 钥匙串配置 |
Developer ID 公证认证 | 用凭据配置名调用工具，不在脚本明文保存口令；限制执行账号与配置的可见范围 |
| 临时注入的密钥文件 | 团队已有密钥管理和清理机制时 | 控制读取权限、生命周期与日志脱敏；结束或失败时清理，并验证文件确实消失 |
Apple 文档说明，notarytool 可将公证凭据存入钥匙串，并在提交时通过配置名引用；也可使用 API 密钥认证。凭据的保管和清理仍应由你的环境管理流程负责。(Apple 自定义公证工作流文档)
建议把 Agent 的权限拆成两段：先允许它检查项目并生成构建、签名和验收计划；确认目标身份、产物路径与命令后，再由授权人员提供执行权限。生产凭据不要出现在会话内容中。若自动化任务不需要独立决定发布，可把“提交公证”与“对外发布”设成不同门禁。
Developer ID：从内到外签名并逐项验证
独立分发通常要使用 Developer ID Application 身份。Apple 对公证分发要求相应的签名条件，包括启用 Hardened Runtime、使用安全时间戳，以及避免把开发调试 entitlement 带入正式应用；具体设置可对照 Hardened Runtime 文档。Apple 还说明，自 2023 年 11 月 1 日起，公证服务不再接受 altool 或 Xcode 13 及更早版本的上传；新流程应使用当前文档指定的工具。
先确认当前签名身份是否存在：
security find-identity -p codesigning -v
签名应用后，不要只看外层 .app。若其中含有框架、插件、辅助工具或其他嵌套代码，应按内层到外层的顺序完成签名。再检查应用包和相关组件：
codesign --verify --deep --strict --verbose=2 "build/YourApp.app"
codesign -d -vv "build/YourApp.app"
把完整命令输出和执行时间写入构建记录。若签名失败，先检查实际身份、嵌套组件签名状态、entitlements 和构建输入；不要让 Agent 不断尝试不同证书或改写权限配置。签名命令和身份选择可参照前文的 Apple macOS 分发签名说明。
公证交付：区分提交、结果与票据
上传成功只说明文件已提交，不代表公证已通过，更不代表最终分发包已经装订并完成验证。每次提交都应留存提交编号、公证日志和对应产物的校验记录，确保日后能追溯日志对应哪个版本。
按分发格式安排以下操作：
- 完成 Developer ID 签名，并对应用包及嵌套代码运行签名验证。
- 创建待提交文件，确认它与实际准备分发的格式一致。
- 使用
notarytool提交并等待结果，保存提交编号。 - 下载公证日志，检查错误与警告；状态不是
Accepted时暂停。 - 对支持装订的目标执行
stapler staple，再运行stapler validate。 - 验证最终交付文件；ZIP 不能直接装订，需处理其中的应用等项目，再重新制作供分发的 ZIP。
- Gatekeeper 评估与其他验收均通过后，才进入人工放行。
提交命令可参考下面的形式，凭据配置名应由你的密钥管理流程提供：
xcrun notarytool submit "build/YourApp.dmg" \
--keychain-profile "NOTARY_PROFILE" \
--wait
若返回提交编号，继续下载日志，而不是立即发布：
xcrun notarytool log "SUBMISSION_ID" \
--keychain-profile "NOTARY_PROFILE" \
"build/notary-log.json"
Apple 的自定义公证工作流要求检查结果与日志，并说明 ZIP 不能直接装订票据；处理其中项目后应重新打包。
最后针对实际交付文件运行适用的检查，例如：
xcrun stapler validate "build/YourApp.dmg"
spctl --assess --type execute --verbose=2 "build/YourApp.app"
若是安装包，应按目标类型执行评估。日志有警告、装订验证失败，或最终文件与提交文件不是同一份产物，都应先停下排查。Apple 的Mac 软件打包说明建议在干净的分发环境中测试最终文件。
发布复核：用门禁而不是 Agent 的口头确认放行
准备一份能由另一位工程师复核的发布记录，至少包含：仓库版本或提交标识、构建配置与产物路径、签名身份及验证输出、公证提交编号与日志、票据装订结果、最终文件校验信息，以及批准人记录。不要把凭据本身写进记录。
发布前逐项检查：
- 产物一致： 公证对象、验收对象与准备上传或交付的文件相匹配。
- 签名有效： 应用及嵌套代码验证通过，身份符合选定的分发渠道。
- 公证闭环： 结果已确认，日志已留存，适用的票据已装订并验证。
- 权限收回： 临时密钥文件、钥匙串访问和任务账号权限已按流程清理或撤销。
- 人工批准： 责任人核对版本与证据后，明确授权发布。
缺少任何一项，就暂停发布。Agent 能帮你执行命令和整理证据，但无法替团队承担证书授权与上线责任；这也是需要谨慎设置 Claude Code 命令权限的原因。
FAQ：自动化与验收边界
Claude Code 能替你完成哪些签名操作？
它可以在具备相应工具和权限的 Mac 环境中协助调用构建与签名命令，但实际执行取决于环境配置。你仍需确认签名身份和命令输出；不要因为会话回复称“已签名”就认定产物有效，也不要默认开放跳过确认的权限。签名是否通过，应以 codesign 等工具对实际应用包的检查结果为准。
云端 Mac 上如何控制签名与公证凭据的暴露？
公证认证可使用 notarytool 钥匙串凭据配置；签名身份也应通过受控的密钥保管流程提供。避免将凭据写入仓库、提示词、日志或长期工作目录。任务结束后，检查临时文件、钥匙串权限与执行账号，并按组织策略清理或撤销访问。生产发布与不含真实密钥的测试任务应分开授权。
公证服务接受提交后，还要核对哪些证据？
核对提交编号和状态，保存并检查公证日志；随后验证适用的票据已装订到最终分发对象，并对实际交付文件运行相应的签名和 Gatekeeper 检查。若警告尚未评估、票据验证失败，或产物与公证提交对象不一致，就先不要发布。Accepted 是一个阶段性结果，不应替代对最终文件的验收。
从签名到打包，发布任务如何安排顺序？
先构建应用，再按内层到外层签名并验证；然后按分发格式打包并提交公证。收到结果后检查日志、装订适用票据，再验证最终交付文件。ZIP 不能直接装订，需处理其中的应用等项目后重新创建 ZIP。将提交和上线设为独立门禁，能避免公证结果尚未核验时文件已对外发布。
如果你现在用个人 Mac 处理发布，常见代价是设备需要持续维护、构建与签名环境难以隔离、临时任务结束后不易统一清理；普通非 Mac 执行环境也无法直接替代 macOS 签名与验证环节。对于偶发发布或短期验收，受控的远程 Mac 环境可以避免为单次任务长期维护一台机器；若你有持续重负载、固定物理接口或必须常驻的签名环境，自购设备可能更合适。需要临时执行环境时，可先查看 Kvmkit 的 Mac mini 租用选项和帮助中心，了解使用前需确认的事项。已有远程环境的话，先用不含真实密钥的测试项目跑完构建、签名、公证、装订和验收，再决定是否接入生产凭据。
常见问题
Claude Code 可以直接替我完成 macOS 应用签名吗？
Claude Code 可以协助运行构建和签名命令，但能否执行取决于当前环境、凭据是否可用以及工具权限。不要把它给出的“签名成功”文字当验收证据；你要自行核对签名身份、`codesign` 验证结果和最终分发文件，并由发布责任人决定是否放行。
云端 Mac 上怎样保存签名和公证凭据更稳妥？
不要把证书密码、私钥或公证口令提交到仓库、提示词、构建日志或长期保留的工作目录。公证认证可用 `notarytool` 的钥匙串凭据配置；签名身份则应交由受控的钥匙串或密钥管理流程提供。任务结束后检查临时钥匙串、密钥文件和会话权限，并按团队策略清理或撤销凭据。
公证显示 Accepted 后，还需要检查什么？
先用提交编号下载并保留公证日志，检查是否有警告或问题；再确认票据已装订到最终要交付的应用或容器，并运行 `stapler validate`。最后对实际分发的 DMG、PKG 或 ZIP 做签名与 Gatekeeper 验证。Accepted 代表公证服务接受该次提交，不等于你手里的最终打包文件已经完成验收。
签名、公证和 DMG 或 ZIP 打包应该按什么顺序做？
先完成构建，再从嵌套可执行文件向外签名并验证应用；接着按选定的分发格式打包、提交公证并确认结果。对支持装订的最终产物装订票据并验证。ZIP 本身不能直接装订：需要对其中的应用等项目装订，再重新制作供分发的 ZIP。发布流水线应记录每个阶段对应的产物与日志。
把 CI/CD 放在 M4 Mac mini 上，才算真正省心
本文所有流程——Xcode、Fastlane、CocoaPods、SPM——在 macOS 上都是原生一等公民。Mac mini M4 统一内存架构让签名、归档、上传不再互相拖累，~4W standby power suits 24/7 build nodes.