1. 事件回顾从全面拥抱到果断转身这波操作到底是什么逻辑“倒反天罡”这个词放在Shopify这个决定上确实很应景。2019年前后Shopify大张旗鼓宣布把移动端重心押到React Native上当时社区一片叫好觉得跨平台方案的又一个重量级标杆落地了JS生态的开发者大批量涌向移动端整个行业都在讨论“Write once, run anywhere”是不是真的要来了。结果六年过去Shopify的官方博客直接宣布移动端逐步弃用React Native回归SwiftUI和Kotlin原生开发。消息一出移动开发圈直接炸了锅。我最早看到这条消息时第一反应也是有点懵。毕竟Shopify不是那种小体量的试验型项目它是全球电商SaaS领域绕不开的平台支撑着几百万商家的线上生意App承载的是实打实的GMV和用户核心交易链路。这种体量的公司做技术栈迁移牵一发而动全身绝对不是为了追新潮或者拍脑袋。等到我把整个事件的来龙去脉、技术动因、社区反响梳理一遍之后反而觉得这个决定挺符合技术演进的规律只是大多数人平时不太愿意承认跨平台方案在特定阶段、特定规模下确实很香但天花板也实实在在摆在那里。这篇文章我想从一个多年在移动端摸爬滚打的从业者视角把Shopify这个决策背后的技术逻辑拆开揉碎聊一聊React Native到底哪里香、哪里疼原生开发为什么在2025年重新成为大厂的主流选择以及我们普通开发者和技术管理者能从这个案例里抄到什么作业。不管你是写React Native的、写原生iOS/Android的还是正在纠结技术选型的团队负责人这篇文章都应该能给你一些参考。1.1 押注React Native那几年行业到底在兴奋什么想要理解Shopify为什么走回头路得先搞清楚当年它为什么敢押注React Native。时间回到2019年那是React Native口碑非常微妙的时期——Airbnb在2018年宣布弃用React Native回归原生理由是“长期维护成本不可控”当时给社区泼了一大盆冷水。但与此同时Meta内部依然在重度使用React Native微软也在一些产品里尝试接入加上JS/React庞大的开发者基数行业对“用JavaScript写移动App”这件事仍然抱有不小的期待。Shopify的切入点很有意思它不只是想复用代码更想复用整个React生态的工程体系。电商业务最大的特点是什么页面结构高度组件化商品卡片、按钮、列表、弹窗、支付流程、购物车、营销组件……这些东西天然适合用组件树来描述。而React的核心心智模型恰恰就是组件化加声明式UI前端工程师上手几乎没有学习成本。对Shopify来说用一个技术栈把Web端和移动端的工程体系打通意味着前端团队可以更灵活地在两个平台之间调配人力招聘半径也一下子从“iOS/Android双端”扩大到了整个前端市场。说实话这个逻辑在早期是完全成立的。React Native当时的发展势头也确实猛社区涌现了一大批高质量组件库导航方案、状态管理方案、UI库都在快速成熟再加上CodePush这类热更新方案的加持让React Native不仅仅是“能用”甚至在某些场景下表现得还挺顺手。Shopify甚至还开源了不少自研的React Native组件和工具库帮社区解决了不少问题。但问题恰恰就出在“某些场景下”这几个字上。电商App的核心交易链路从来都不是什么简单场景它对性能的敏感程度远比内部工具型App高得多。而跨平台方案在复杂场景下的性能损耗、系统能力覆盖不足、原生底层升级带来的维护成本这些隐患不会在项目初期暴露而是会在用户量增长、功能复杂度上升之后集中爆发。Shopify当时看到的是跨平台带来的效率红利但六年后它面对的是一套越来越难伺候的混合架构。1.2 回归原生不是拍脑袋更像是做了一次全身体检后的结论如果你去看Shopify官方发布的关于这次技术调整的博客会发现他们的措辞其实相当克制没有把React Native说成一无是处而是很实在地列了几个维度的问题核心页面性能达不到预期、团队维护成本过高、双端用户体验的深度定制受限。这些话表面上看是“技术原因”实际上每一条背后都对应着非常具体的痛感。性能问题不用多说做过React Native大型项目的人都懂JS线程和原生UI线程之间的通信是有实打实开销的。页面一复杂列表滚动掉帧、启动白屏、首屏渲染慢这些问题是没法靠优化“压榨”干净的因为瓶颈在架构层面。Shopify这种体量的App详情页、首页Feed、购物车、结算流程全部是高频核心路径任何一点点卡顿都会被直接折算成用户流失和GMV损失。维护成本这块React Native早期版本最让人头疼的是它有一套自绘渲染层和桥接层原生底层一升级桥接层就可能出问题。更要命的是React Native社区库的质量参差不齐很多库长期不维护一旦遇到系统API变更就只能自己动手维护或者推倒重写。Shopify这种体量的公司移动端要对接的底层能力非常多——推送、蓝牙、Apple Pay、ARQuickLook、Widget、NFC、相机、相册权限、深层链接、一系列支付组件每个能力都可能有系统版本兼容问题这些在原生环境下是日常操作但在React Native环境下就变成了桥接层能不能及时跟上、第三方库有没有人管的问题。换句话说Shopify做这个决定不是React Native“不够好”而是对Shopify的业务规模来说“够用”和“好用”之间的差距已经被放大到无法忽视的程度。再加上2024年之后SwiftUI和Jetpack Compose这两套原生声明式UI框架已经非常成熟写原生的效率和几年前完全不是一个量级。过去跨平台最大的卖点是“省力”现在原生开发自己也变省力了那跨平台方案的优势就更加被稀释了。2. 压垮React Native的几座大山性能、维护与动态化困境很多人一听到“大厂抛弃RN”就情绪化地站队要么说RN是垃圾要么说原生是守旧。理性来看技术选型没有绝对的对错只有适不适合。但既然Shopify用六年时间真金白银地验证了一遍那这些被验证出来的问题就值得被认真对待。我把自己这些年做跨平台项目的体感结合起来把压垮RN的几座大山讲清楚。2.1 性能瓶颈不是玄学是可量化、可感知的差距React Native的架构演进其实一直在解决性能问题。早期版本JavaScript运行在JSCore上通过Bridge与原生通信每次JS调用原生方法或者原生回调JS都要经过序列化和异步队列。页面结构一旦复杂频繁的Bridge通信就会导致UI线程阻塞具体表现就是滚动卡顿、动画掉帧、点击响应不跟手。后来的新架构引入了TurboModule和Fabric试图用JSI直接持有C对象引用绕开Bridge序列化确实把性能上限拉高了不少。但新架构大量落地是近两年的事而且它解决的是“通信开销”并没有根本解决“JS引擎本身执行效率与原生代码的差异”这个问题。说白了JavaScript的运行时性能和Swift、Kotlin这种编译型语言相比在CPU密集场景下的差距是客观存在的比如大量数据的排序、复杂动画的插值计算、表格组件的单元复计算、首页Feed流的异步预取。这些操作在原生里是几毫秒完成在JS里可能就是几十毫秒用户在快速滑动时对帧率的感知是非常敏锐的。另一个典型场景是冷启动React Native要先初始化JS引擎、加载JS bundle、执行JavaScript入口逻辑才会开始渲染UI。这个过程在低端Android设备上可能直接导致白屏一两秒甚至更久。这也是“react native 启动白屏”这个搜索热词为什么常年挂在网上的原因——它确实是RN绕不开的痛点。2.2 热更新与动态化看起来很美落地全是坑CodePush这种热更新能力是很多团队选择React Native的核心原因。通过远程下发JS bundle可以绕过应用商店审核直接更新业务逻辑这种灵活性在To B、企业内部工具类App里确实非常有价值。但对面向C端用户的大型商业App来说热更新是一把双刃剑。第一它对代码质量的约束力会被大幅削弱。原生代码上架之前要经过严格的评审和测试流程但热更新让业务代码可以绕开这些流程静默上线一旦出问题影响范围是不可控的。第二热更新会造成客户端版本碎片化。线上用户各自固化了不同版本的JS bundle后端接口兼容变成了噩梦。你可能要同时面对十几个版本的客户端逻辑排查线上问题时分分钟想摔键盘。第三也是最现实的——App Store对热更新的态度一直很暧昧动态下发代码在审核政策上存在被拒绝的风险。对Shopify这种全球化商业公司来说把核心交易逻辑押在一个有审核政策风险的更新通道上本身就是一件高风险的事。我也见过很多团队因为热更新而选择RN最后又因为热更新带来的版本管理问题而焦头烂额。技术方案带来的额外自由度如果配套的管理体系跟不上自由度就会变成失控度。2.3 工程师心态与组织协作隐性成本最容易被低估这块是很多人不会直接讲的。技术选型不光是技术问题更是组织问题。React Native让前端工程师可以写移动端听起来是人效提升但实际操作中你会发现一个业务页面可能既要兼顾JS侧的渲染逻辑又要涉及原生侧的能力封装出了问题到底该找谁JS工程师对Xcode和Android Studio的工程配置一窍不通原生工程师又不想整天处理桥接层的问题最后的局面往往是两个团队互相扯皮。还有一个更微妙的点很多技术能力强的移动端工程师内心对跨平台方案是有抵触的。因为长期写RN意味着离系统底层越来越远职业成长空间受限。真正厉害的人更愿意深入SwiftUI、深入研究UIKit、研究系统级性能优化而不是一辈子在JS和原生的边界上做胶水。所以你会发现押注RN的团队短期人好招但长期想留住核心移动端人才很难。Shopify这种体量的公司移动端团队动不动几十上百人组织协作成本和人才保留问题会被放大到非常刺眼。3. 从“能用”到“好用”原生开发为什么在2025年重新成为主流答案聊完RN的痛再看原生这边。过去很多人选React Native有个重要理由是“原生开发太慢了双端各写一套不现实”。这个论点在SwiftUI和Jetpack Compose出现之前确实成立。但这几年的情况已经悄悄变了原生开发的生产力提升幅度可能比很多人想象中要大得多。3.1 SwiftUI与Jetpack Compose让原生开发也进入了声明式时代SwiftUI从2019年发布到现在已经迭代了差不多六个大版本如今的成熟度和早期的1.0版本完全不可同日而语。Layout系统、数据流、动画、SwiftData数据持久化、Widget扩展支持、沉浸式空间计算支持整个生态已经非常完整。Jetpack Compose同样在快速进化Compose Multiplatform也在探索跨平台的可能性。声明式UI让界面构建方式发生了根本性变化写界面就是写状态和布局描述开发效率和可维护性都上了一个台阶。这意味着什么意味着过去RN最大的卖点——声明式UI的开发体验原生这边自己也有了而且更彻底、更贴近系统底层。你写SwiftUI的时候可以直接调用任意系统API可以拿到Swift语言的全部性能优势可以和系统能力做到零摩擦集成。写Jetpack Compose时协程、Flow、Kotlin的语言特性让你在处理异步和并发时非常顺手。工具链上呢Xcode的Preview和Android Studio的Compose Preview都能做到“改代码立刻看效果”开发体验完全不输热重载。所以现在再去计算“双端各写一套”的成本已经不是过去那个算法了。原生开发不再是“事倍功半”的代名词在一些特定场景下因为不需要处理跨平台抽象层开发效率反而可能更高。尤其是复杂交互、深色模式适配、动态字体、无障碍支持这类需要精细打磨的系统级体验原生写起来反而更省心。3.2 核心交易链路与设备能力的深度集成原生优势无可替代电商类App的战场从来都在细节里。闪购秒杀时商品卡片要立刻响应点击直播购物时弹幕和购物车要无缝流转支付流程要保证绝对稳定推送通知点击后希望能瞬间跳到对应页面。这些体验细节每一条背后都连接着系统级能力后台任务调度、内存管理、网络协议栈、系统动画引擎、安全模块。原生代码和系统之间不需要任何中间层所以可以做到对每个环节的完全掌控。还有端侧AI能力的落地。Apple这边的Core ML、Vision框架、Natural Language框架Android这边的ML Kit、MediaPipe这些能力对原生开发非常友好。想象一下一个电商App想在商品详情页做“拍照搜同款”可以直接调用系统相机把图片抠出来做特征匹配然后在原生层快速渲染结果。如果是React Native你需要写大量原生桥接每一步都依赖桥接层的稳定性和性能。而系统AI框架的很多能力是深度集成在系统架构里的比如Apple的设备端大模型能力走原生路径显然最容易拿到最佳效果。还有一个点是App体积和启动速度。React Native应用为了跑JS引擎需要把JSCore或Hermes引擎、JS bundle、各类C依赖都打入包内体积超标是很常见的。而App体积和启动速度对电商类应用的新用户转化率、留存率都有直接影响。Shopify这种体量哪怕启动速度优化0.1秒都可能是千万美元级别的生意。3.3 Shopify的迁移路径对中小团队有哪些可借鉴的地方Shopify这次不是一瞬间完成切换而是采取了渐进式策略新功能模块直接用SwiftUI和Kotlin写存量RN页面逐步替换核心交易页面优先迁移。这种“新模块原生、老模块渐进替换”的路线对做技术栈迁移的团队来说是相当稳妥的参考模板。最关键的一点是他们在架构层面对业务逻辑和UI做了更好的隔离。迁移过程中底层业务逻辑服务可以通过接口暴露给UI层调用原生UI替换成SwiftUI时不需要碰逻辑层。这种面向接口的架构设计比“换技术栈时推倒重来”要理智得多。对中小团队来说哪怕现在没有迁移的打算也值得在写新功能时注意UI和逻辑的分离好处是未来无论你是想换RN、换Flutter、换原生都有退路可走。4. 跨平台技术选型复盘六个维度帮你判断该上React Native还是找原生聊完Shopify这个案例很多人最关心的其实是那我们自己的项目呢现在做技术选型到底该不该用React Native我结合自己这些年见过的大大小小的项目总结了一套相对实用的判断框架。技术选型没有标准答案但有标准的思考路径。4.1 核心判断框架团队、场景、阶段一个都不能少先说团队基因。团队主要技术栈是不是JavaScript/TypeScript有没有能够熟练驾驭原生桥接的工程师如果团队主要是由前端转过来的那React Native的上手门槛确实低得多。反过来如果团队本身就是iOS/Android双端建制齐全那引入RN的价值就比较有限了反而增加了“第三种技术栈”的沟通成本。再说场景。这个App是面向C端用户的高频使用产品还是面向内部员工或特定客户群的工具型产品C端产品的核心页面几乎都需要极致的性能和深度定制体验这些场景优先考虑原生。但如果是内部管理系统、简单业务表单、数据看板这类工具型应用性能和系统深度集成的需求不高React Native甚至Flutter反而很合适因为这类场景真正看重的是快速交付、动态更新和人力成本控制。这正好对应了那句“react native教程”为什么在搜索上一直有热度——大量中小团队、外包团队、To B团队在使用它解决实际问题。还有发展阶段。创业公司早期验证商业模式比优化性能重要得多用RN快速上线双端MVP是完全合理的。但当你进入增长期用户量暴增、核心功能复杂度提升、性能瓶颈逐渐暴露的时候就要果断考虑核心模块的原生化改造。这和Shopify的路径本质上是一样的。表格式对比会更直观判断维度偏向React Native偏向原生开发团队技术栈以JavaScript为主iOS/Android双端团队建制齐全产品类型内部工具、管理后台、基础业务C端用户高依赖、体验驱动型上线速度追求双端快速上线追求长期可维护性系统能力依赖低不涉及复杂系统API高需要深度集成系统能力性能敏感度中低可接受轻微卡顿高核心链路毫秒必争团队规模小团队、工程师稀缺平台级业务有足够人力投入4.2 React Native还好用吗谈谈社区现状与真实评价有一说一React Native依然是目前跨平台方案里生态最成熟的一个没有之一。它的社区体量、第三方库丰富度、招聘市场认可度、学习资料量都是其他跨平台方案短期无法超越的。如果你做一个新项目不考虑原生React Native绝对是当前值得优先考虑的候选方案之一。Meta也一直在持续投入新架构今年发布的新版本在性能上已经有了明显提升特别是Hermes引擎的默认启用、Fabric架构的全面落地让老版本那些恼人的启动白屏问题改善了很多。但我也要说句实话React Native的定位正在变得更清晰也更保守。它不再试图“取代原生”而是退回到一个更务实的位置——作为原生生态的补充服务于那些快节奏迭代、性能要求不是极致的业务模块。换句话说它成了“效率和性能之间的一种折中”而不是“两端通吃的银弹”。如果你接受这个定位用RN会舒服很多如果你指望RN解决所有性能问题那大概率会失望。4.3 给技术管理者的几条实在建议技术选型这东西最怕的不是选错技术而是把技术选择变成个人信仰。我见过很多团队因为CTO个人特别钟爱某种技术就整个公司押上去结果业务和技术需求都变了还死撑着不换。技术选型应该是一道“项目体检报告”而不是一道“证明我眼光好”的判断题。第一永远为核心业务模块保留原生的可能性。新架构里把UI和业务逻辑分离核心业务模块优先用原生能力承载而不是让跨平台框架接管一切。第二不要追求“百分百代码复用”。代码复用率再高如果核心体验一塌糊涂产品依然会死。第三一定要提前规划技术栈演进路径React Native可以写但要留好“桥”和“接缝”这样未来才能进退自如。第四招“既懂原生又懂跨平台”的人比招“只会纯前端或只会纯原生”的人长期来看有价值得多。5. 写在最后技术没有永恒决策永远是对当下约束条件的最优解我个人这些年写过原生、写过React Native也用过Flutter最大的感受就是技术选型永远不存在一劳永逸的正确答案。React Native成全了很多团队也让很多团队在性能的边角里疲于奔命。它本身不是问题问题在于很多人往往把一个“阶段性的最优解”当成了“永恒不变的信仰”。Shopify这次转身从舆论上看是“倒反天罡”但从技术演进的规律来看其实是挺自然的一件事。跨平台方案在特定的阶段解决特定规模的问题随着产品变大、用户变多、性能敏感度变高原生回归就成了水到渠成的选择。未来哪天有什么新的跨平台框架横空出世再出现一次“从原生迁到跨平台”的潮流我也不会觉得惊讶。行业永远在摇摆中前进而聪明的人只在合适的时机做合适的选择。如果你正在犹豫要不要从React Native切回原生先别急着看新闻就做决定好好盘一下自己的产品阶段、团队结构和性能瓶颈把“人云亦云”这四个字从选项里删掉。技术是工具业务才是目的。能把这个关系理顺你就已经比绝大多数从业者想得清楚了。 Shopify弃用React Native回归原生：跨平台方案的天花板在哪里
1. 事件回顾从全面拥抱到果断转身这波操作到底是什么逻辑“倒反天罡”这个词放在Shopify这个决定上确实很应景。2019年前后Shopify大张旗鼓宣布把移动端重心押到React Native上当时社区一片叫好觉得跨平台方案的又一个重量级标杆落地了JS生态的开发者大批量涌向移动端整个行业都在讨论“Write once, run anywhere”是不是真的要来了。结果六年过去Shopify的官方博客直接宣布移动端逐步弃用React Native回归SwiftUI和Kotlin原生开发。消息一出移动开发圈直接炸了锅。我最早看到这条消息时第一反应也是有点懵。毕竟Shopify不是那种小体量的试验型项目它是全球电商SaaS领域绕不开的平台支撑着几百万商家的线上生意App承载的是实打实的GMV和用户核心交易链路。这种体量的公司做技术栈迁移牵一发而动全身绝对不是为了追新潮或者拍脑袋。等到我把整个事件的来龙去脉、技术动因、社区反响梳理一遍之后反而觉得这个决定挺符合技术演进的规律只是大多数人平时不太愿意承认跨平台方案在特定阶段、特定规模下确实很香但天花板也实实在在摆在那里。这篇文章我想从一个多年在移动端摸爬滚打的从业者视角把Shopify这个决策背后的技术逻辑拆开揉碎聊一聊React Native到底哪里香、哪里疼原生开发为什么在2025年重新成为大厂的主流选择以及我们普通开发者和技术管理者能从这个案例里抄到什么作业。不管你是写React Native的、写原生iOS/Android的还是正在纠结技术选型的团队负责人这篇文章都应该能给你一些参考。1.1 押注React Native那几年行业到底在兴奋什么想要理解Shopify为什么走回头路得先搞清楚当年它为什么敢押注React Native。时间回到2019年那是React Native口碑非常微妙的时期——Airbnb在2018年宣布弃用React Native回归原生理由是“长期维护成本不可控”当时给社区泼了一大盆冷水。但与此同时Meta内部依然在重度使用React Native微软也在一些产品里尝试接入加上JS/React庞大的开发者基数行业对“用JavaScript写移动App”这件事仍然抱有不小的期待。Shopify的切入点很有意思它不只是想复用代码更想复用整个React生态的工程体系。电商业务最大的特点是什么页面结构高度组件化商品卡片、按钮、列表、弹窗、支付流程、购物车、营销组件……这些东西天然适合用组件树来描述。而React的核心心智模型恰恰就是组件化加声明式UI前端工程师上手几乎没有学习成本。对Shopify来说用一个技术栈把Web端和移动端的工程体系打通意味着前端团队可以更灵活地在两个平台之间调配人力招聘半径也一下子从“iOS/Android双端”扩大到了整个前端市场。说实话这个逻辑在早期是完全成立的。React Native当时的发展势头也确实猛社区涌现了一大批高质量组件库导航方案、状态管理方案、UI库都在快速成熟再加上CodePush这类热更新方案的加持让React Native不仅仅是“能用”甚至在某些场景下表现得还挺顺手。Shopify甚至还开源了不少自研的React Native组件和工具库帮社区解决了不少问题。但问题恰恰就出在“某些场景下”这几个字上。电商App的核心交易链路从来都不是什么简单场景它对性能的敏感程度远比内部工具型App高得多。而跨平台方案在复杂场景下的性能损耗、系统能力覆盖不足、原生底层升级带来的维护成本这些隐患不会在项目初期暴露而是会在用户量增长、功能复杂度上升之后集中爆发。Shopify当时看到的是跨平台带来的效率红利但六年后它面对的是一套越来越难伺候的混合架构。1.2 回归原生不是拍脑袋更像是做了一次全身体检后的结论如果你去看Shopify官方发布的关于这次技术调整的博客会发现他们的措辞其实相当克制没有把React Native说成一无是处而是很实在地列了几个维度的问题核心页面性能达不到预期、团队维护成本过高、双端用户体验的深度定制受限。这些话表面上看是“技术原因”实际上每一条背后都对应着非常具体的痛感。性能问题不用多说做过React Native大型项目的人都懂JS线程和原生UI线程之间的通信是有实打实开销的。页面一复杂列表滚动掉帧、启动白屏、首屏渲染慢这些问题是没法靠优化“压榨”干净的因为瓶颈在架构层面。Shopify这种体量的App详情页、首页Feed、购物车、结算流程全部是高频核心路径任何一点点卡顿都会被直接折算成用户流失和GMV损失。维护成本这块React Native早期版本最让人头疼的是它有一套自绘渲染层和桥接层原生底层一升级桥接层就可能出问题。更要命的是React Native社区库的质量参差不齐很多库长期不维护一旦遇到系统API变更就只能自己动手维护或者推倒重写。Shopify这种体量的公司移动端要对接的底层能力非常多——推送、蓝牙、Apple Pay、ARQuickLook、Widget、NFC、相机、相册权限、深层链接、一系列支付组件每个能力都可能有系统版本兼容问题这些在原生环境下是日常操作但在React Native环境下就变成了桥接层能不能及时跟上、第三方库有没有人管的问题。换句话说Shopify做这个决定不是React Native“不够好”而是对Shopify的业务规模来说“够用”和“好用”之间的差距已经被放大到无法忽视的程度。再加上2024年之后SwiftUI和Jetpack Compose这两套原生声明式UI框架已经非常成熟写原生的效率和几年前完全不是一个量级。过去跨平台最大的卖点是“省力”现在原生开发自己也变省力了那跨平台方案的优势就更加被稀释了。2. 压垮React Native的几座大山性能、维护与动态化困境很多人一听到“大厂抛弃RN”就情绪化地站队要么说RN是垃圾要么说原生是守旧。理性来看技术选型没有绝对的对错只有适不适合。但既然Shopify用六年时间真金白银地验证了一遍那这些被验证出来的问题就值得被认真对待。我把自己这些年做跨平台项目的体感结合起来把压垮RN的几座大山讲清楚。2.1 性能瓶颈不是玄学是可量化、可感知的差距React Native的架构演进其实一直在解决性能问题。早期版本JavaScript运行在JSCore上通过Bridge与原生通信每次JS调用原生方法或者原生回调JS都要经过序列化和异步队列。页面结构一旦复杂频繁的Bridge通信就会导致UI线程阻塞具体表现就是滚动卡顿、动画掉帧、点击响应不跟手。后来的新架构引入了TurboModule和Fabric试图用JSI直接持有C对象引用绕开Bridge序列化确实把性能上限拉高了不少。但新架构大量落地是近两年的事而且它解决的是“通信开销”并没有根本解决“JS引擎本身执行效率与原生代码的差异”这个问题。说白了JavaScript的运行时性能和Swift、Kotlin这种编译型语言相比在CPU密集场景下的差距是客观存在的比如大量数据的排序、复杂动画的插值计算、表格组件的单元复计算、首页Feed流的异步预取。这些操作在原生里是几毫秒完成在JS里可能就是几十毫秒用户在快速滑动时对帧率的感知是非常敏锐的。另一个典型场景是冷启动React Native要先初始化JS引擎、加载JS bundle、执行JavaScript入口逻辑才会开始渲染UI。这个过程在低端Android设备上可能直接导致白屏一两秒甚至更久。这也是“react native 启动白屏”这个搜索热词为什么常年挂在网上的原因——它确实是RN绕不开的痛点。2.2 热更新与动态化看起来很美落地全是坑CodePush这种热更新能力是很多团队选择React Native的核心原因。通过远程下发JS bundle可以绕过应用商店审核直接更新业务逻辑这种灵活性在To B、企业内部工具类App里确实非常有价值。但对面向C端用户的大型商业App来说热更新是一把双刃剑。第一它对代码质量的约束力会被大幅削弱。原生代码上架之前要经过严格的评审和测试流程但热更新让业务代码可以绕开这些流程静默上线一旦出问题影响范围是不可控的。第二热更新会造成客户端版本碎片化。线上用户各自固化了不同版本的JS bundle后端接口兼容变成了噩梦。你可能要同时面对十几个版本的客户端逻辑排查线上问题时分分钟想摔键盘。第三也是最现实的——App Store对热更新的态度一直很暧昧动态下发代码在审核政策上存在被拒绝的风险。对Shopify这种全球化商业公司来说把核心交易逻辑押在一个有审核政策风险的更新通道上本身就是一件高风险的事。我也见过很多团队因为热更新而选择RN最后又因为热更新带来的版本管理问题而焦头烂额。技术方案带来的额外自由度如果配套的管理体系跟不上自由度就会变成失控度。2.3 工程师心态与组织协作隐性成本最容易被低估这块是很多人不会直接讲的。技术选型不光是技术问题更是组织问题。React Native让前端工程师可以写移动端听起来是人效提升但实际操作中你会发现一个业务页面可能既要兼顾JS侧的渲染逻辑又要涉及原生侧的能力封装出了问题到底该找谁JS工程师对Xcode和Android Studio的工程配置一窍不通原生工程师又不想整天处理桥接层的问题最后的局面往往是两个团队互相扯皮。还有一个更微妙的点很多技术能力强的移动端工程师内心对跨平台方案是有抵触的。因为长期写RN意味着离系统底层越来越远职业成长空间受限。真正厉害的人更愿意深入SwiftUI、深入研究UIKit、研究系统级性能优化而不是一辈子在JS和原生的边界上做胶水。所以你会发现押注RN的团队短期人好招但长期想留住核心移动端人才很难。Shopify这种体量的公司移动端团队动不动几十上百人组织协作成本和人才保留问题会被放大到非常刺眼。3. 从“能用”到“好用”原生开发为什么在2025年重新成为主流答案聊完RN的痛再看原生这边。过去很多人选React Native有个重要理由是“原生开发太慢了双端各写一套不现实”。这个论点在SwiftUI和Jetpack Compose出现之前确实成立。但这几年的情况已经悄悄变了原生开发的生产力提升幅度可能比很多人想象中要大得多。3.1 SwiftUI与Jetpack Compose让原生开发也进入了声明式时代SwiftUI从2019年发布到现在已经迭代了差不多六个大版本如今的成熟度和早期的1.0版本完全不可同日而语。Layout系统、数据流、动画、SwiftData数据持久化、Widget扩展支持、沉浸式空间计算支持整个生态已经非常完整。Jetpack Compose同样在快速进化Compose Multiplatform也在探索跨平台的可能性。声明式UI让界面构建方式发生了根本性变化写界面就是写状态和布局描述开发效率和可维护性都上了一个台阶。这意味着什么意味着过去RN最大的卖点——声明式UI的开发体验原生这边自己也有了而且更彻底、更贴近系统底层。你写SwiftUI的时候可以直接调用任意系统API可以拿到Swift语言的全部性能优势可以和系统能力做到零摩擦集成。写Jetpack Compose时协程、Flow、Kotlin的语言特性让你在处理异步和并发时非常顺手。工具链上呢Xcode的Preview和Android Studio的Compose Preview都能做到“改代码立刻看效果”开发体验完全不输热重载。所以现在再去计算“双端各写一套”的成本已经不是过去那个算法了。原生开发不再是“事倍功半”的代名词在一些特定场景下因为不需要处理跨平台抽象层开发效率反而可能更高。尤其是复杂交互、深色模式适配、动态字体、无障碍支持这类需要精细打磨的系统级体验原生写起来反而更省心。3.2 核心交易链路与设备能力的深度集成原生优势无可替代电商类App的战场从来都在细节里。闪购秒杀时商品卡片要立刻响应点击直播购物时弹幕和购物车要无缝流转支付流程要保证绝对稳定推送通知点击后希望能瞬间跳到对应页面。这些体验细节每一条背后都连接着系统级能力后台任务调度、内存管理、网络协议栈、系统动画引擎、安全模块。原生代码和系统之间不需要任何中间层所以可以做到对每个环节的完全掌控。还有端侧AI能力的落地。Apple这边的Core ML、Vision框架、Natural Language框架Android这边的ML Kit、MediaPipe这些能力对原生开发非常友好。想象一下一个电商App想在商品详情页做“拍照搜同款”可以直接调用系统相机把图片抠出来做特征匹配然后在原生层快速渲染结果。如果是React Native你需要写大量原生桥接每一步都依赖桥接层的稳定性和性能。而系统AI框架的很多能力是深度集成在系统架构里的比如Apple的设备端大模型能力走原生路径显然最容易拿到最佳效果。还有一个点是App体积和启动速度。React Native应用为了跑JS引擎需要把JSCore或Hermes引擎、JS bundle、各类C依赖都打入包内体积超标是很常见的。而App体积和启动速度对电商类应用的新用户转化率、留存率都有直接影响。Shopify这种体量哪怕启动速度优化0.1秒都可能是千万美元级别的生意。3.3 Shopify的迁移路径对中小团队有哪些可借鉴的地方Shopify这次不是一瞬间完成切换而是采取了渐进式策略新功能模块直接用SwiftUI和Kotlin写存量RN页面逐步替换核心交易页面优先迁移。这种“新模块原生、老模块渐进替换”的路线对做技术栈迁移的团队来说是相当稳妥的参考模板。最关键的一点是他们在架构层面对业务逻辑和UI做了更好的隔离。迁移过程中底层业务逻辑服务可以通过接口暴露给UI层调用原生UI替换成SwiftUI时不需要碰逻辑层。这种面向接口的架构设计比“换技术栈时推倒重来”要理智得多。对中小团队来说哪怕现在没有迁移的打算也值得在写新功能时注意UI和逻辑的分离好处是未来无论你是想换RN、换Flutter、换原生都有退路可走。4. 跨平台技术选型复盘六个维度帮你判断该上React Native还是找原生聊完Shopify这个案例很多人最关心的其实是那我们自己的项目呢现在做技术选型到底该不该用React Native我结合自己这些年见过的大大小小的项目总结了一套相对实用的判断框架。技术选型没有标准答案但有标准的思考路径。4.1 核心判断框架团队、场景、阶段一个都不能少先说团队基因。团队主要技术栈是不是JavaScript/TypeScript有没有能够熟练驾驭原生桥接的工程师如果团队主要是由前端转过来的那React Native的上手门槛确实低得多。反过来如果团队本身就是iOS/Android双端建制齐全那引入RN的价值就比较有限了反而增加了“第三种技术栈”的沟通成本。再说场景。这个App是面向C端用户的高频使用产品还是面向内部员工或特定客户群的工具型产品C端产品的核心页面几乎都需要极致的性能和深度定制体验这些场景优先考虑原生。但如果是内部管理系统、简单业务表单、数据看板这类工具型应用性能和系统深度集成的需求不高React Native甚至Flutter反而很合适因为这类场景真正看重的是快速交付、动态更新和人力成本控制。这正好对应了那句“react native教程”为什么在搜索上一直有热度——大量中小团队、外包团队、To B团队在使用它解决实际问题。还有发展阶段。创业公司早期验证商业模式比优化性能重要得多用RN快速上线双端MVP是完全合理的。但当你进入增长期用户量暴增、核心功能复杂度提升、性能瓶颈逐渐暴露的时候就要果断考虑核心模块的原生化改造。这和Shopify的路径本质上是一样的。表格式对比会更直观判断维度偏向React Native偏向原生开发团队技术栈以JavaScript为主iOS/Android双端团队建制齐全产品类型内部工具、管理后台、基础业务C端用户高依赖、体验驱动型上线速度追求双端快速上线追求长期可维护性系统能力依赖低不涉及复杂系统API高需要深度集成系统能力性能敏感度中低可接受轻微卡顿高核心链路毫秒必争团队规模小团队、工程师稀缺平台级业务有足够人力投入4.2 React Native还好用吗谈谈社区现状与真实评价有一说一React Native依然是目前跨平台方案里生态最成熟的一个没有之一。它的社区体量、第三方库丰富度、招聘市场认可度、学习资料量都是其他跨平台方案短期无法超越的。如果你做一个新项目不考虑原生React Native绝对是当前值得优先考虑的候选方案之一。Meta也一直在持续投入新架构今年发布的新版本在性能上已经有了明显提升特别是Hermes引擎的默认启用、Fabric架构的全面落地让老版本那些恼人的启动白屏问题改善了很多。但我也要说句实话React Native的定位正在变得更清晰也更保守。它不再试图“取代原生”而是退回到一个更务实的位置——作为原生生态的补充服务于那些快节奏迭代、性能要求不是极致的业务模块。换句话说它成了“效率和性能之间的一种折中”而不是“两端通吃的银弹”。如果你接受这个定位用RN会舒服很多如果你指望RN解决所有性能问题那大概率会失望。4.3 给技术管理者的几条实在建议技术选型这东西最怕的不是选错技术而是把技术选择变成个人信仰。我见过很多团队因为CTO个人特别钟爱某种技术就整个公司押上去结果业务和技术需求都变了还死撑着不换。技术选型应该是一道“项目体检报告”而不是一道“证明我眼光好”的判断题。第一永远为核心业务模块保留原生的可能性。新架构里把UI和业务逻辑分离核心业务模块优先用原生能力承载而不是让跨平台框架接管一切。第二不要追求“百分百代码复用”。代码复用率再高如果核心体验一塌糊涂产品依然会死。第三一定要提前规划技术栈演进路径React Native可以写但要留好“桥”和“接缝”这样未来才能进退自如。第四招“既懂原生又懂跨平台”的人比招“只会纯前端或只会纯原生”的人长期来看有价值得多。5. 写在最后技术没有永恒决策永远是对当下约束条件的最优解我个人这些年写过原生、写过React Native也用过Flutter最大的感受就是技术选型永远不存在一劳永逸的正确答案。React Native成全了很多团队也让很多团队在性能的边角里疲于奔命。它本身不是问题问题在于很多人往往把一个“阶段性的最优解”当成了“永恒不变的信仰”。Shopify这次转身从舆论上看是“倒反天罡”但从技术演进的规律来看其实是挺自然的一件事。跨平台方案在特定的阶段解决特定规模的问题随着产品变大、用户变多、性能敏感度变高原生回归就成了水到渠成的选择。未来哪天有什么新的跨平台框架横空出世再出现一次“从原生迁到跨平台”的潮流我也不会觉得惊讶。行业永远在摇摆中前进而聪明的人只在合适的时机做合适的选择。如果你正在犹豫要不要从React Native切回原生先别急着看新闻就做决定好好盘一下自己的产品阶段、团队结构和性能瓶颈把“人云亦云”这四个字从选项里删掉。技术是工具业务才是目的。能把这个关系理顺你就已经比绝大多数从业者想得清楚了。