在 iOS 生态里，所谓“证书签名”并非简单的文件打上印章，而是一条由硬件根信任到应用层层递进的加密链路，任何破环都可能导致系统直接拒绝启动。
技术底层：公钥‑私钥链路
Apple 为每个开发者帐号分配一对 RSA/ECDSA 密钥对，私钥保存在开发者本地或 Apple 的云钥库中，公钥则嵌入到 Apple 颁发的根证书。签名过程实际上是用私钥对 Mach‑O 可执行文件的哈希值进行加密，生成 .signature 区块；系统在加载时，用对应的公钥解密并比对哈希，确保文件未被篡改。
Provisioning Profile 与 Entitlements 的角色
单纯的代码签名只能证明“这段代码出自某个开发者”，但 iOS 还要判断它是否拥有特定的运行权限。Provisioning Profile 把开发者证书、设备 UDID、App ID 以及一组 Entitlements（如 push、keychain、app‑group）打包在一起，形成最终的授权文件。
签名校验流程在 iOS 启动链
系统启动时的校验顺序可以概括为三步：加载根证书 → 验证开发者证书链 → 校验 Mach‑O 哈希与 Entitlements 匹配。如果任意一步失败，dyld 将直接抛出 code signature invalid，并记录在系统日志中，用户只能看到“应用已损坏”。
边界案例：多实例与免后台分身
说白了，想要在同一台设备上运行两个 Bundle ID 相同的 App，必须让系统把它们视为两份独立的签名实体。下面列出目前已知的几类可行路径：
- 使用企业级分发证书重新签名，生成不同的 App ID 与 Entitlements；
- 利用 TestFlight 或内部测试渠道，给每个实例分配唯一的 Provisioning Profile；
- 在越狱环境下直接修改
Info.plist中的CFBundleIdentifier，但会失去官方签名校验。
不过，这些手段都有明确的边界：企业证书的有效期一般为一年，且每个开发者帐号最多只能拥有 100 台设备登记；TestFlight 每个 build 只能保留 90 天；越狱虽能绕过签名，却会触发系统的安全完整性检查（Secure Enclave），导致部分硬件特性失效。
“App Store 之外的签名只能在受信任的企业或开发者账户范围内使用，超出范围即视为安全风险。”——Apple 官方文档
| 场景 | 签名方式 | 有效期 |
| 企业内部部署 | 企业证书 + 自定义 Entitlements | 1 年 |
| 公开测试 | TestFlight 证书 | 90 天 |
| 越狱多实例 | 手动修改签名 | 无限（风险高） |
从技术角度看，苹果证书签名的“应用边界”其实是一把双刃剑：它既能防止恶意篡改，又让合法的多实例需求踩在细碎的合规条款上。要想在不触碰安全红线的前提下实现分身，唯一的突破口仍是通过官方渠道获取合法的多 Bundle ID 授权。