选 APP 技术路线时，先找出最容易让项目停下来的能力：指定设备的蓝牙连接、厂商提供的 SDK、离线提交，或者一段必须流畅完成的复杂操作。页面原型能演示业务流程，却不能证明这些能力已经可用。
原生与跨端的选择需要项目证据。下面的核查方法是选型讨论示例，不代表任何客户项目的实测结果，也不承诺固定的成本节省比例。
跨端仍可能需要分别实现
React Native 的平台差异文档说明，可以通过平台判断或不同平台文件组织差异代码。这意味着业务逻辑可以共用，但界面行为和部分能力仍要分平台处理。
Flutter 的平台通道文档介绍了 Dart 与平台专属代码之间的通信方式。遇到没有现成能力的设备接口时，不能只问“框架支不支持”，还要确认谁负责平台实现、调试与后续升级。
因此，既不能把跨端报价当作只有一份代码的维护费用，也不能因为有硬件需求就直接认定必须全原生。先验证关键路径，再确定哪些模块需要分别开发。
把最难的能力做成一个可验证的小样
假设应用要连接门店设备，先要求开发方在约定的手机和设备上完成连接、执行一次操作、断开并重新连接。此处是验证方式示例，不是现有案例。记录手机型号、系统版本、设备固件、依赖版本和失败现象，避免仅凭模拟器画面作出选型结论。
| 要判断的问题 | 可以要求提供的证据 | 仍未解决时怎么处理 |
|---|---|---|
| 关键 SDK 是否支持目标平台 | 两个平台上的真实调用结果与厂商支持范围 | 补平台实现评估，或调整首发范围 |
| 插件是否覆盖实际操作 | 成功、取消、权限拒绝后的完整流程 | 明确缺口由插件修复还是自行实现 |
| 性能是否满足使用场景 | 约定设备、数据量和操作下的测量记录 | 先定位瓶颈，再比较替代实现 |
| 离线后是否会重复提交 | 断网、重连、重复点击后的业务结果 | 联合接口设计补重试与去重方案 |
验收标准应由项目约定。不要拿另一台高配手机、少量演示数据或调试环境的结果，替代目标用户条件下的验证。也不要把某个小样成功扩大为全应用性能已经合格。
预算要把共用部分和平台部分拆开
让方案分别列出业务页面、接口、平台适配和测试工作。若依赖厂商 SDK 或社区插件，还应列明升级时由谁检查兼容性，依赖停止维护后有哪些替代路径。能否持续维护，是路线选择的一部分。
对比两种方案时，尽量使用相同的首发功能、设备范围和验收条件。否则，一份报价包含双端设备测试，另一份只包含页面开发，数字差异不能说明哪条路线更划算。阶段付款的讨论可接着阅读费用与验收节点的安排。
小样之后怎样决定
如果关键路径能通过验证，平台差异也有明确负责人，可以继续评估跨端方案的复用价值。若某个平台只能依赖尚未验证的组件，就把它列为待解决项，并在承诺完整工期前验证；必要时比较局部原生模块、缩小首发范围与全原生方案的代价。
不要先把所有页面完成，再去验证唯一不可替代的设备能力。决定路线需要的是困难部分的证据，而不是演示页面的数量。
两个平台都能构建成功，能否确定路线可行？
还不能。构建证明代码能够产出安装包，关键业务操作、权限拒绝后的处理和设备兼容性需要在约定环境中单独验证。
做跨端项目还需要原生开发人员吗？
取决于平台差异和依赖缺口。现成组件覆盖需求时可能不必自行编写对应模块，但仍应有人能够定位平台问题；需要自定义平台能力时，要把实现与维护责任写入方案。