如何签名 IPA 以及 iOS 应用

共计 6411 个字符，预计需要花费 17 分钟才能阅读完成。

最近在编译一些开源的 Flutter 应用给自己的 iOS 安装，突然发现自己对 iOS 的签名机制其实理解得很模糊。虽然平时用 Xcode 开发应用时，大部分情况下勾选"Automatically manage signing"就能搞定，但当遇到需要重签名第三方 IPA 包、或者给测试团队分发应用时，就发现自己对证书、描述文件这些东西一知半解。特别是看到证书过期、描述文件不匹配这类报错时，总是不知道从何下手。

于是花了点时间深入研究了一下 iOS 的签名机制，发现这套体系虽然看起来复杂，但理解了背后的原理之后，很多问题就迎刃而解了。今天就想和你分享一下我的学习心得，从证书的本质讲起，到实际操作重签名 IPA 包，再到各种签名方式的对比。

签名机制的底层逻辑

iOS 的签名机制本质上是为了解决一个核心问题：确保安装到苹果设备上的应用是可信的、未被篡改的？苹果采用了一套基于[[非对称加密]]的双重签名机制来实现这个目标。这套机制的设计很巧妙，既保证了安全性，又让苹果能够完全控制 iOS 生态系统中的应用分发。

在深入细节之前，我们先理解几个核心概念。首先是公钥和私钥，这是非对称加密的基础。简单来说，私钥用来签名，公钥用来验证签名。私钥必须妥善保管，而公钥可以公开分发。当你用私钥对一段数据签名后，任何人都可以用对应的公钥来验证这个签名是否有效，从而确认数据的完整性和来源的可信度。

接下来是证书的概念。证书本质上就是公钥加上一些附加信息（比如证书持有者的身份信息），然后由权威机构（在 iOS 体系中就是苹果）用他们的私钥签名生成的文件。当你在本地生成一对公私钥后，把公钥上传给苹果，苹果用他们的私钥对你的公钥进行签名，就生成了一个证书文件。这个证书就证明了"这个公钥是经过苹果认证的"。

然后是描述文件（Provisioning Profile），这是整个签名体系中最关键的部分。描述文件把很多信息打包在一起：你的证书、应用的 Bundle ID、允许安装的设备列表（如果是开发或 Ad Hoc 签名）、应用可以使用的功能权限等。描述文件本身也是由苹果用私钥签名的，这就确保了描述文件的内容不会被篡改。

现在来看看整个验证流程是如何工作的。当你用 Xcode 打包一个应用时，Xcode 会用你本地的私钥对应用进行签名，同时把对应的描述文件嵌入到 IPA 包中。当用户把这个应用安装到设备上时，iOS 系统会执行一系列验证步骤。首先，系统用内置的苹果公钥验证描述文件的签名，确认描述文件是由苹果签发的。然后，系统从描述文件中提取出你的证书，再用苹果公钥验证这个证书的有效性。最后，系统用证书中的公钥验证应用本身的签名。只有所有验证都通过了，应用才能被安装和运行。

这就是所谓的"双重签名"机制：第一层签名是苹果对你的证书和描述文件的签名，第二层签名是你用自己的私钥对应用的签名。这种设计让苹果既能控制谁可以签名应用（通过签发证书），又能控制应用可以运行在哪些设备上、可以使用哪些功能（通过描述文件）。

理解了这个底层逻辑后，很多看似复杂的概念就容易理解了。比如为什么证书分为开发证书和发布证书？因为它们对应的是不同的使用场景和权限。为什么描述文件会过期？因为苹果需要定期更新和审查开发者的资质。为什么有些应用需要在设置中手动信任证书？因为那些应用使用的是企业证书，不是通过正常的 App Store 分发渠道安装的。

从我的实践经验来看，理解这套机制不仅能帮你解决签名相关的技术问题，还能让你更好地理解苹果对 iOS 生态的控制策略。苹果通过这套签名体系，实现了对应用分发的完全掌控，同时也为用户提供了相对安全的应用环境。虽然这套机制对开发者来说增加了一些复杂度，但从安全角度来看，它确实在很大程度上保护了用户的利益。

证书和描述文件的实战理解

先说证书。证书主要分为两大类：开发证书（Development Certificate）和发布证书（Distribution Certificate）。开发证书是用来在开发阶段签名应用的，它允许你把应用安装到特定的测试设备上进行调试。一般来说，团队中的每个开发者都可以有自己的开发证书。而发布证书则是用来签名最终发布的应用，可能是上传到 App Store，也可能是用于企业内部分发或 Ad Hoc 分发。

这里有个细节需要注意：从苹果开发者网站下载的证书文件（.cer 格式）只包含公钥，不包含私钥。私钥是你在本地生成证书签名请求（CSR）时创建的，永远保存在你本地的钥匙串中。这就是为什么当你换了一台电脑后，即使下载了证书文件，也可能无法正常签名应用。因为新电脑上没有对应的私钥。解决办法是从原来的电脑上导出包含私钥和证书的 .p12 文件，然后在新电脑上导入。

