我注意到一个现象：一提到马甲包过审，讨论很快就会滑向「混淆强度开多少」「类名改得够不够乱」。工具的参数被翻来覆去地调，真正导致被拒的那几条，反而没人提。

这篇不聊怎么绕过审核，那条路本身就不成立，风险也摆在明面上。只把三个常见的误判拆开，再说 Ipa Guard 在合规的代码保护里能做什么、不能做什么。

误判一：二进制不像了，就能过审？

苹果审核里有一条 4.3，叫 Spam，管的就是重复应用、模板应用和批量提交。它的判断不只看二进制：元数据、截图、功能、内容、账号和提交历史，都在考察范围里。

混淆能把类名、方法名、资源名改成乱码，让两个包的符号特征看起来不一样。可产品还是那个产品：功能一样、页面一样、内容一样、后台一样。审核看的是「这是不是另一个 App」，不是「这两个包的文件名像不像」。反正审核看的是产品本身，不是符号表。

需要说清楚：马甲包本身违反 App Store 的 4.3 条款。被识别之后，轻则拒审、下架，重则封开发者账号，连带影响同一账号下的其他应用。混淆工具不是过审保险，任何承诺「保证过审」的说法都别信啊。

误判二：换账号、换素材，就是新应用

换个开发者账号、换一套图标和截图、把应用名改一改，这是很多人理解里的「新包」。但审核不是只看提交入口。功能结构、界面布局、后端接口、隐私行为，甚至更新节奏，都可能成为判断依据。

更现实的是，账号本身也是资产。拿同一个账号反复提交相似应用，风险会累积；被判定为 spam 之后，账号下的正常应用也会被牵连。这笔账，比多做一轮 功能差异要贵得多吧。

如果两个产品在功能、内容、目标用户上真的不同，那它们本来就是两个产品，不需要伪装；如果本质上是一个产品，换名字、换图标、换账号都只是表面功夫，4.3 依然适用。

误判三：混淆强度越高越保险

就算不谈审核，混淆强度也不是越高越好。

类名、方法名改得太狠，反射调用、KVC、storyboard 里的类名引用、JS 与原生之间的桥接，都可能断掉。资源文件名批量改成乱码，xib、sb、json 里写死的路径也会对不上。调试信息删干净之后，线上崩溃的堆栈也跟着变得难读。

Ipa Guard 的界面里给每个类、每个文件标了风险等级，但文档里写得很清楚：风险等级只是参考，不能当标准，最终还得靠实际项目跑一遍。白名单模式、黑名单模式、处理强度，这些参数的意义是「控制范围」，不是「拉满就安全」。

稳妥的做法是先在低风险项里选，装到真机上，至少把核心流程走一遍：登录、支付、列表、详情、分享，一个都别漏。混淆出问题，经常不是崩溃，而是某个功能悄悄失效。

它在合规那部分能做什么

把「过审」这个目标拿掉，它的定位其实挺清楚：保护已经编译好的 IPA，降低被反编译、被抄、被改包的风险。

  • 不需要源码，直接对 IPA 处理，所有操作在本地完成，不上传服务器。
  • 代码层面可以混淆 OC、Swift、C++、Dart 的类名、方法名、属性名和参数名，覆盖 OC、Swift、Flutter、Unity3D、Cocos2dx、H5、HBuilder 这些项目类型。
  • 资源层面可以改图片、mp3、xib、sb、json、html 等文件的名字，重新生成 MD5，图片还能加水印。
  • 可以清理自动注释和调试信息，增加反调试的难度。
  • 处理完能配置签名参数重签名，装到真机上验证功能。

这些能力解决的是「别人能不能读懂你的代码、能不能把你的资源搬走」，不是「苹果认不认这是一个新产品」。两件事别混在一起嘛。

和 Obfuscator-LLVM、手动改工程比一比

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

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

Ipa Guard 走的是 IPA 层：不用源码、不碰编译链，多平台项目也能处理，适合手上只有安装包、或者不想为了加固去改工程的情况。它不解决审核判定，也不替代代码层面的安全设计。

回到马甲包过审这个问题：它卡住的从来不是「二进制像不像」，而是「产品是不是同一个」。

混淆改的是代码的可读性，不是产品的独特性。

真要做第二个产品，先把功能、内容、用户和合规这几件事做出真正的差异；加固是之后的事，用来保护你做出来的东西不被抄走。顺序反了，工具再强也帮不上忙啊。