苹果生态里有几个词长得很像：签名、公证、认证、描述文件。团队内部沟通时混用问题不大，但一旦涉及排查问题或者跟服务商对接，混用就会直接导致判断跑偏——最常见的就是把 macOS（苹果桌面操作系统）上的公证要求，套到 iOS（苹果移动操作系统）分发的场景里，然后得出一堆错误结论。
一句话结论
公证（Notarization，苹果对软件包做的一次自动安全扫描）是 macOS 平台上针对桌面软件的机制，由苹果服务器扫一遍包、确认没有已知恶意代码后发一张「票据」；iOS 签名则是移动端的身份与完整性机制。两者目的不同、平台不同、执行方式也不同，不能互相套用。
公证是怎么运作的
开发者把做好的桌面软件上传到苹果，苹果的服务器自动扫一遍，检查里面有没有已知的恶意代码、有没有用被禁止的技术。扫描通过后，开发者可以把结果「钉」到自己的包上，也可以选择让苹果把结果放到网上供系统查询。
之后用户在自己的 Mac 上打开这个软件时，系统会去核对：这个包有没有被公证过？如果是，直接放行；如果没有，弹出警告拦一道。整个过程不需要开发者守着，是自动化跑的。
注意这里的关键点：公证是一次性的、在分发之前完成的，检查的是「这个包干不干净」，查完的结果跟包绑定。
iOS 签名又是怎么运作的
移动端的逻辑不一样。签名是开发者用自己的证书给包盖章，证明「这个包是我出的、里面的内容没被改过」。设备安装时会核验证书是否有效、包的内容是否和签名时的记录一致。
启动阶段还要再做一次在线核对——确认这张证书此刻没有被吊销。这一步是持续性的、每次都可能发生的，跟公证那种「查一次就完事」的模式完全不同。
也就是说，公证解决的是「这个软件有没有毒」，iOS 签名解决的是「这个软件是谁出的、有没有被改过、出证的人现在还算不算数」。前者是安全扫描，后者是身份体系。
为什么容易搞混
有三个原因。
第一，都叫「苹果的要求」。团队听到「苹果不通过就装不了」，很容易把两个机制的后果混为一谈。实际上公证不过关的后果是 Mac 上弹警告、用户手动放行还能用；iOS 签名不过关的后果是直接装不上或者打不开，用户没有手动放行的余地（除了在设置里手动信任企业级开发者这一条特定路径）。
第二，都涉及「上传给苹果」这个动作。公证要上传包给苹果扫描，某些签名方式也需要把设备信息或者包提交到苹果的体系里。动作相似，目的完全不同。
第三，中文资料里这两个词的译法不统一，有的地方把签名也说成「认证」，有的把公证说成「认证」，进一步加剧混淆。
混用会导致哪些误判
- 误判一：以为 iOS 的包也要过公证。不需要。移动端的包走的是签名体系，没有「先提交给苹果扫一遍」这一步。
- 误判二：以为公证过了就等于长期安全。公证只说明提交那一刻没查到问题，不代表此后不会被吊销。iOS 那边更明显：证书随时可能被吊销，一次通过不代表一直有效。
- 误判三：把 macOS 上的用户放行经验搬到移动端。桌面端用户可以右键打开绕过警告，移动端用户遇到拦载基本只能通知开发者处理，没有对等的自助路径。
- 误判四：以为不联网就永远查不到。离线时设备确实可能放行，但这不是漏洞而是设计上的容忍窗口，一旦联网核对到状态变化，照样会被拦。
对接服务商时该怎么问
如果你的业务同时涉及桌面端和移动端，提需求时把话说具体，能省掉大量来回。比如不要问「你们做不做公证」，而是说清：这个包是跑在 Mac 上还是 iPhone 上；需要的是桌面端的公证票据，还是移动端的签名证书；出问题的时候希望谁来处理。
反过来也一样，服务商如果拿公证的说法来解释移动端的稳定性承诺，基本可以判断他没分清楚——这两套机制连触发时机都不一样，用其中一套的逻辑去保证另一套的表现，本身就不成立。
小结
记住一句话就够：公证查的是「干不干净」，一次性的；iOS 签名管的是「谁出的、还算不算数」，持续的。把这两个词在团队里统一说法，能少掉不少无效沟通，也能避免在选型时被似是而非的说法绕进去。
我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920 微信：A-mk5888）
