“用跨平台做还是原生做？”——这个问题在需求确认之后一定会出现。它没有一个放之四海都对的答案，但有判断顺序。顺序搞反了，容易只盯住开发报价那一栏。
这篇文章把三种主流做法摊开，给出三条按顺序判断的线，再给一张场景对照表。你不需要懂代码，只要能回答关于自己业务的那几个问题。
一、先认清三种做法各自换来什么
| 做法 | 换来什么 | 代价在哪 |
|---|---|---|
| 原生（iOS 与 Android 各做一套） | 系统能力用得最全，动效与相机、定位、蓝牙这类硬件交互最稳；问题定位也直接 | 两套人力、两套排期、两次商店审核；同一改动要写两遍 |
| 跨平台（一套业务代码两端运行） | 开发与迭代省人力，界面统一，小团队也能同时上两个平台 | 深层系统能力和复杂动画仍需写平台代码；包体积、调试链路比原生绕一些 |
| 混合 / 套壳（网页装进外壳） | 最快、最省，网页团队就能交付 | 交互与性能有天花板；对“只是把网页包起来”的应用，商店审核并不友好 |
一句话概括：原生买的是体验与能力，跨平台买的是效率，套壳买的是时间。三种都能上线，区别在于上线之后你还要付多少。
二、三条判断线，顺序不要颠倒
第一条：功能依赖多少系统与硬件
这是硬指标，先量它。把下面这份清单对着自己的功能划一遍，划到 3 项以上，基本就该往原生靠：
- 蓝牙、串口、NFC 等外设对接；
- 后台定位、轨迹记录、地理围栏；
- 相机实时处理（扫码之外的识别、测量、拍照上传前的压缩）；
- 指纹、面容等生物识别；
- 系统级分享、深链跳转、与其他 App 互相唤起；
- 离线缓存、后台同步、桌面小组件；
- 音视频通话与推送到达率要求较高的场景。
如果这些一条都用不上，你的需求其实很简单，接着看第二条。
第二条：谁来维护，维护多久
这一条最容易被跳过，但它决定第二年的成本。三种情况对应三种选法：
- 公司里没有移动端的人，未来靠外包维护。选跨平台。一套代码，交接面小，换团队时对方接手更快；原生双端交接，常常要交接两支队伍。
- 有固定的一两个技术同事，且要长期做下去（三年以上）。原生可以分平台演进，功能越加越深时不会被框架挡住。
- 一次做完、后期改动很少（内部工具、展会演示）。跨平台或混合即可，不必为低频使用付费。
第三条：体验在生意里占多重
- 业务型——下单、报工、审批、巡检、看板、对账。核心是表单、列表、状态流转，跨平台完全够用，把力气花在字段和流程上更值。
- 体验型——影像处理、内容社区、重动效、游戏化激励。用户是拿它当“产品”而不是“工具”，原生更合适。
- 极低频——一年用两回的报名、抽奖、活动页。先别做 APP：网页或小程序更省，这一点在能做小程序的先别做 APP里讲过。
三、场景对照表
| 你的场景 | 倾向 | 提前想清的代价 |
|---|---|---|
| 业务型工具，表单与流程为主 | 跨平台 | 大量输入页的键盘与光标体验、扫码、深链要单独验证 |
| 硬件对接（蓝牙、串口、NFC） | 原生 | 两套人力；测试机型号要备足，尤其安卓碎片化机型 |
| 图像、视频、实时处理 | 原生，或核心模块原生 + 其余跨平台 | 低端机要做性能降级，算法在端上跑不动就要上云 |
| 会员 + 内容 + 电商 | 跨平台为主 | 支付、登录、分享要分别接各平台 SDK；上架合规材料一次备齐 |
| 内部低频工具 | 混合、H5 或小程序 | 别指望它承担系统级职责（后台常驻、硬件调用） |
四、三个常见误区
- “一次开发，到处运行”。共享的是业务代码。适配、两个商店的上架素材与审核、平台各异的推送与支付 SDK，仍然要两边各做一遍。省下的是开发量，不是工作量。
- “套壳便宜”。省下的是开发，赔的是体验与后续。而且对内容单薄、只是把网页包一层外壳的应用，商店审核可能不通过——这一点在立项时就该问清楚。
- “原生一定更好”。只在小团队、预算有限、需求还在变的时候，双端原生常常换来两个都做一半。技术选型看的是匹配，不是先进程度。
五、已经上线了，想换技术栈怎么办
这种情况我们遇到过几次，先分清“必须换”还是“想换”：
- 必须换的信号：关键功能被框架卡住做不出来；崩溃与卡顿集中在特定机型的核心流程；招不到能维护这套代码的人。
- 可以再等等的信号：只是某个页面滑动不顺、某个动画不够细腻——这类问题通常优化就能解决。
真要换，优先走渐进路线：新版本里把一两个核心模块改用原生实现，其余继续原来的方案，接口不变、用户无感。全量重写需要三个前提同时成立：后端接口已经稳定、有明确的功能冻结期、能接受几个月不发新功能。三个缺一个，重写就容易变成“新旧两套并存”。
六、七个问题，问完答案基本就有了
- 最核心的三个功能是什么？
- 它们依赖哪些系统能力或硬件？
- 上线后谁来维护，有几个人？
- 一年计划发几个大版本？
- 目标用户主要在哪个系统、什么价位的机型上？
- 有没有必须对接的外部硬件或第三方 SDK？
- 最坏情况下，能不能接受重写其中一个模块？
这七个问题的答案，就是我们给客户做选型建议时最先问的东西。它们不涉及技术偏好，全都是业务事实。
七、我们通常怎么建议
面向多数中小企业的业务型应用，常见做法是先用跨平台把需求验证出来，跑顺之后再按模块下沉原生。理由是：需求在第一年最容易变，改一套代码比改两套便宜；等到哪一块真的被框架挡住了，再单独拿出来重做，边界清楚、预算也可控。
反过来，如果一开始就知道要对接硬件、要做重度的图像处理，那就别绕这一圈，直接按原生规划，把测试机和人力提前算进预算。
本页要点（Key Takeaways）
- 三种做法买的东西不同：原生买体验与能力，跨平台买效率，套壳买时间
- 判断顺序：先量系统与硬件依赖 → 再看谁来维护、维护多久 → 最后看体验在生意里的权重
- “一次开发，到处运行”只是业务代码共享；适配、审核、各平台 SDK 仍要两边做
- 业务型应用先用跨平台验证需求，被卡住再按模块下沉原生，是成本更可控的路径
- 换技术栈前先分清“必须换”与“想换”；渐进改造的三个前提：接口稳定、功能冻结、能接受停更
- 延伸阅读：APP上线后才是开始：第一年的版本迭代与机型适配、能用小程序解决的，就先别做APP
附：把选型问题带进第一次沟通
如果你正准备立项，可以先把第六节那七个问题写下来，答案不完整的部分就是我们第一次沟通要问的内容。需要评估现成的方案，可以看看我们的APP开发服务，或直接约一次技术沟通——我们会先给判断，再谈报价。
本文由建沅网络APP开发方向的技术团队撰写，观点来自一线项目实践。如需转载请联系我们并注明出处。