AI扼杀了React Native?

CSDN·2026年09月18日 20:22
React Native 在 2020 年是正确的选择,而原生开发在今天是正确的选择。

近日,Shopify 决定将旗下移动应用从 React Native 全面迁回原生开发。

其工程团队在官网最新发布《Native is now the future of mobile at Shopify》(原生开发,如今已成为 Shopify 移动端的未来)一文,宣布将所有移动应用迁回 Swift 和 Kotlin。

这个决定多少有些出人意料。

要知道在 2020 年,Shopify 曾大力押注 React Native,并在此后的几年里成为这一生态最重要的使用者和贡献者之一。其不仅用 React Native 构建了 Shopify、Shop、Point of Sale、Inbox 等大型应用,还开源了 React Native Skia、FlashList、Restyle 等一系列广受欢迎的工具。甚至就在 2025 年 1 月,Shopify 还曾公开大赞 React Native 的未来依然光明,并计划继续投入。

但短短一年后,Shopify 的决策变了。而这究竟是为什么?

Shopify 为什么突然放弃 React Native?

回看 2020 年,当时 Shopify 从原生开发毅然转向 React Native,官方给出的理由很明确:

第一,节省了大量时间,不再重复构建同样的功能;

第二,让没有移动端开发背景的工程师也能参与移动应用开发;

第三,不必不断追赶 iOS 和 Android 两个平台之间的功能差异。

这套逻辑在过去几年里确实发挥了作用。

Shopify 表示,React Native 帮助公司节省了大量开发时间,也让团队摆脱了长期维护 Android 和 iOS 双端功能一致性的压力。

但与此同时,Shopify 也承认,为了让 React Native 在如此大规模的应用中稳定运行,他们投入了大量资源,包括性能优化、基础设施建设、框架升级以及外部依赖维护。

这些成本过去是值得付出的,因为相比之下,iOS 和 Android 各写一套代码的成本更高。

随着时间的推移,一切悄然发生了变化。

Shopify 表示,公司早在 2021 年就开始使用 LLM 辅助软件开发,最开始主要用于实现功能、调查问题、修复 Bug 和代码审查。随着模型能力提升,AI 能承担的任务越来越复杂。

到了 2025 年底,Shopify 开始重新思考一个过去默认成立的假设:构建两套移动应用,真的还意味着要做两倍的工作吗?

于是,他们重新评估移动技术栈,并开始重新使用 Swift 和 Kotlin 语言进行原生开发,另外借助 LLM 重构了旗下大型应用的核心部分。

结果让团队感到意外。

AI Agent 不仅能够根据 iOS 版本实现 Android 功能,也能够帮助原本主要使用某一种技术栈的开发者参与另一端的开发。与此同时,通过共享的产品规范、测试和代码审查节点,iOS 和 Android 两端之间保持功能一致性的成本也被明显降低。

因此,Shopify 最终得出了一个非常明确的结论:

原生开发仍然意味着做两套软件,但 AI 已经能够承担其中足够多的实现、转换、测试和审查工作,使“重复开发”不再像 2020 年那样成为决定性成本。 

这里也需要特别注意,Shopify 并没有把这次迁移解释成“React Native 不行了”。

恰恰相反,官方明确写道:React Native 对 Shopify 来说一直运行良好,而且依然是一个优秀的框架。他们真正改变的是技术栈背后的成本。

用 AI 12 周完成应用重写

真正让这次迁移变得有说服力的,是 Shopify 已经拿实际项目进行了验证。

Shop 是 Shopify 最早迁移的应用。官方透露,在 AI 辅助下,团队从概念验证开始,到最终将完全重写的原生版本发布到应用商店,只用了 12 周。

而这并不是一个简单的小型 Demo。

Shopify 旗下还有更庞大的主应用正在迁移。官方表示,Shopify App 拥有超过 300 个页面,同时还包括主屏幕和锁屏小组件、Apple Watch 应用、复杂功能以及 Siri Shortcuts 等。

目前,这款旗舰应用的迁移已经开始,预计在 2026 年晚些时候发布原生版本。Shop、Shopify、Point of Sale、Inbox 等其他移动应用也将陆续迁移。 更值得注意的是,Shopify 这次没有采用过去那种“边运行边改造”的方式,而是选择重新开始。

为什么不是一点点迁移,而是直接“推倒重来”?

过去 Shopify 从原生迁往 React Native 时,曾经采用逐步改造的方式。那时的原因也很好理解。一个成熟的大型应用如果全部重写,可能需要几年时间,而在整个过程中,团队还得继续开发新功能。

但这一次情况不同,Shopify 认为,AI 已经让从零重写大型移动应用变得现实。官方给出的原因有三个:

AI 能够参考原有 React Native 版本,用 Swift 和 Kotlin 实现功能;

全新项目可以摆脱历史代码中的限制;

而此前的原型也证明,这种重写速度远高于过去。

所以,他们最终不是把旧的 RN 应用一点点改成原生,而是把 RN 应用当作“参考实现”,直接重新构建一套原生应用。

这一点其实非常关键。因为这意味着 AI 在 Shopify 的角色并不是简单的“代码补全工具”。它更像一个能够阅读旧系统、理解需求、实现另一套技术栈、运行测试并不断修改的迁移助手。

Shopify 那些 React Native 开源项目怎么办?

这也是社区最关心的问题之一。毕竟 Shopify 不只是 React Native 的使用者,它还是生态的重要贡献者。

对于一些主流的开源库, Shopify 在博客中清楚地写道:

