Shopify(Shopify)2020年决定全面采用React Native(React Native),押注极为成功,一次构建省时且让无移动背景开发者也能贡献。2025年1月我们曾称其前景光明并计划持续投入,当时确为事实且框架出色。但此后编程模型显著进步,用Swift(Swift)与Kotlin(Kotlin)构建同功能的成本已非昔比。2020年决策的核心假设因大语言模型(LLM)改变,我们从第一性原理重估移动技术栈。
正文
2020年我们决定全力投入 React Native,这个赌注极为成功。我们只写一次功能就省了大量时间,让没有移动背景的开发者也能贡献代码,并不再疲于追赶功能对齐。
2025年1月,我曾写道 React Native 前景光明,Shopify 会继续投入。基于当时认知那是对的,React Native 表现良好且仍是优秀框架。但此后编程模型大幅进步,对我们而言用 Swift 和 Kotlin 双端开发同一功能的成本已不同往日。
我们不会因决策曾成功就死守。核心假设变了,就愿意重回审视。LLM 改变了2020年决策的核心假设,因此我们从第一性原理重评移动技术栈。
结论是我们回到原生。
为什么切回原生
2020年我们转用 React Native 出于三因:避免双端重复造功能、让开发者跨栈工作、少追对齐多交付价值。React Native 一直带来这些好处,尽管我们花不少资源优化性能、跟进框架更新,但收益远大于投入。
Shopify 自2021年(早于 ChatGPT 一年)就用 LLM 建软件,起初用于实现功能、查修 bug、审代码。模型进步后,委托复杂度也增。到2025年底,它们不只加速写码,更让我们质疑“写两次是否等于两倍工”。
我们重评技术栈,用 LLM 以 Swift 和 Kotlin 重写了最大应用的核心模块,效果惊艳。Agent 能参考 iOS 版实现 Android 版反之亦然;帮开发者跨栈贡献;通过共享规格、测试、审 checkpoint 大幅降低双端对齐成本。
原生仍意味双平台构建维护,成本未消。但 Agent 现能承担足够多的实现、转译、测试、审查,使该成本不再是2020年时的决定因素。React Native 应用可以快,我们的一样快。我们转向是因为 Agent 削弱了共享实现的优势,而各平台原生构建的优势犹在。原生让我们更贴平台能力与一手工具,代码与平台间框架依赖层更少。
我们的 React Native 开源库的未来
在讲迁移前,我们承诺平稳过渡。起初我们就想回馈 React Native,发布的开源库已成各类首选。感谢社区,我们将确保无缝过渡。
React Native Skia
Shopify 继续赞助至2026年底,William Candillon 之后仍维护。他将在数月内 fork 仓库并以新名发布。原仓库过渡完成后归档。我们会更新通知以便迁移。依赖此库请考虑赞助。
FlashList
该库周下载约200万,已成 React Native 高性能列表默认方案。因其生态重要,Shopify 会继续修兼容性关键问题。正与几家公司谈长期接管,有意联系 Mustafa Ali。
Restyle
Restyle 用户较少,我们将归档仓库,维护至2026年底后停止。欢迎 fork,有团队接手我们协助交接。
我们如何迁移
Shopify 有多个大应用(Shopify、Shop、Point of Sale、Inbox),全球数百万商家买家每日依赖。我们权衡逐步迁移(brownfield)与重写(greenfield)。过去转 React Native 选 brownfield 因重写需数年且停新功能。
此次 greenfield 明显胜出:LLM 善参考 React Native 版用 Swift 和 Kotlin 建功能;可干净重来不受旧约束;原型显示比无 agent 时快得多。
Shop 应用(购物类榜单常客)首发迁移。AI 辅助下,团队12周从概念到上架完整原生版。Shopify 应用(最大,300+屏、小组件、Watch 应用等)迁移中,今年晚些推出。其余将很快迁移。
防止垃圾代码
直接让 LLM 读 React Native 代码一次性生成本地功能行不通,即便先冻规格任务,也会得大量不可维护无法发布的代码。
我们建了 Helix 系统,渐进而行。它不指望首稿对,而是建循环:不完美就不前进,直到变好。开发者指向一屏,Helix 读 React Native 码提一串 checkpoint(小有序切片,分钟可审)。逐 checkpoint 构建:每个须测试证行为、视觉审匹配运行应用、过俩对抗审查员、获人点头才提交并下一轮。每次反馈被记住,循环越自主。
此法极有效,重建耗时不及其几分之一。
实现快速反馈循环
Agent 控模拟器是瓶颈,常需盯守,因不可靠构建测试迭代。我们建过工具让 agent 自复现修 bug 验证,但慢且脆。React Native 热重载有助不决,因模拟器控慢,主要依赖无障碍树或截图取态验证。Agent 秒改码但测输出需分,迭代极慢手。模型再好不能快测也白搭,移动端尤难。
我们 redesign 架构为人 agent 共适:核心原则业务逻辑完全脱 UI,可桌面无头跑。经 CLI 给 agent,毫秒级迭代免模拟器。
CLI 让 agent 查态、导航、操作免触 UI,反馈循环极快,可自治工作数小时。
需模拟器时,CLI 远程连驱 UI 免布局树检,极速且支持 E2E。
下一步
我们将用 AI 把所有移动应用迁至 Swift 和 Kotlin。Shop 已全原生上架,Shopify 应用中,其余紧跟。快速但不降标:每重建须达到或超出现有性能稳定可达性等。不仅是换语言重写,而是重建立便人 agent 快理解测改。
迁移非终点。成功指团队更快交付更好体验,以产品速度、质量、agent 自治完工作量衡量。
我们会分享所得,深潜 Helix、agent 可寻址架构等。对 React Native 经验曾开放,此过渡同样。
致谢
原生现对 Shopify 正确,但2020年 React Native 也正确,其成归功于人。
Meta
感谢 Meta 的 React Native 团队优秀治理、听反馈、紧密合作。因你们对架构性能工具社区投入,React Native 今日更好。
William Candillon
感谢创 React Native Skia 并远超想象,重定图形动画可能。期待下一步。
Software Mansion
感谢 Reanimated 工作、听反馈、助解最难动画性能问题。
Shopify 工程师
数百工程师贡献采纳 React Native、迁移、建基础、提性能、维护集成、回馈生态。多人重做新手挑战假设促过渡成功同时持续交付。谢。
React Native 社区
谢所有用库、贡献、报 issue、挑战决策、分享者。反馈含辛辣亦促更好。
过去六年工具经验关系续塑我们建移动应用方式。深谢所有参与者。
评论
社区对 Shopify 从 React Native 转回 Swift 与 Kotlin 分歧明显:较多人认可大模型降低了原生开发成本、视其为合理趋势,但高赞质疑者指出文章缺乏长期成本数据,认为这不过是技术时尚轮回或跨平台框架并未真正省力的旧辩重演。
认为大模型显著降低原生开发成本、回归原生是行业趋势
- 论据:编码代理让不熟悉 Swift/Kotlin 的开发者也能借助工具快速生成双端原生代码,行业整体正从 RN/Flutter 转向原生;Shopify 从第一性原理重估技术栈值得肯定。(认可度:较多人)
- 引用:> 人工智能生成代码让直接编写原生变得轻松,不再需要中间框架(@kraig911)
质疑人工智能改变跨平台经济学的证据,要求公开成本数据
- 论据:文章只对比了不用代理的重写成本,未比较用代理维护现有 RN 的成本;缺少工时、缺陷率、模型花费等数字;代理让 RN 开发也变便宜,维护两份代码库反而增加长期分歧成本;剥离业务逻辑至命令行界面是架构调整而非原生论据。(认可度:高赞)
- 引用:> 他们展示了人工智能让重写更便宜,但没展示长期维护双端一致性的成本,一年后再拿数据说话(@hermitwriter)
跨平台框架并未真正节省人力,大厂应直接原生
- 论据:RN 最终常需掉进原生做优化,不如直写平台;历史上跨平台假设减头数却增加了工具链工程师,总数未少;资源充足的公司理应投资平台专属专长。(认可度:较多人)
- 引用:> 用 React Native 最后还是得写原生代码做优化,那直接平台开发更有意义(@evilfred)
这只是技术时尚的轮回,不必过度解读
- 论据:近二十年类似辩论反复出现(从 Cordova 到 RN),此次披着 AI 外衣;Shopify 曾高调宣扬 RN 性能如今回头,属正常循环。(认可度:较多人)
- 引用:> 时尚之轮再次转动(@quotemstr)
人工智能让原生与跨平台的分界移动,但是正常工程取舍
- 论据:不同公司资源不同,光谱上是否用跨平台的分界线因 AI 向左移,绝对化拥护或反对某工具价值不大。(认可度:较多人)
- 引用:> 人工智能正让这条是否使用跨平台的界线发生移动,这个判断可能是对的(@Waterluvian)
认为 React Native 其实对人工智能迭代更友好,转向原生反直觉
- 论据:作为原生开发者指出 RN 的热刷新等特性反而让它成为 AI 振动编码更好的栈,且今年工具链已成熟;多数 AI 应用用 Expo/RN 实现,此时弃用令人意外。(认可度:少数人)
- 引用:> 奇怪的是 React Native 的 hot refresh 等反而让它成为 AI 编码更好的栈(@pzo)
有价值的补充
- 有开发者实测借助代理工具一夜将中小规模应用双端转原生,启动明显变快(@atonse)
- 当前可考虑原生 Swift/Kotlin 配合 UniFFI 共享 Rust 代码,兼顾性能与复用(@railka)
- Hermes 虚拟机无 JIT,与 V8 性能差距大,React Native 仅适合少量 JS 缝合原生界面的场景(@faangguyindia)
- 脱离框架上游税是真实成本,但转为依赖编码模型的价格与条款同样不可控(@hermitwriter)