一句话结论：导出安装包不是一个”随便选一个都行”的步骤。选出来的包带的是哪一类凭证、有没有被重新加密、允不允许装到别的设备上，在当时就已经定死了。后面拿去重签时能不能过，八成取决于这一步。

先分清”打包”和”导出”是两件事

编译生成应用主体的过程叫打包，把它装进 IPA 容器并盖章的过程叫导出。我们说的选项，指的是后者。同一个 App，编译出来完全一样，导出时选了不同的方式，产出的包文件大小可能差不多，但内部凭证完全不同，后续能不能被拿去重签，结果天差地别。

四种常见方式分别是怎么回事

• 发布方式：这是提交商店那一版用的。它的特点是干净、规范，没有附加的设备限制，是拿去给签名方重签时最理想的一种。

• 临时分发方式（Ad Hoc）：这一版会带一张写死了设备清单的描述文件，上面列着哪些设备的 UDID（设备唯一识别码）允许安装。好处是兼容性好，坏处是重签时必须把这些设备限制替换掉，对处理方有一定要求。

• 开发调试方式：开发阶段在测试机上跑的那版。它同样绑定了设备，而且绑定逻辑更零散，重签后偶发装不上的概率比前两种高。

• 企业内部分发方式：用企业开发者账号导出、给公司内部员工装的那版。它本身已经是成品分发包，多数情况下不需要再找第三方重签。

选错了会表现成什么现象

最典型的三种：

• 重签直接失败，日志里报”描述文件不匹配”或者”找不到对应的凭证”。这种还算好，至少明确告诉你不行。
• 重签成功，但只有部分设备装得上，其他设备一点就闪退。通常是设备清单没被彻底清干净，残留限制还在起作用。
• 能装上也能打开，但推送、登录、支付其中一个不工作。这类往往不是签名没过，而是 entitlements（权限声明，应用声明自己要用到哪些系统能力的文件）在导出时就被锁成了某一套，重签时没有补上。

第三种最麻烦，因为它在交付那一刻表现不出来，要等功能被用到才暴露。

还有一个隐蔽选项：要不要重新加密

导出流程里有个容易被一路回车跳过的步骤，问的是”要不要为这个应用重新签名并重新加密资源”。如果勾选了，包体内的资源会被这一层再包住。后续重签时，处理方需要先把这层理顺，否则会出现”签名过了但打不开”或者”换了设备就崩”。准备拿去给人重签的包，这一项通常建议不勾。

实操上该怎么选

如果你就是想把产品发给用户装上，自己没有企业开发者账号，准备找签名服务：优先让开发方导出发布方式那一版给你。它是兼容性最好、重签最稳的一种。

如果开发方给的是临时分发版本，也不是不能用，但要提前把三件事说清楚：这一版绑定了哪些设备的 UDID、entitlements 里开了哪些能力（推送、后台定位、钥匙串共享这类）、有没有勾选重新加密。把这些一次性给到处理方，能避免大量返工。

小结

导出方式不是随手点过的默认值。给它 30 秒，确认是哪一种、有没有额外加密、开了什么权限，比事后排查一轮划算得多。把这些信息连同 IPA 一起提交，签名这一步基本就不会在打包环节翻车。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）