React Native Skia 的维护不会立刻停止。Shopify 表示,会持续赞助该项目直到 2026 年底,William Candillon 也会在此后继续维护。接下来几个月,他将从现有仓库 fork 出一个新项目,并以新的名称继续发布。原来的仓库则会在迁移完成后归档。对于已经依赖 React Native Skia 的开发者,Shopify 也表示会提前发布迁移信息,并建议用户考虑直接赞助 William Candillon。 

FlashList 的情况不一样。Shopify 表示,该项目目前每周大约有 200 万次下载,已经成为 React Native 生态中高性能列表渲染的重要方案之一。因此,Shopify 不会立即放弃它。在新的长期维护者确定之前,Shopify 仍会继续修复那些可能导致兼容性问题的关键 Bug。目前,Shopify 正与多家公司讨论 FlashList 后续的长期维护安排。 

Restyle 会在 2026 年底停止维护。相比之下,Restyle 的用户规模更小。Shopify 已决定归档该仓库,并继续维护到 2026 年底,之后停止维护。项目允许其他团队直接 fork 并继续开发,Shopify 也表示会协助完成交接。 

从目前公布的方案来看,Shopify 试图把几个核心项目分别交给社区或者新的维护者。

重写过程中,AI 会不会写出一堆“垃圾代码”?

如果让 AI 直接读取一个庞大的 React Native 项目,然后说:“帮我全部转换成 Swift 和 Kotlin。”结果很可能并不会很好。

Shopify 自己也进行了这样的尝试。

官方直言,“直接把 React Native 代码库交给大语言模型,让它一次性把同样的功能用原生代码重写出来。但事实证明,这行不通。即使让模型先尽可能收集完整信息,将这些信息整理成规格说明和任务文件,再开始实现,最终得到的仍可能是一大堆难以维护、根本无法发布的代码。”

于是,他们专门构建了一套叫做 Helix 的系统,采用更加渐进的方式。它并不假设模型第一次生成的结果就是正确的,而是建立了一套持续迭代的闭环:一个不够完善的结果无法继续向前推进,只有经过不断修正并达到可用标准后,才能进入下一步。

具体来说,开发者只需要把某个页面交给 Helix。

Helix 会先读取 React Native 代码,然后提出一系列可以在几分钟内检查的小型任务节点。AI 每完成一个节点,都必须同时满足几个条件:

行为测试通过;

与正在运行的原应用进行视觉比对;

通过两次对抗式代码审查;

获得人类开发者确认。

只有全部通过,代码才能提交,然后进入下一个节点。

而前面每次审查得到的反馈还会被系统记住,让后续迁移过程越来越自动化。 

Shopify 发现,AI 写代码已经可以非常快。真正拖慢整个流程的,反而是移动端测试。

因为 AI 如果需要通过模拟器观察页面、读取无障碍树、点击按钮、截图,再判断结果,那么一次完整的反馈可能需要几分钟。

模型几秒钟就能修改代码,但验证一次却需要几分钟。

对于需要反复迭代的 AI Agent 来说,这种效率是无法接受的。

所以 Shopify 干脆重新设计应用架构。他们提出了一个核心原则——业务逻辑必须与 UI 完全解耦,而且能够脱离移动端界面,在桌面环境中无头运行。

然后,他们通过 CLI 把这套能力开放给 AI Agent。

这样,Agent 可以直接检查应用状态、进行导航和执行操作,不需要每一次都启动模拟器、观察界面。部分操作可以在毫秒级完成,而不是过去的分钟级。

只有真正需要验证 UI 时,Agent 才通过远程模式连接模拟器进行测试。 

React Native 真的要“凉”了吗?

对于这次迁移,不少网友直接将其解读为“AI 扼杀了 React Native”。

但 Shopify 自己并没有这么认为。它在文章最后特别强调:React Native 在 2020 年是正确的选择,而原生开发在今天是正确的选择。

其实,React Native 当年解决的核心问题,是开发者不想为不同平台重复编写大量相似代码。如今,AI Agent 正在接手其中一部分过去需要人工完成的重复工作。当“重复写代码”的成本开始下降,原本为了降低开发成本而存在的跨平台方案,自然就需要重新计算价值。

这也不意味着未来三年 React Native 或 Flutter 等这类跨平台框架就会失去价值。对于很多团队来说,跨平台开发依然意味着成熟的生态、更统一的开发体验,以及更低的维护成本。

但 Shopify 已经率先做了一次规模不小的实验。接下来真正值得关注的,或许不是 React Native 会不会“凉”,而是当更多大型团队拥有类似的 AI Agent 能力后,会不会重新审视过去的技术选择。

React Native 没有突然变差,变的是写原生代码的成本。而这,可能才是 AI 正在重新改写软件开发技术栈的地方。

本文来自微信公众号“CSDN”,整理:屠敏,36氪经授权发布。

+1
7

好文章,需要你的鼓励

参与评论
评论千万条,友善第一条
后参与讨论
提交评论0/1000

36氪AI测评

选靠谱AI,看真实评测
查看
36氪AI测评官方交流社区
加入

36氪项目推荐

咨询项目审核和入驻
联系
36氪项目推荐订阅号
关注

下一篇

这次,机器人进门直接干活。

1小时前

36氪APP让一部分人先看到未来
36氪
鲸准
氪空间

推送和解读前沿、有料的科技创投资讯

一级市场金融信息和系统服务提供商

聚焦全球优秀创业者,项目融资率接近97%,领跑行业