上周半夜有个做外包的朋友发消息过来，说手上一个 IPA 在 Mac 上重签名一直卡在codesign报错，团队里唯一一台 Mac 还被借去剪视频了，问我在 Windows 上能不能把这事儿直接办了。这类问题我这些年被问过太多次，索性把 IPA 签名工具（Win 版与 Mac 版）这条线上我踩过的、修过的、绕过去的东西一次性理清楚。
先说清楚这篇东西是什么：它讲的不是“某个软件怎么点下一步”，而是 IPA 签名这件事本身——签名签的到底是什么、Win 版工具和 Mac 版工具在原理上差在哪、什么场景该用哪个、出问题怎么查。适合三类人看：刚接手 iOS 内部分发工作的开发、负责把 CI 产物转成可安装包的同学、以及需要在非 macOS 环境上应急处理签名的人。所有操作都建立在一个前提上：你对这个 IPA 里的应用和手上这份证书拥有合法使用权，签名只用于自己团队的应用测试与内部交付。
1. IPA签名这件事，先搞清楚它在签什么
很多人上手就找工具，装完发现一堆选项不知道填什么，根子在于没弄明白 IPA 签名到底在保护什么。iOS 的安装校验不是“看这个包长得像不像正经包”，而是逐层验证：这个可执行文件有没有被改动过、签名用的证书是不是可信的、这份证书有没有被某个描述文件授权去运行这个 Bundle ID、这台设备的 UDID 在不在授权名单里。四个条件里任何一个不成立，安装就会被拒，或者装上了点开就闪退。
工具的职责，说白了就是帮你把这四件事重新对齐一遍。你换了一份证书和描述文件，工具要做的就是：把原来的签名块扒掉、重新计算每个文件的指纹、把新的描述文件塞进去、用新证书重新生成签名块。所以不管界面长得多花哨，底下干的是同一套活儿。理解了这一点，Win 版和 Mac 版的差别就一目了然了——不是功能强弱的问题，是谁更接近官方实现的问题。
1.1 解压一个IPA，你会看到什么
拿一个标准的 IPA，把后缀改成.zip解开，你会看到一个Payload目录，里面躺着一个.app。这个东西本质上是个目录，不是文件。进去之后有几个必须认识的成员：
- 主可执行文件：和
.app同名的那个无后缀文件，是 Mach-O 格式，签名块就挂在它身上 Info.plist：记录 Bundle ID、版本号、最低系统版本、支持的设备架构embedded.mobileprovision：描述文件，CMS 签名过的 plist，包含 Team ID、授权设备列表、entitlements、过期时间_CodeSignature/CodeResources：所有资源文件的哈希清单，plist 格式Frameworks/：动态库和第三方 framework，每一个都是独立的签名主体PlugIns/：扩展，比如分享扩展、通知服务扩展，.appex也是独立签名主体Watch/：带 watchOS 配套应用的话，这里还有一个完整的子 App 要签
我见过最常见的翻车，是有人只签了主包，Frameworks里的东西原封不动。装了能起来，一调起某个第三方 SDK 就崩，日志里就是那句经典的Library not loaded，因为那个 dylib 的签名跟主包的证书对不上。
1.2 签名的三层：资源指纹、描述文件、CMS签名块
把这套机制拆成三层看，理解起来会顺很多。
第一层是资源指纹。签名工具会遍历.app里除签名相关文件之外的所有内容，逐个算 SHA-256（老系统还有 SHA-1），把结果写进CodeResources。系统在启动应用前会重新算一遍，对不上就拒绝运行。这一层防的是“包里被塞了东西”。
第二层是描述文件。embedded.mobileprovision是苹果签发给你的授权文件，里面写清楚了这个证书能签哪些 Bundle ID、能装到哪些设备、能用哪些特殊能力（推送、iCloud、App Groups 之类）。系统会解析它、验证它的签名链、检查是否过期、检查当前设备的 UDID 在不在ProvisionedDevices里。
第三层是CMS 签名块。工具会把前两层算出来的摘要，连同证书链，打包成一个 PKCS#7 结构，写进 Mach-O 的一个特殊段__LINKEDIT里，由LC_CODE_SIGNATURE指向它。这一层防的是“指纹清单本身被篡改”。
三层缺一层都不行。Win 版工具最容易出问题的地方，恰恰是第二层和第三层的衔接——entitlements 提取不全、证书链没装、CMS 结构生成得不规范，都会导致签名“看起来成功了”但装不上。
1.3 证书、描述文件、Bundle ID 的三角关系
这三者的匹配关系是排查问题的第一把钥匙，值得单独拿出来说。
| 组合情况 | 结果 | 典型报错 |
|---|---|---|
| Bundle ID 与描述文件精确匹配 | 正常 | 无 |
Bundle ID 与描述文件是通配符*匹配 | 通常可签，但部分能力不可用 | 推送、App Groups 失效 |
| Bundle ID 不在描述文件范围内 | 失败 | Provisioning profile doesn't include signing certificate或安装后立即失败 |
| 证书与描述文件不是同一个账号签发 | 失败 | A valid provisioning profile for this executable was not found |
| 描述文件过期 | 失败 | This provisioning profile has expired |
| 描述文件里没有目标设备 UDID | 装不上 | 无法安装此应用，部分系统提示完整性校验失败 |
记住一条：描述文件是“授权范围”，证书是“身份证明”，Bundle ID 是“被授权对象”。三者必须能串成一条链，缺一环都白搭。很多新手拿到一份别人的描述文件就想直接用，结果 Bundle ID 对不上，改 Info.plist 里的 Bundle ID 又忘了同步改签名，越改越乱。
2. Win版和Mac版工具的差别，别只看界面
市面上叫“IPA 签名工具”的东西非常多，界面从极简到专业都有，但按底层实现归类，其实就是两条路：一条是调用 macOS 系统自带的codesign、security这些命令行工具，另一条是在非 macOS 环境里自己把签名算法复刻一遍。前者是 Mac 版工具的主流做法，后者是 Win 版工具的必然选择。
这个差别决定了它们的可靠边界。不是“Win 版不行”，而是 Win 版要额外承担“把苹果那套签名协议实现正确”的责任，实现质量参差不齐，出了问题的表现也更隐蔽——Mac 版报错直白，Win 版经常是“签名成功”然后装不上。
2.1 Mac版：站在官方工具链肩膀上
Mac 版工具本质上是codesign的一层壳。不管它界面做得多复杂，底层跑的还是系统自带的签名服务。这个方案的优势非常明显：
- 签名格式天然合规：苹果自己的实现，不可能出现结构错误
- entitlements 处理有官方入口：
codesign -d --entitlements :-能直接把包里的权限描述导出来 - 验证闭环完整：
codesign --verify --deep --strict能在本地就把问题查出来，不用等到装到手机上才发现 - 嵌套签名顺序可控：
--deep虽然被人吐槽，但至少给了个兜底
我自己的习惯是：只要手边有 Mac，绝不用别的方案。哪怕只是临时改个 Bundle ID，也用脚本走codesign，因为出了问题能定位。命令行报错信息虽然不友好，但至少是准确的。
代价是依赖钥匙串。证书必须导入login钥匙串，security find-identity -v -p codesigning能列出来，codesign才认。CI 环境里还得处理钥匙串解锁、set-key-partition-list授权，不然会卡在“用户交互不允许”这类提示上。
2.2 Win版：在Windows上硬复刻一遍签名算法
Win 版工具的处境完全不同。Windows 上没有codesign，只能自己实现。这条路的技术栈大致是这样：
读取.p12，用 OpenSSL 解出私钥和证书链；解析 Mach-O 头，找到或者创建LC_CODE_SIGNATURE段；遍历包内文件算哈希，生成CodeResources；从描述文件里提取 entitlements，构造 entitlements plist；组装 CodeDirectory 结构；最后用私钥对 CodeDirectory 做 CMS 签名，把结果写回 Mach-O。
这一长串里，任何一步的实现细节偏一点，结果就是“签名看着完成了，安装校验失败”。我遇到过的最典型几类：
- CodeDirectory 里的
pageSize用的不是 4096，某些系统版本上会校验失败 - 哈希算法只用 SHA-1，iOS 15 之后对某些场景校验更严
- entitlements 是硬编码的模板，没有从描述文件里提取，导致带推送的应用签完推送失效
- 嵌套的 framework 被跳过，只签了主包
- 证书链不完整，缺中间证书，系统校验证书链时直接不认
这些问题的共同点是：工具不会报错。界面上绿勾一点，包也生成了，你满心欢喜传上去，装的时候来一句“无法安装”，然后就卡住了。
2.3 一张表看清两者边界
| 维度 | Mac版（codesign 方案） | Win版（自实现方案） |
|---|---|---|
| 签名结构正确性 | 官方实现，基本不用担心 | 取决于工具质量，需要实测 |
| entitlements 提取 | 官方命令直接导出 | 需自行解析描述文件，易缺失 |
| 本地验证能力 | codesign --verify完整闭环 | 通常只能做结构自检 |
| 嵌套组件处理 | 脚本可控，能逐个签 | 部分工具只处理主包 |
| 特殊架构支持 | 完整（arm64、arm64e、x86_64） | arm64e 支持常出问题 |
| 环境依赖 | 必须 macOS + 钥匙串 | Windows 即可，无需钥匙串 |
| 适合场景 | 日常签名、CI、问题定位 | 应急、批量、无 Mac 环境 |
结论很直白：能把包在 Mac 上签，就别在 Windows 上签。Win 版的价值在于“没得选的时候还能干”，不在于“比 Mac 版更方便”。
3. 动手前的物料准备
工具只是执行者，真正决定成败的是你手上的物料对不对。这一节说的东西，比工具选型重要十倍。我见过太多人卡在“签名失败”，最后发现是 p12 导出的时候少了证书、或者描述文件根本没包含测试机。
3.1 p12证书的导出与保管
.p12是私钥加证书打包成的容器，导出的时候会让你设一个密码，这个密码后面每一步都要用。导出路径通常是在开发账号后台的证书管理里，选好证书类型，下载.cer，双击导入钥匙串，然后在钥匙串里选中“证书+私钥”这一对，右键导出为.p12。
几个必须注意的点：
- 只导证书不导私钥，等于白导。钥匙串里如果那条证书下面没有展开的私钥项，说明私钥不在这台机器上，导出来的 p12 签不了名
- 证书类型要选对。开发证书只能签测试包，分发证书签的包不能装到未登记的设备上，两者不能混用
- 导出后立刻验证。找台干净的机器导入一次，看能不能正常展开，别等到签名的最后一刻才发现密码记错了
- 备份要加密。p12 加密码之后仍然是可以被暴力破解的，别随手扔在共享盘里
提示：p12 的密码和你账号的登录密码没有任何关系，忘了就是忘了，没有找回渠道，只能重新生成证书。重新生成会导致旧证书签的包全部失效，测试同学手上的包得全部重装。
3.2 描述文件的类型选择
描述文件决定了“这个包能装到哪”。常见的有三种用途：开发调试、内部分发、上架分发。它们的区别主要在设备名单和分发渠道上。
开发用的描述文件会绑定具体的设备 UDID，新增设备必须重新生成描述文件，否则新机器装不上。这是最常见的坑——测试组新来一个同事，包给他装，报“无法安装”，第一反应是签名工具坏了，实际上是他的设备根本没登记。
内部分发用的描述文件不限制设备数量，但有效期的管理更严格，过期之后所有已安装的包都会失效，表现是打开就闪退，卸载重装也没用，必须换新描述文件重签。所以这类项目我都会在日历上挂一个提前一个月的提醒，别等到出事。
还有一点容易被忽略：描述文件里的 entitlements 是硬约束。描述文件里没有开推送能力，你签出来的包就算 Info.plist 里写了推送配置，运行时也拿不到 token。工具里如果有个“自定义 entitlements”的输入框，别乱填，填了描述文件不支持的东西，签名会失败或者运行异常。
3.3 设备UDID登记这件小事
UDID 的获取方式这几年变过几次，现在最稳的办法是通过描述文件或者第三方工具读取。登记流程本身不复杂，麻烦的是流程管理：谁负责收集、什么时候收集、收集完谁去重新生成描述文件、生成完谁通知大家更新。
我在几个小团队里见过的最乱的情况是：描述文件由一个人管，设备名单由另一个人收，两边不同步，结果就是“我这个包装不上”的工单反复出现。后来统一成一个简单的规矩——新设备登记必须走一个固定的表单，每周固定时间统一处理一次，问题立刻少了八成。
另外提醒一句：模拟器的标识和真机不是一回事，别把模拟器的值填进去，填了也没用。
4. Mac版重签名完整实操
这一节给一套可以直接抄的流程。前提是有 macOS 环境、证书已经导入钥匙串、描述文件和 IPA 都在手上。
4.1 解包与旧签名清理
先准备目录，把 IPA 解开：
mkdir -p work && cd work unzip -q ../app.ipa APP_PATH=$(find Payload -maxdepth 1 -name "*.app" | head -1) echo "目标应用: $APP_PATH"接着把旧的签名残留清掉。这一步很多教程会跳过，但不清理的话，某些情况下旧签名块会被保留，导致新签名校验不通过：
rm -rf "$APP_PATH/_CodeSignature" find "$APP_PATH" -name "CodeResources" -delete find "$APP_PATH" -name "embedded.mobileprovision" -delete然后把新的描述文件放进去，同时提取出 entitlements，这是后面签主包必须用的：
cp ../new.mobileprovision "$APP_PATH/embedded.mobileprovision" # 从描述文件中提取 entitlements（老系统用 security cms -D） security cms -D -i ../new.mobileprovision > profile.plist plutil -extract Entitlements xml1 -o entitlements.plist profile.plist这里有个细节：plutil -extract在较老的 macOS 上参数不一样，如果报错，用/usr/libexec/PlistBuddy -x -c "Print :Entitlements" profile.plist > entitlements.plist替代。两条命令效果一样，后者兼容性更好。
4.2 从内往外签：Frameworks、PlugIns、主包
签名顺序不能反。外层签名的CodeResources会记录内层文件的哈希，如果先签外层再改内层，外层立刻失效。所以必须从最里层往外签。
我一般用一个循环把嵌套组件全部扫出来：
# 先签 Frameworks 里的东西 find "$APP_PATH/Frameworks" -name "*.framework" -o -name "*.dylib" 2>/dev/null | while read -r item; do codesign -f -s "iPhone Distribution: XXXX" --timestamp=none "$item" done # 再签 PlugIns 里的扩展 find "$APP_PATH/PlugIns" -name "*.appex" 2>/dev/null | while read -r item; do codesign -f -s "iPhone Distribution: XXXX" \ --entitlements entitlements.plist --timestamp=none "$item" done # 有 Watch 应用的话，这里还要单独处理 Watch 目录，顺序同样是先子后父-s后面跟的是证书名称，用security find-identity -v -p codesigning查出来是什么就填什么，一个字都不能差，包括括号里的 Team ID。--timestamp=none是内部分发场景，不需要可信时间戳，能省不少时间；如果要走正式分发，把--timestamp=none换成--timestamp。
4.3 主包签名与entitlements
最后签主包：
codesign -f -s "iPhone Distribution: XXXX" \ --entitlements entitlements.plist \ --timestamp=none \ "$APP_PATH"--entitlements这一项是重签名的灵魂。不传的话，签出来的包权限就是空的，带推送的应用会拿不到 token，带 App Groups 的应用读不到共享数据，带 Keychain Sharing 的会遇到莫名其妙的登录态丢失。而传错的话（比如传了描述文件里没有的权限），签名直接失败。
所以我在这一步的习惯是：签之前先看一眼 entitlements 内容：
plutil -p entitlements.plist确认里面的application-identifier前缀跟描述文件里的 Team ID 一致，com.apple.developer.team-identifier也是同样的值。这两个不一致是最常见的签名失败原因之一。
4.4 回包、验证与真机安装
打包别用zip，用ditto：
mkdir -p out ditto -c -k --sequesterRsrc --keepParent Payload out/app-resigned.ipa为什么不用zip：zip会丢失符号链接和部分权限位，某些带 framework 符号链接的应用装上去直接崩。ditto是 macOS 自带的，行为跟系统打包一致，稳得多。
打包完先验证：
codesign --verify --deep --strict --verbose=2 "Payload/XXX.app"输出valid on disk和satisfies its Designated Requirement才算过。如果报code object is not signed at all，说明有嵌套组件漏签；报invalid signature，一般是资源被改动过或者签名顺序搞反了。
验证通过再装到真机上。命令行方式可以用xcrun devicectl device install app指定设备，或者用 Xcode 的 Devices 窗口拖进去。装完别只看图标能不能亮，一定要点开跑一遍主流程，特别是涉及推送、支付、登录这些依赖权限的功能。
5. Win版工具的操作路径
Windows 上的操作逻辑跟 Mac 是一一对应的，只是每一项都得手动填或者从文件里选，工具替你做了底层的事。这一节讲怎么把该填的填对，以及哪些事在 Windows 上确实做不了。
5.1 界面里那几个关键输入项
不管界面怎么排，Win 版工具必然有这几个输入：
- IPA 文件路径：注意文件名别带中文和空格，有些工具解析路径时会出问题
- p12 证书路径 + 密码：密码填错的表现通常是“证书加载失败”，但有些工具会静默失败，签出来的包是空的签名，所以要留意日志
- 描述文件路径：用于提取 entitlements 和生成
embedded.mobileprovision - Bundle ID：如果勾了“修改 Bundle ID”，这里填新的；不勾就沿用包内原值
- 输出路径：建议单独目录，别覆盖原包
还有一个经常被忽略的选项：是否签名嵌套框架。有些工具默认不签，有些默认签但不递归。我的建议是找到这个开关并打开，然后在日志里确认Frameworks下的每一个条目都有对应的成功记录。
注意：如果工具提供“自动匹配描述文件”之类的功能，别信。它靠的是 Bundle ID 前缀匹配，遇到通配符描述文件会瞎匹配，签出来的包权限不全。老老实实手动指定文件，多花三十秒，省两小时排查。
5.2 用批处理做批量签名
Win 版工具大多留了命令行入口，参数命名各家不同，但形态大同小异。假设工具的可执行文件叫ipasign-cli.exe，典型的调用长这样：
$signer = "C:\tools\ipasign-cli.exe" $p12 = "C:\certs\dist.p12" $pwd = "证书密码" $prov = "C:\certs\dist.mobileprovision" $src = "C:\build\app.ipa" $dst = "C:\build\out" Get-ChildItem $src -Filter *.ipa | ForEach-Object { $outFile = Join-Path $dst ($_.BaseName + "-resigned.ipa") & $signer --ipa $_.FullName ` --p12 $p12 ` --password $pwd ` --provision $prov ` --output $outFile ` --sign-frameworks ` --log-level debug if ($LASTEXITCODE -ne 0) { Write-Warning "签名失败: $($_.Name)" } }关键是--log-level debug（或者对应的详细日志开关）。Win 版工具的默认日志往往只有一行“完成”，出问题时完全没法定位。开详细日志，你会看到它处理了哪些文件、提取了哪些 entitlements、签了哪些框架，这比界面上的绿勾有用得多。
批量签名还有个容易踩的坑：多个包并行处理时，如果工具内部用了临时目录但没做隔离，会出现互相覆盖。我一般不用并行，串行跑慢点但稳。真要并行，就给每个任务单独的临时目录参数。
5.3 Windows上做不了、也别硬做的事
有几件事必须承认 Windows 方案做不到，硬上只会浪费时间：
第一，本地验证做不了。codesign --verify是 macOS 专属，Windows 上没有等价的完整验证。工具通常只能做结构自检，比如检查签名段有没有写进去。真正的校验只有装到设备上才知道。所以 Win 版签完的包，我的习惯是不要一次性全量分发，先拿一台测试机装一次，确认没问题再批量。
第二，证书链验证依赖预装。某些工具需要你手动把苹果的根证书和中间证书导入 Windows 的证书存储区，否则 CMS 签名会失败或者签名链不完整。这个在新装环境上很容易漏，表现是签名报错但错误信息完全不知所云。
第三，特殊架构和特殊场景支持不完整。带 arm64e 的应用、带 watchOS 配套的应用、带 App Clip 的应用、带自定义动态库注入的应用，这四类在 Win 版工具上的失败率明显高于普通应用。如果包属于这四类，强烈建议想别的办法，别在 Windows 上死磕。
第四，改包内容之后没有回退能力。Mac 上你可以随时解包看结构、逐层调试，Windows 上工具是个黑盒，出问题只能换工具或者换环境。所以我在 Windows 上处理这类任务的定位很明确——应急，不追求一次成功，能过就行。
6. 问题排查速查表
签名这个环节的报错信息覆盖面很广，但真正高频的也就那么几种。这一节把最常见的整理成表，配合排查顺序，能省不少时间。
6.1 装不上：报错信息对照
| 现象/报错 | 最可能的原因 | 处理方式 |
|---|---|---|
| 无法安装此应用，完整性校验失败 | 签名结构不完整，或描述文件与证书不匹配 | 回到 Mac 用codesign --verify验一遍，重新走签名流程 |
| 无法安装，请稍后再试 | 描述文件过期，或设备不在名单内 | 检查描述文件的过期时间和ProvisionedDevices |
| 需要 iOS 更高版本 | 包内MinimumOSVersion高于设备系统 | 改Info.plist或者换低版本系统的设备 |
| 提示设备已注册但装不上 | UDID 格式问题，或描述文件未重新生成 | 重新导出描述文件，确认 UDID 在列表里 |
| 安装进度卡住不动 | IPA 打包方式有问题，符号链接丢失 | 用ditto重新打包 |
| 提示签名者无效 | 证书被吊销，或证书链不完整 | 重新生成证书，或在 Mac 上补装中间证书 |
6.2 装上了闪退：最典型的三种原因
闪退比装不上更难查，因为系统给的提示往往是模糊的。但按概率排，八成集中在三个地方：
第一种，嵌套组件没签或者签名不一致。表现是启动瞬间崩，日志里有Library not loaded或者code signature invalid。查法很简单，在 Mac 上对每一个Frameworks里的文件单独跑codesign -v，哪个报错就是它。
第二种，entitlements 与描述文件不符。表现是启动后走到某个功能点才崩，比如调推送、读写 Keychain、访问 App Group 容器。查法是用codesign -d --entitlements :-导出签名后的权限，跟描述文件里的一一比对，多出来的项就是问题。常见的是get-task-allow被错误地设成了 true，测试包没问题，正式包会出状况。
第三种，架构缺失。某些精简过的 IPA 只保留了 arm64，但设备或者某些系统组件需要别的架构。表现是启动就退，日志里能看到no suitable image found。查法用lipo -info看主可执行文件和各个 framework 的架构列表。
6.3 一份排错顺序清单
我自己的排查顺序是固定下来的，从便宜到贵，能少走很多弯路：
- 先看描述文件：过期没有、Bundle ID 匹配没有、设备在不在名单里、entitlements 有哪些。这四项能解决一半问题
- 再看证书：类型对不对（开发还是分发）、有没有被吊销、证书链完不完整。在 Mac 上用
security find-identity -v -p codesigning一眼就能看出证书是否有效 - 然后看嵌套签名：把
Frameworks、PlugIns、Watch逐个验一遍，别只看主包 - 接着看架构：
lipo -info过一遍，确认目标设备需要的架构都在 - 最后看打包：用
ditto而不是zip，问题往往就出在这一步
提示：排查的时候优先复现“最小失败案例”。比如怀疑是某个 framework 的问题，就只签主包不签 framework，看现象是否一致；怀疑是 entitlements 的问题，就用一个不带任何特殊权限的描述文件签一遍做对照。二分法比盯着日志猜要快得多。
7. 几条踩过坑之后才明白的经验
写了这么多流程，最后说几条不在任何文档里、但确实影响效率的东西。
证书和描述文件的有效期要当成运维指标来管。我见过一个项目，内部分发的描述文件到期，全公司几百台设备的应用同时打不开，用户以为是自己手机坏了，客服电话被打爆。后来做法很简单：把所有证书和描述文件的有效期录进一个表，提前 60 天、30 天、7 天各触发一次提醒，谁名下的谁处理。这件事的成本极低，收益极高。
签名脚本要跟着仓库走，不要留在某个人电脑上。很多团队的签名命令是某位同学在终端里手敲的，人一休假，整个发布流程就停摆。正确做法是把签名逻辑写成脚本提交进仓库，参数从环境变量或者配置文件读，任何人拉下来都能跑。脚本里把证书名称、描述文件路径这些易变的东西抽成变量，改的时候只改一处。
Win 版工具要当成“一次性应急手段”，别纳入常规流程。偶尔救急很好用，但一旦变成常规路径，问题就会积累：没人验证、没人维护、换个工具就全乱。我给自己定的规矩是，Windows 上签出来的包一律标记为“待验证”，必须有一台真机装过、跑过主流程，才能进测试分发池。
改 Bundle ID 之前先想清楚为什么要改。绝大多数情况下不需要改。需要改的场景通常是同一份代码要出两个可以并存的包，这时候要注意的不只是Info.plist里的 Bundle ID，还有推送证书、URL Scheme、Keychain 访问组、App Group 标识，这些都要同步调整。改漏一个，表现就是某个功能静默失效，查起来非常费劲。
留一份干净的原始 IPA。重签名是个有损操作，签错了不一定能退回原状态。我习惯在构建产物出来的时候单独存一份未签名的原始包，任何重签名都从它出发，而不是在已经签过的包上反复折腾。这个习惯救过我好几次——某次在已经改过 Bundle ID 的包上继续操作，越改越乱，最后从原始包重来，十分钟解决。
最后，记录每次成功的参数组合。工具版本、证书名称、描述文件、签名选项，这一套组合跑通了就存下来。下次遇到同类包，直接套用，比重新摸索快得多。签名这件事的技术含量不高，但细节密度极大，靠记忆是靠不住的，靠记录才靠得住。