描述文件的类型就更多了。对于开发阶段，我们用的是 Development 类型的描述文件。这种描述文件中会包含允许安装应用的设备列表（通过设备的 UDID 标识），所以只有在列表中的设备才能安装这个应用。当你连接一个新的测试设备到 Xcode 时，Xcode 会自动把这个设备添加到你的开发者账号中，并更新描述文件。

Ad Hoc 类型的描述文件和开发描述文件类似，也需要指定设备列表，但它用于分发给测试用户，而不是开发调试。这种方式的限制是每个开发者账号最多只能添加 100 个设备，而且这个设备数量是按年度重置的。在实际使用中，我发现 Ad Hoc 分发适合小规模的测试，比如给几个核心测试用户分发内测版本。

App Store 类型的描述文件用于提交到 App Store 的应用，它不需要指定设备列表,因为任何 iOS 设备都可以从 App Store 下载安装。这种描述文件的验证是最严格的，苹果会在审核时对应用进行各种检查。

还有一种特殊的企业描述文件（Enterprise/In-House），这是企业开发者账号专用的。使用这种描述文件签名的应用可以安装在任意设备上，不受设备数量限制，也不需要经过 App Store 审核。但用户在安装时需要在设置中手动信任企业证书。这种方式主要用于企业内部应用的分发，比如员工管理系统、内部工具等。

在 Xcode 8 之后，苹果引入了"Automatically manage signing"功能，大大简化了证书和描述文件的管理。启用这个选项后，Xcode 会根据你的开发者账号自动生成和管理证书、描述文件。对于大多数日常开发场景，这个自动管理功能已经足够了。但是，当你需要更精细的控制时，比如需要使用特定的证书签名、或者需要在多台电脑之间共享证书，就需要手动管理这些文件。

我的建议是，在刚开始学习 iOS 开发时，可以先用自动管理来快速上手。当你对整个体系有了基本了解后，再尝试手动管理证书和描述文件。这样既能避免一开始就被复杂的概念搞晕，又能在遇到问题时有能力深入排查。

如何重签名 IPA 文件

掌握了签名机制的原理后，我们来看看一个很实用的技能：如何重签名一个 IPA 文件。这个需求在很多场景下都会遇到，比如你拿到了一个第三方的 IPA 包，想用自己的证书签名后安装到测试设备上；或者你想修改应用的 Bundle ID，用不同的描述文件重新打包。

重签名的核心工具是 codesign 命令。这是 macOS 系统自带的代码签名工具，功能很强大。不过直接使用 codesign 有很多细节需要注意，稍有不慎就会导致签名失败或者应用闪退。让我们一步一步来看。

首先，你需要准备好用于签名的证书和描述文件。可以用以下命令查看系统中可用的签名身份：

security find-identity -v -p codesigning

这个命令会列出所有可用于代码签名的证书，包括证书的名称和唯一标识。记下你想用的证书名称，后面会用到。

接下来解压 IPA 文件。IPA 文件本质上就是一个 zip 压缩包，所以可以直接用 unzip 命令解压：

unzip -oqq original.ipa -d temp

解压后会得到一个 Payload 目录，里面包含 .app 文件。这个 .app 文件就是应用的主体。

在重签名之前，有几个准备工作要做。首先，如果你用的是免费的个人开发者账号，需要删除应用中的扩展和插件。因为免费账号无法签名 App Extension 和 WatchKit 扩展。这些扩展通常位于 .app/PlugIns 目录下，直接删除即可。

然后要处理 Frameworks。这是重签名过程中最容易出错的地方。IPA 包中可能包含多个动态库（.framework 文件），这些动态库也需要单独签名。如果不签名，应用安装后会立即闪退。签名 frameworks 的命令是：

