在最近几年的项目中，我接触到的 iOS 应用，很少还是“纯原生”。
Flutter、React Native、Unity、Cocos2dx、HBuilder 这些方案，已经成为很多团队的常态选择。
但在安全层面，混合开发带来的一个明显变化是：攻击面变宽了，而防护思路却很容易停留在原生时代。

最初我也犯过这个问题——给 OC / Swift 做了混淆，却发现真正被分析和复用的，反而是 JS、Dart 或资源层逻辑。

混合开发应用被分析时，关注点往往不在代码美不美

从实际逆向角度看，混合应用的突破口通常集中在几处：

• Flutter / Unity 生成的符号结构
• JS、HTML 中的业务逻辑
• 明文资源文件与配置
• Native 与跨平台层的桥接关系

即使 Native 层做了处理，只要跨平台产物保持原样，整体防护效果依然有限。

为什么源码级混淆在混合项目中经常推进困难

理论上，Flutter、Unity 都有各自的混淆或编译参数。但在真实项目里，往往会遇到：

• 构建链条复杂，改动风险高
• 多端共用代码，不方便单独处理 iOS
• 已发布版本需要补保护
• 外部团队交付，仅提供 IPA

在这些条件下，把安全策略放到 IPA 层统一处理，反而更现实。

在混合应用里，混淆目标需要重新划分

在实践中，我逐渐把混淆目标拆成几类，而不是“一刀切”：

• Native 层：类、方法、参数、变量
• 跨平台产物：生成代码的符号与结构
• 资源层：图片、JSON、HTML、JS、音频
• 调试信息：符号、注释、残留日志

这种拆分思路，会直接影响工具选择和配置方式。

多工具组合下的一种可落地方案

在一个 Flutter + iOS 混合项目中，我采用过下面这套组合方式：

• 构建阶段保留默认编译流程，避免引入不确定性
• 业务敏感逻辑尽量后移到服务端
• 在 IPA 阶段统一处理代码与资源

这里用到的 IPA 处理工具之一，就是 Ipa Guard。

Ipa Guard 在混合开发场景中的使用方式

这类工具的价值，并不在于“懂不懂 Flutter”，而在于它处理的是 最终产物。

代码层处理

在 Ipa Guard 中，可以直接针对 IPA 内的可执行文件：

• 查看 OC / Swift 类结构
• 选择需要混淆的类与方法
• 对函数参数、变量进行重命名

对于 Flutter、Unity 生成的二进制内容，这一步的目标并不是“还原逻辑”，而是 破坏符号可读性。

资源层处理

混合应用中，资源往往是最容易被直接拿走的部分。
通过对图片、JSON、HTML、JS 等文件统一重命名，并修改 MD5，可以有效降低直接复用的可能性。

在一些项目里，这一步比代码混淆带来的收益还直观。

调试信息清理

清理符号和注释，对混合项目尤其重要。
跨平台产物一旦保留调试信息，分析成本会明显降低。

配置与测试阶段需要格外谨慎

混合应用对环境依赖更强，所以我通常会：

• 控制混淆范围，不做全量处理
• 每次混淆后立刻真机安装验证
• 优先验证跨平台页面是否正常加载

Ipa Guard 支持直接配置签名并安装测试，这一点在反复验证阶段非常省时间。

混合开发并不意味着“无法保护”

很多讨论里，会把混合开发和“安全性差”直接画等号。
但从实践来看，更大的问题往往是： 安全方案没有跟着技术栈一起演进。

当你接受 IPA 层统一处理这一思路后，混合开发并不会成为不可控因素。

在混合开发成为主流的今天，iOS 应用的安全策略本身也需要“混合”起来。
源码、构建、IPA、运行环境，每一层都做一点，才更接近真实世界的需求。