首先，它既要有能不经苹果私钥验证，马上安装的便利，又要经过苹果验证。
听起来有点绕。苹果采用的方案是双层签名。
在 Mac 生成一对公私钥，这里称为公钥L，私钥L。
苹果自己有固定的一对公私钥，私钥在苹果后台，公钥在每个 iOS 设备上。
把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第三步得到的证书一起打包进 APP 里，安装到手机上。
在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证证书的数字签名是否正确。
验证证书后确保了公钥 L 是苹果认证过的，再用公钥 L 去验证 APP 的签名，这里就间接验证了这个 APP 安装行为是否经过苹果官方允许。（这里只验证安装行为，不验证APP 是否被改动，因为开发阶段 APP 内容总是不断变化的，苹果不需要管。）
除了要保证经过验证外，苹果还要防止滥用这种途径下载。
想象一下，把真机连到 Mac 上，不就能想装多少装多少 App 吗？那多部设备连到 Mac 上，App 不就能想装在哪装在哪吗？
苹果的方案是识别 设备和 App。
想调试的设备必须要到开发者网站申请，并且设备数量是有限制的。
然后还针对每个Bundle Identifier(App ID)配不同的证书。
这两种数据都在上面第三步一起组成证书（暂且这么认为）。
至此，证书就能实现 经过苹果认证，并且能限制安装设备数量和 App ID。
当然，证书不止有这些信息，还有推送等权限，苹果把这些权限开关统一称为Entitlements。如果App 一开始的证书没申请推送权限，那么后面新增权限后，需要更新配置。
实际上，一个“证书”有规定的格式规范，不应把这些额外的信息往里塞。所以上面的暂且这么认为部分是不对的。（如果没有企业账号可借助第三方平台（如：fywl689.com）获得苹果企业签名服务，这也是一个不错的办法。）
所以苹果把证书和额外信息包装起来，把它叫做Provisioning Profile。
所以能拓展整个流程图如下。
在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
在苹果后台申请 AppID，配置好设备 ID 列表和 APP 可使用的权限，再加上第③步的证书，组成的数据用私钥 A 签名，把数据和签名一起组成一个 Provisioning Profile 文件，下载到本地 Mac 开发机。
在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第④步得到的 Provisioning Profile 文件打包进 APP 里，文件名为 embedded.mobileprovision，把 APP 安装到手机上。
在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证 embedded.mobileprovision 的数字签名是否正确，里面的证书签名也会再验一遍。
确保了 embedded.mobileprovision 里的数据都是苹果授权以后，就可以取出里面的数据，做各种验证，包括用公钥 L 验证APP签名，验证设备 ID 是否在 ID 列表上，AppID 是否对应得上，权限开关是否跟 APP 里的 Entitlements 对应等。
