macos 软件分发必须满足三项硬性条件：有效 developer id 签名、apple 公证服务票据钉入、官方时间戳绑定；缺一则内核拦截。developer id 证书是唯一合法签名凭证，需年费 99 美元开发者计划支持，且须正确配置 team id 与 signing identity；公证已强制替代 altool，使用 xcrun notarytool 并钉入票据；运行时动态校验签名、票据及时间戳，篡改即阻断。
macOS 环境下，软件源安全与数字签名合规不是可选项，而是运行前提。自 macOS 10.15 Catalina 起，未公证的 Developer ID 签名应用已无法启动；到 2026 年 macOS Tahoe 26 系统，规则进一步升级：所有第三方分发软件必须同时满足三项硬性条件——使用有效 Developer ID 证书签名、通过 Apple 公证服务（notarization）并附带有效票据、签名时绑定苹果官方时间戳。缺一即被内核拦截，连启动界面都不会出现。
Developer ID 证书是唯一合法“身份证”
Mac App Store 以外分发的软件，只能依赖 Apple Developer Program 颁发的 Developer ID 证书签名，不能用 Mac Development 或 iOS Distribution 证书替代。该证书需由团队管理员在 Apple Developer 账户 中生成，并导出为 .p12 文件导入钥匙串。个人开发者、开源项目维护者若未加入年费 99 美元的计划，将彻底失去签名资格——这不是技术限制，而是政策门槛。
- 证书必须处于“Valid”状态，过期或被吊销（如 OpenAI 事件中因供应链风险主动撤销）会导致所有旧版本立即失效
- 签名时需指定正确的 team ID 和 signing identity，Xcode 归档或
xcodebuild -sign命令中不可省略--sign参数 - 同一证书不可跨团队混用；若团队变更或成员退出，需重新申请并更新全部构建流程
公证不是“锦上添花”，而是强制通关环节
签名只证明“谁签的”，公证才回答“苹果是否认可它安全”。2026 年起，xcrun notarytool 已完全取代老旧的 altool，且必须使用 Apple ID 关联的开发者账号登录。上传后，系统自动扫描恶意代码、检查权限声明、验证签名链完整性，并在数分钟至数小时内返回结果。
- 失败时不会仅提示“不通过”，而是明确列出问题类型：常见如硬编码网络请求、未声明的辅助工具、嵌入式脚本未签名、Info.plist 中 NSAppTransportSecurity 配置违规等
- 公证票据（ticket）必须“钉入”（staple）到最终分发包中，命令为
xcrun stapler staple <app-or-dmg-path></app-or-dmg-path>；未钉入的包在离线环境或首次运行时仍会触发 Gatekeeper 阻断 - 已发布的软件也可补公证，支持 ZIP、PKG、DMG 等格式，无需重新打包用户已下载的文件
运行时校验已成常态，篡改零容忍
macOS 不再只在校验安装包一次，而是在每次启动时动态验证：Mach-O 文件哈希、签名信息、公证票据有效性、时间戳是否在证书有效期内。任何修改——包括汉化资源替换、破解补丁注入、甚至用 codesign --remove-signature 清除签名后再重签——都会导致 Gatekeeper 弹出“已损坏，无法打开”警告，且终端绕过命令（如 xattr -rd com.apple.quarantine）在最新系统中多数已失效。
- 启用 Hardened Runtime 是基础要求：必须勾选 “Disable Library Validation”、“Allow Execution of JIT-compiled Code” 等选项，并在 entitlements 文件中显式声明所需权限
- 所有嵌套内容须完整签名：插件、辅助工具、脚本、甚至内嵌的 Python 解释器都需独立签名，否则公证阶段直接报错
- 避免使用非 Apple 官方工具链打包：自制打包脚本若跳过
codesign的递归签名逻辑，极易遗漏子组件
当前规则下，安全不是靠用户“信任”，而是靠机制闭环。签名解决来源可信，公证解决内容可信，运行时校验解决行为可信——三者缺一不可。开发者能做的，是把签名和公证变成 CI/CD 流水线的必经步骤，而非发布前的手动补救。
