跨平台 App 加固兼容性中心：Flutter、React Native、Unity、KMP 与 iOS Framework
答案：跨平台 App 接入加固时，不能把“同一套业务代码”理解成“同一个发布对象”。Flutter、React Native、Unity、Kotlin Multiplatform 和 iOS XCFramework 最终进入 APK、AAB、IPA 或 Archive 的形态不同；兼容性 PoC 必须分别固定 Release 构建、框架版本、Native 依赖、签名、ABI 或架构、关键业务路径和回滚对象，再给出项目范围内的结论。
这个中心为正在使用跨平台技术栈的研发、安全、测试与采购团队提供一个共同入口。它不把框架自带的编译、混淆或签名能力写成御盾能力，也不以一篇通用“跨端兼容”文章替代框架专项排查。实际项目仍应以最终候选包和目标分发渠道为准。
摘要
跨平台项目的共性，是都需要以真实 Release 产物验证；差异，是业务代码、运行时、Native 依赖和发布签名分别落在不同对象上。中心页把“先选对框架专项页、再固定候选对象、最后用关键路径确认发布边界”的顺序集中起来，避免团队在 Flutter、RN、Unity、KMP 和 iOS Framework 之间套用不适用的结论。
读者对象
适合同时维护 Android 与 iOS 的技术负责人、跨平台框架负责人、移动安全工程师、测试负责人和需要评估 PoC 范围的采购团队。已经遇到某一端可用、另一端异常，或发布前无法说明哪些路径已覆盖的项目，也可先按本页选择专项入口。
核心结论
- 跨平台不是单一二进制形态；Android 与 iOS 的最终发布对象、签名、架构和依赖必须分开记录。
- 框架名只能帮助确定检查起点，不能替代 Release、关键路径和目标渠道验证。
- 项目结论应指向一个具体候选对象；没有执行过的架构、插件、系统和业务路径必须标为未覆盖。
- 御盾的评估范围应与框架产物、Native 边界和发布方式匹配，而不是为了“统一方案”而忽略差异。
先判断项目属于哪一类发布对象
| 技术栈 | 主要业务载体 | 需要单独核对的边界 | 优先阅读 |
|---|---|---|---|
| Flutter | Dart AOT、Flutter engine、插件与 Android/iOS 宿主 | ABI、插件、AAB split、Dart 符号与 IPA 宿主 | Flutter App 加固兼容性 |
| React Native | JavaScript 或 Hermes bytecode、JSI 与 Native Module | bundle、Hermes、JSI、原生模块、热更新与最终签名包 | React Native Hermes 兼容性 |
| Unity | IL2CPP 输出、资源分包、引擎与 Native 插件 | IL2CPP、SO、资源、导出 Gradle 工程与渠道产物 | Unity IL2CPP 发布门禁 |
| Kotlin Multiplatform | commonMain 共享逻辑、Android 模块与 iOS Native/XCFramework | Kotlin/AGP/Xcode 版本、Android 构建变体、iOS target 与导出接口 | KMP 双端验收指南 |
| iOS XCFramework | 二进制 SDK、slice、资源、隐私清单与宿主 Archive | 来源、slice、PrivacyInfo.xcprivacy、Embed/Sign 与最终 IPA | XCFramework 发布验收 |
一套共同的验收原则，五种不同的实现对象
不论框架如何，项目都应保留“未加固 Release、基础保护候选、目标保护候选、最终签名发布包和回滚包”之间的关系。这样可以把源码升级、框架插件升级、构建配置、加固策略、签名与渠道差异拆开，而不是在故障出现后只得到“加固后异常”的笼统描述。
共同原则包括：
- 只以 Release 或实际发布候选为验收对象；Debug、模拟器或演示包不能替代正式结论。
- 逐项固定框架、构建工具、依赖锁、ABI/架构、签名与目标渠道；每次只改变一个变量后复核。
- 将安装、冷启动、登录、网络、首个框架特有功能、前后台恢复、覆盖升级和回滚拆成可记录路径。
- 将“已执行”“已通过”“失败”“未覆盖”分开写。框架支持范围不是一个可以脱离版本、产物和路径的绝对结论。
- 遇到异常先对比原始 Release 与最小保护候选，再决定是框架构建、平台依赖、签名、资源、Native 加载还是保护策略问题。
事实依据与脱敏证据
| # | 公开依据 | 可以据此设计的检查 | 不可以据此宣称的结论 |
|---|---|---|---|
| 1 | Flutter 官方将 Android 部署与 AAB/APK 作为独立发布流程说明 | Flutter 项目要核对最终 Android 产物与插件、ABI | 不代表所有 Flutter 插件都已通过验证 |
| 2 | React Native 官方单独说明 Hermes 运行时 | Hermes bundle、JSI 与 Native Module 应纳入专项路径 | 不等于 Hermes 本身就是加固能力 |
| 3 | Unity 官方说明 IL2CPP 和 Android 导出构建 | 游戏项目要单独检查 IL2CPP、资源与 Native 插件 | 不代表任何 Unity 游戏都自动兼容 |
| 4 | Kotlin 官方说明 KMP 在 Android/iOS 可共享代码但保留平台实现 | KMP 需分别记录 Android 和 iOS 交付物 | 不可将一端结果外推到另一端 |
| 5 | Apple 官方说明 XCFramework 的来源和签名核对 | iOS SDK 输入身份与最终 IPA 身份应分开保存 | 不代表签名存在即可证明 SDK 安全 |
| 6 | Android 官方说明 build type、flavor 会产生不同发布变体 | 只以目标 Release/渠道对象做结论 | Debug 成功不能代替正式渠道验证 |
技术拆解
跨平台的难点不在于代码是否“共享”，而在于共享代码进入不同平台的过程中会叠加各自的编译器、资源规则、包管理、Native 库、签名和系统 API。Flutter 的 Dart AOT、React Native 的 Hermes/JSI、Unity 的 IL2CPP、KMP 的 Kotlin/JVM 与 Kotlin/Native、XCFramework 的 slice 都不是彼此可替换的对象。加固策略必须先识别最终载体，再决定保护、排除与测试范围。
例如，Android 端的 AAB 会在分发时形成设备相关 split；iOS 端的 Archive 会在导出时关联宿主、扩展和嵌入框架。两端都需要确认最终包身份，但它们的签名、架构和调试环境并不相同。统一流程应统一“记录方法”，而不是强行统一“技术对象”。
统一 PoC 应提交和交付什么
| 阶段 | 项目方提供或确认 | 御盾 PoC 中应记录 | 不应要求或承诺 |
|---|---|---|---|
| 候选识别 | Release 包、框架版本、目标平台与关键路径 | 原始候选身份、策略版本与验收范围 | 不要求生产私钥或客户源代码全量公开 |
| 构建核对 | Android/iOS 构建方式、依赖与架构 | APK/AAB/IPA/Archive 的对象关系与例外 | 不把编译成功视为兼容完成 |
| 运行复核 | 关键业务路径、渠道、测试边界 | 已执行路径、异常分类、回归结果 | 不以首页启动外推所有 SDK 与功能 |
| 发布准备 | 最终签名、升级与回滚策略 | 发布候选、未覆盖项与回滚条件 | 不承诺未经验证的机型或系统均通过 |
对于包含 SO、游戏引擎、图像/音视频算法、支付、推送、地图、WebView 或平台专属 SDK 的项目，框架名称只能帮助确定第一检查点，不能替代依赖和关键路径清单。统一 PoC 的价值在于形成可比较的交付对象，而不是用一份泛化结论覆盖所有技术栈。
框架专项与性能兼容性中心如何配合
框架专项页用于解释某一种产物的特殊边界；当项目需要评估启动、内存、包体、SDK/SO 或系统版本差异时，应同时查看 御盾性能与兼容性中心。若目标是确认发布前的防护范围、异常处理与回滚条件，则应使用 App 加固 PoC 验收指南。
这三类页面的职责不同：框架页回答“这个技术栈的产物怎样验收”；兼容性中心回答“怎样建立性能和系统基线”；PoC 指南回答“怎样把范围、结果和例外写进项目验收”。它们互相链接，但不争抢同一个页面意图。
工程落地
建议把跨平台 PoC 放入现有发布流程，而不是在上线前另起一套不可追踪的测试。每次版本候选至少保留：框架与构建工具版本、Android/iOS 产物身份、依赖与架构摘要、目标渠道、已执行关键路径、异常分类、处理结论和回滚对象。高频发布项目可将这一表单与 CI/CD 的构建编号关联；但只有已经实际执行的检查项才能显示为通过。
若项目在同一版本中同时升级框架、支付 SDK、Native 依赖和保护策略，应拆出可比较的候选对象。一次修改过多变量会让“跨平台兼容性”变成无法归因的总称，最终既拖慢发布，也不利于保留必要的安全保护。
攻防视角
跨平台技术栈常把业务入口集中在共享层或桥接层，这会让攻击者更容易寻找可复用的逻辑、资源和运行时边界；但防护不应因为追求强度破坏真实交付链。较稳妥的做法是保护关键逻辑与完整性入口，同时把 Android/iOS 的运行时、签名和平台服务差异显式纳入验证。这样，团队既不会把“框架不同”当成忽略安全的理由，也不会以全量关闭保护来换取一个不可解释的临时通过。
风险边界
本中心不提供绕过、重签、注入或提取第三方应用内容的方法；也不承诺某个框架、插件、设备或渠道已普遍兼容。框架官方资料描述的是其产品能力与构建约束，不是御盾对客户发布包的测试报告。任何对外兼容声明都应附带实际版本、候选对象、已执行路径和未覆盖范围。
常见误区
同一份代码就只需要一次验证
共享业务代码不代表 Android 与 iOS 最终产物相同。KMP 的共享模块会分别进入 Android JVM/DEX 交付与 iOS Native 交付；Flutter、React Native 与 Unity 也各有自己的运行时和 Native 边界。任何一端通过都不能自动证明另一端通过。
框架没有报错就代表发布包没有问题
开发模式、模拟器、Debug、Release、渠道包和最终签名包可能有不同的依赖、资源、架构或签名条件。发布门禁应以最终交付对象和目标渠道为准。
遇到异常先关闭所有保护
全量关闭会失去归因能力，也可能让临时方案进入正式发布。更稳妥的顺序是固定候选身份，比较原始包与基础保护包，缩小到一个构建或策略变量，再完成回归和回滚验证。
常见问题
跨平台项目能否使用同一份加固报告？
可以共用候选身份、关键路径、回滚和发布责任字段，但 Android 与 iOS 的二进制、签名和分发结论必须分别记录；不同框架的运行时和依赖也需要专项条目。
只交付 Android 包能否先开始评估？
可以先完成 Android 范围内的兼容性评估，但报告应明确 iOS 或其他目标未覆盖，不能将单端结果写成双端兼容结论。
是否需要提交生产签名私钥？
不需要。项目方可以在受控发布环节完成最终签名；PoC 更关注候选包、版本、构建范围、关键路径和发布身份的可核对关系。
下一步应该提交哪些材料？
提交当前框架、Release 候选包、目标 Android/iOS 版本、现有 Native 或 SDK 依赖摘要、计划保护范围和一条最关键的业务路径，即可开始界定 PoC 范围。
公开依据
- Kotlin Multiplatform supported platforms
- Kotlin Multiplatform compatibility guide
- Flutter Android deployment
- React Native Hermes
- Unity IL2CPP introduction
- Apple XCFramework source verification
准备跨平台 App 加固评估时，可先查看 御盾 App 加固产品页，再按项目的实际框架和发布对象申请封闭兼容性验证。