Ipa Guard 防护上架，混淆、重签名和回归测试怎么做-Ipa Guard Tutorial

加固做完，装到手机上打不开；或者装上了，点支付就崩。上架前最怕的不是还没加固，是加固把功能弄坏了。更麻烦的是，这种问题经常在提审之后才暴露，一来一回又是几天。

这篇按防护上架的流程走一遍：准备 IPA、选混淆范围、处理资源和调试信息、重签名、真机回归，再提交。用 Ipa Guard 的话，前面几步都在本地完成。

第一步：先准备一份能正常上架的 IPA

动手混淆之前，先确认手上这个包本身是好的。用发布证书加 App Store 类型的描述文件打包，先装到真机上跑一遍主流程；开发证书打出来的包，留着做功能验证可以，拿去提审会被挡。

原包和对应的 dSYM 各存一份。原包是回退的底牌，dSYM 是以后看崩溃日志用的，两个都别丢啊。版本号和构建号也先记下来，后面改完重新处理，记得往上加一位。

打开工具，选好要处理的可执行文件，中间会列出类名，并按风险等级做了标注。文档里写得很清楚：风险等级只是参考，不能当标准，最终还得靠实际项目跑一遍。

所以第一轮别全选。先在低风险类里挑，跑通了再慢慢扩大。界面上的白名单、黑名单、跳过三种模式，本质上是控制「哪些动、哪些不动」，没有哪种更高级，看你项目的结构。

处理项	可以先动	动之前确认
类名	业务层、低风险类	有没有被 storyboard / xib、反射、KVC 按名字引用
方法名	内部实现方法	有没有被 JS 桥接、通知名、动态调用拼出来
属性 / 参数名	普通业务字段	有没有参与 JSON 映射、序列化
资源文件名	图片、音频	代码里有没有写死路径，xib / json 有没有引用
处理强度	先中低	强度越高越难读，出问题也越难回退

配置好之后点保存，下次新版本直接加载，不用从头再选一遍。这个功能对长期维护的项目挺实用，省的是重复劳动嘛。

资源这一层，可以把图片、mp3、xib、sb、json、html 这些文件的名字改掉，重新生成 MD5，图片还能加水印。它的作用是让资源不容易被直接搬走，或者被替换后还看不出来。

但资源改名有个前提：代码里不能有写死的路径。动态加载、按名字拼路径、多语言目录里的引用，都得先确认一遍。改完装到手机上，重点看图片、音频、本地化文案有没有正常出来。

调试信息清理也一样。把自动注释和调试信息删掉，确实会让反编译的人多费点劲；可线上崩溃还要靠 dSYM 符号化，所以清理的是 IPA 里的调试信息，dSYM 该留还得留。这两件事别混在一起。

处理完的 IPA 要重新签名才能装。Ipa Guard 里配好证书和描述文件，测试阶段用开发证书，发布阶段换发布证书。签完直接装到真机上，先看能不能起来。

装不上先查三样：描述文件和证书对不对、开发设备的 UDID 在不在描述文件里、Bundle ID 有没有变。三样都对还装不上，把签名配置删掉重配一遍，比在设备上反复点重试快。

开发证书跑通之后，再用发布证书处理一份最终包。最终包可以通过 TestFlight 或 Ad Hoc 再验一轮，尽量让测试环境和上架环境接近。

这一步是整个流程里最花时间、也最不能省的。

跑的时候把 dSYM 准备好，万一崩了，符号化出来的堆栈才有意义。发现哪个模块出问题，就回到第二步把对应的类或文件从混淆范围里拿掉，重新处理、重新签名、再跑一遍。范围是一轮轮收窄的，不是一次定死的。

保护后的 IPA 用你平时的方式提交就行，Appuploader、Transporter、Xcode 都可以。它负责处理包，不负责上传，这两步分开吧。

提交前把几样东西归档：原始 IPA、混淆配置、dSYM、这一版的类名映射关系。上架之后线上出崩溃，还得靠 dSYM 和映射把堆栈还原成人能看懂的样子。只留一个处理后的包，后面排查会很被动。

还有一点得说清楚：加固解决的是代码被反编译、被抄、被改包的问题，不解决审核判定。审核看的是产品、元数据、隐私和合规，别把加固当成过审的保险。

Obfuscator-LLVM 在编译期做混淆，集成进 Xcode 工具链，原生层覆盖得不错。代价是配置链长，Xcode 大版本更新后经常要等社区适配，Flutter 的 Dart 层、Unity 的 C# 层它管不到。

手动改工程最直接，也不会有工具翻车的风险。但类名、方法名、资源名一个个改，改完还要全量回归，中型项目光这一轮就能耗掉好几天。

Ipa Guard 走的是 IPA 层：不用源码、不碰编译链，多平台项目也能处理，适合手上只有安装包、或者不想为了加固去改工程的情况。三种方式都绕不开回归测试，区别只在改动的入口和覆盖范围。

加固的终点不是处理完成，是装到手机上功能还对才行。加固不是提审前的收尾动作，是回归测试的起点。