codesign -fs "iPhone Developer: your_name" Payload/YourApp.app/Frameworks/*.framework

这里要注意，需要遍历 Frameworks 目录下的所有 .framework 文件逐个签名。

接下来需要准备一个 entitlements.plist 文件。这个文件定义了应用的权限，比如推送通知、iCloud、App Groups 等。可以从描述文件中提取这些信息：

security cms -D -i embedded.mobileprovision > profile.plist
/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' profile.plist > entitlements.plist

这两个命令首先把描述文件转换成可读的 plist 格式，然后提取其中的权限信息。

现在可以进行真正的重签名了。首先替换应用中的描述文件：

cp new.mobileprovision Payload/YourApp.app/embedded.mobileprovision

然后对 .app 包进行签名：

codesign -fs "iPhone Developer: your_name" --entitlements entitlements.plist Payload/YourApp.app

如果一切顺利，codesign 命令会输出"Payload/YourApp.app: replacing existing signature"这样的信息，表示签名成功。

最后，把重签名后的应用重新打包成 IPA：

zip -qr resigned.ipa Payload

整个过程看起来步骤很多，但实际操作几次后就会熟练了。我在实践中遇到过几个常见问题。第一个是 Bundle ID 不匹配。重签名时使用的描述文件必须和应用的 Bundle ID 一致，否则会签名失败。如果需要修改 Bundle ID，需要编辑 .app/Info.plist 文件。

第二个问题是权限冲突。如果 entitlements.plist 中声明了某些权限，但描述文件不支持这些权限，也会导致签名失败。比如，免费账号的描述文件不支持 iCloud 和推送通知，如果强行签名包含这些权限的应用，就会出错。

第三个问题是可执行文件权限。有些应用在解压后，可执行文件会失去执行权限。这时需要手动添加：

chmod +x Payload/YourApp.app/YourApp

从我的经验来看，熟练掌握重签名技能后，会发现很多应用分发和测试的问题都能迎刃而解。比如，当你需要把一个应用分发给不同团队成员，但他们的测试设备不在你的账号设备列表中时，就可以让他们提供自己的证书和描述文件，然后重签名后分发。或者当你拿到一个旧的 IPA 包，证书已经过期时，也可以用新的证书重新签名。

几种签名方式的对比

在了解了签名的原理和操作方法后，我们来看看实际应用场景中的几种主要签名方式。每种方式都有各自的适用场景、优缺点和成本考量。

最常用的是开发者签名，也就是通过正常的开发者账号进行签名。这种方式分为开发签名和 Ad Hoc 签名。开发签名主要用于日常开发和调试，设备需要连接到 Xcode 或者预先添加到开发者账号的设备列表中。Ad Hoc 签名则用于分发测试版本，可以通过企业分发平台或者直接把 IPA 文件发送给测试用户。这两种方式的共同限制是设备数量，每个开发者账号每年只能添加 100 个设备。

对于需要大规模内部分发的场景，很多人会想到企业签名。企业签名使用的是苹果企业开发者账号（Apple Developer Enterprise Program），年费 299 美元。使用企业证书签名的应用可以安装在任意数量的设备上，不受 100 个设备的限制。这听起来很诱人，但实际使用中会发现企业签名有个致命的问题：容易掉签。

所谓掉签，就是苹果突然撤销了企业证书，导致所有使用这个证书签名的应用都无法打开。这种情况通常发生在苹果检测到某个企业证书被滥用时，比如用于分发大量非内部应用。一旦掉签，所有用户的应用都会立即无法使用，这对业务的影响是灾难性的。而且，企业签名的应用在安装时需要用户手动在设置中信任证书，这个额外的步骤会影响用户体验，也容易引起用户的疑虑。

为了解决企业签名的不稳定问题，市面上出现了一种叫做"超级签名"的方案。超级签名的原理其实很巧妙：它利用了苹果为开发者提供的 Ad Hoc 分发机制。当用户要安装应用时，超级签名系统会获取用户设备的 UDID，把这个 UDID 添加到开发者账号的设备列表中，然后用 Ad Hoc 方式重新签名应用，最后分发给用户。整个过程是自动化的，用户感知不到。

超级签名相比企业签名有几个明显的优势。首先是稳定性更好。因为用的是正常的开发者账号和 Ad Hoc 分发通道，不太容易被苹果封禁。其次是用户体验更好，应用可以直接安装，不需要手动信任证书。但超级签名也有自己的局限性：由于每个开发者账号只能添加 100 个设备，要支持大量用户就需要购买和管理大量开发者账号。所以超级签名的服务通常按安装次数收费，单次安装的成本大约在 12-16 元。

从成本角度来看，企业签名按月收费，根据服务商和证书质量不同，从几百元到几千元不等。如果你的应用用户量大、需要频繁分发更新，企业签名的成本会比较划算。但如果用户量不大、更新不频繁，超级签名可能是更合适的选择。特别是对于刚开始做应用分发的团队，我建议先从超级签名开始尝试，等用户规模上来后再考虑企业签名。

还有一种特殊的签名方式叫 TestFlight。这是苹果官方提供的测试分发平台，可以理解为正规渠道的测试版分发。使用 TestFlight 分发的应用不需要添加设备 UDID，用户只需要在 App Store 中安装 TestFlight 应用，就可以接收和安装测试版本。TestFlight 最多可以邀请 10000 个外部测试用户，这对大多数应用来说已经足够了。而且 TestFlight 完全免费，稳定性也最好。唯一的缺点是应用需要经过苹果的简化审核，虽然比正式上架快很多，但还是需要等待审核时间。

在我自己的实践中，对于正常的业务应用，我都优先考虑 TestFlight。它不仅稳定可靠，而且还能收集到崩溃报告和用户反馈，这对改进应用质量很有帮助。只有在需要快速迭代、不想等待审核，或者应用包含一些不适合审核的功能时，才会考虑其他签名方式。