在最近几年的项目中，我接触到的 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、运行环境，每一层都做一点，才更接近真实世界的需求。