Shopify 宣布放弃 React Native，AI 编码智能体让回归原生开发成为新选择
Why has Shopify dropped React Native?
Shopify 宣布原生开发是其移动开发的未来，Shop 应用已在 12 周内用 AI 重写为完全原生的 Swift 和 Kotlin 应用，其余应用将陆续迁移。
文章梳理了 Shopify 从 React Native 转回原生的决策过程，核心变化是 AI 智能体降低了跨平台共享代码的优势。
开始之前：鉴于本文讨论的是原生移动开发，我想向所有读者免费提供我 2021 年的电子书《大规模构建移动应用：39 个工程挑战》（原价 20 美元）。这本书对于大型移动应用需要解决的挑战依然具有现实意义，并列举了本文下面涵盖的技术，包括 Kotlin Multiplatform。
此优惠有效期至 10 月 2 日星期五。结账时，只需选择“电子书：本书的 PDF 和 EPUB 版本”。无需信用卡！欢迎与构建移动应用或从事相关工作的同事分享此链接。
最近，Shopify 抛出了一枚重磅消息：原生开发现在是该电商平台移动开发的未来。这在移动开发社区引发了大量反响，其规模堪比六年前 Shopify 最初转向 React Native 时引发的轰动。
但时代已经变了，我们都知道这次的变革推动者是谁：AI 智能体！最新一代模型在编码能力上的提升，已经到了让 Shopify 不再满足于 React Native（RN）的程度，而就在去年它还对 RN 很满意。
本文探讨这一局面是如何形成的、Shopify 为何做出改变，以及更广泛的移动生态。我们涵盖：
Shopify 为何在 2020 年选择 React Native。首要原因是 Android 应用构建耗时过长，而 iOS 和 Android 应用保持一致是件好事。
五年后依然满意。Shopify 将全部六款应用迁移到 RN，大多数事情进展顺利，2020 年的迁移被视为明智之举。
为何现在放弃 React Native？AI 现在非常擅长编写移动端代码和后端代码，而 React Native 引入了原生开发没有的抽象层。Shopify 仅用 12 周（！！）就将 Shop 应用重写为原生。来自 Shopify 移动团队的更多细节。
我们以前没见过这种反复吗？Airbnb 做过类似的事：2016 年采用 React Native，两年后又迁回原生。根本原因相同：性能。
自 2019 年起转向原生。迁移到原生过去需要很长时间，Notion 已经做了七年。当 Notion 完成这一过程时，一个合理的问题是：无论有没有 AI，原生编辑器是否真的会拖慢他们的 Web 迭代速度。
Kotlin Multiplatform（KMP）也想说两句。KMP 允许用 Kotlin 编写业务逻辑，并在 iOS 和 Android 之间共享，同时各平台保持原生。这项技术让人感觉切合当下，并可能随着 AI 变得更流行。
接下来会怎样？编写原生 iOS 和 Android 应用比以前更容易了，但 React、Flutter 和 KMP 应用也是如此。
1. Shopify 为何在 2020 年选择 React Native
让我们回到 2020 年，当时 Shopify 决定全力投入 React Native（RN）。那时，移动端是该平台非常重要的渠道，十分之七的客户在移动设备上使用它。时任工程主管的 Farhan Thawar 当时写道：
“每个季度，大多数买家都通过移动端购物（去年第三季度[2019年]，我们有71%的买家通过移动端购物）。黑色星期五和网络星期一（合称BFCM）是我们商家一年中最繁忙的时期，这几天的购买活动是一个风向标。在今年的BFCM期间，Shopify商家的移动端购买量又增长了3%，平均占销售额的69%。”
既然移动端如此重要，公司为iOS和Android构建原生移动应用也就不足为奇了；毕竟，原生移动端可以完全控制平台的能力、集成和性能，那为什么还要费心使用跨平台技术呢？
事实证明，原因之一是Android原生应用的发布延迟，Shopify和其他公司一样都在这个问题上苦苦挣扎。
当Android发布需要一年以上：Clubhouse的失败
在十年之初的疫情期间，实时对话应用Clubhouse在2020年3月推出后大获成功。该应用在最初14个月里仅支持iOS，因为团队无法发布Android应用。而到了年底，使用量彻底爆发：
尽管如此受欢迎，Clubhouse当时在Android上却无法使用！
Clubhouse花了14个月才在Android上推出测试版，而等到2021年5月推出时，该平台已在几个月前过了巅峰期，使用数据当时呈下降趋势。直到2021年7月，Android版Clubhouse应用才在全球推出——比iOS版晚了16个月——此时已来不及赶上增长浪潮，这注定了这家前景光明的企业走向失败。
这是怎么发生的？主要有几个原因：
为Android构建出色的应用比iOS更复杂：需要支持更多设备类型，还要支持使用不同API的旧版操作系统。
在低端Android手机上获得良好性能很困难。
我也怀疑Clubhouse团队是在为一个从未实现的规模做工程。也许他们试图打造一个“完美”的应用来全球发布，却错过了增长浪潮，这意味着与一个本可以更早发布、更及时地惠及业务的版本相比，该应用最终“过度设计”了。
从零开始构建原生Android应用——即使有现成的iOS应用作为蓝图——在2010年代和2020年代初都是一项挑战。Clubhouse是一个企业出问题的极端案例，部分原因就是Android发布迟缓。
但客户习惯可能也起了作用：当时，大多数美国初创公司优先考虑iOS应用和功能，因为在美国，最有价值的用户越来越多地出现在iOS上。对于主要客户在美国的公司来说，优先考虑iOS在商业上是合理的，但对于业务遍布全球的公司来说则不然，因为在亚洲等地区，智能手机用户主要使用Android。
React Native帮助Shopify更快地增加了Android支持
Shopify与React Native的第一次积极体验是在2018年，当时是Shop app（当时叫‘Arrive’）。公司总结道（强调为我所加）：
“2018年底，我们决定用 React Native 重写我们最受欢迎的消费者应用之一 Arrive（现为 Shop 应用）。Arrive 绝非等闲之辈；它是一款评分很高、性能出色、在 iOS 上拥有数百万次下载的应用。它是一个很好的候选对象，因为我们没有 Android 版本。我们的努力将帮助我们触达所有渴望使用 Arrive 的 Android 用户。现在它在 iOS 和 Android 上都是 React Native，并共享 95% 的相同代码。我们将在未来的博客文章中深入探讨 Arrive。
到目前为止，这次重写带来了：
iOS 上的崩溃次数少于我们的原生 iOS 应用
推出了 Android 版本
一支由移动端和非移动端开发者组成的团队。”
转向 React Native 是加速推出新应用 Android 版本的最简单方法之一。2020 年，当 Shopify 宣布这一举措时，这就是其声明的意图：
“我们广受欢迎的 Shopify Ping 应用（现名为 Shopify Inbox）已支持数十万次客户对话，目前仅支持 iOS。2020 年，我们将由旧金山办公室使用 React Native 构建 Android 版本，并且我们正在招聘。”
2. 五年后依然满意
去年，Shopify 在一篇回顾文章《React Native 五年》中宣布，它对转向 RN 感到满意。这份总结堪称一场胜利巡礼：
“回顾一下，我们决定改用 RN 主要有三个原因：
一次编写 - 不再为同一功能构建两次，一次在 iOS 上，一次在 Android 上
人才可移植性 - 让开发者能够在 iOS、Android 和 Web 之间流畅工作
交付更多价值 - 花更多时间为用户交付价值，而不是追逐功能对等
我们很高兴地分享，我们的过渡相当成功：
不必两次构建相同的功能，让我们的生产力实现了阶跃式提升
工程师能够跨 Web 和移动端工作，使团队在相同人数下做更多事情，并解锁了新的增长机会
保持 iOS 和 Android 之间的功能对等已不再是问题，释放了交付更多价值的能力
我们的应用速度极快（<500ms 屏幕加载）且稳定（>99.9% 无崩溃会话）
我们继续在原生是最佳工具的地方利用原生，从而兼得两者之长
在过去 5 年里，我们已将全部应用迁移到 React Native。我们没有采用一刀切的方法，而是由每个团队选择何时以及如何迁移其应用。这使他们能够继续交付功能，同时与我们的 RN 利用战略保持一致。”
他们并非虚言：五年内，六个移动应用迁移到了 React Native：
Shopify 的工程团队表示，他们很喜欢 React Native 的许多方面。Mustafa 解释道：
“速度。RN 应用很快。我们在 Shopify 应用中实现了低于 500ms（P75）的屏幕加载。我们在所有应用中都实现了类似的性能。就像原生一样，你必须应用良好的模式和技术来消除性能瓶颈。
热重载。这是我们在原生方面最大的痛点之一。鉴于我们代码库的规模，即使是最微不足道的更改，也需要几分钟才能在模拟器/物理设备上编译和运行。这浪费了时间并打断了开发者的心流。React Native 的热重载完全消除了这个问题。
TypeScript 作为开发者的“共享”语言非常出色。 TypeScript 已经无处不在，我们看到开发者在 React Web 和 React Native 之间转换取得了巨大成功。”
也有一些新的挑战：
调试更糟糕：“React Native 中的调试很不稳定，在 VS Code 中正确配置需要一些功夫。另一方面，iOS 和 Android 拥有强大的调试能力，开箱即用”
原生代码和原生开发者仍然重要。对于性能密集型代码、某些动画、长时间运行的后台任务和专用 API（如主屏幕小组件），你会需要原生代码。
更多第三方库。“与原生相比，React Native 框架不够全面，因此你最终不得不使用更多第三方库。”
但科技领域的变化能有多快……
3. 为什么现在要放弃 React Native？
本月 Shopify 宣布原生开发现在是 Shopify 移动端的未来，这意味着 RN 突然成为历史，这引起了广泛惊讶。
移动端负责人 Mustafa Ali 表示（重点为我所加）：
“2025 年 1 月，我曾写道 React Native 的未来是光明的，Shopify 计划继续投资于它。基于我们当时所知，那是事实。React Native 对我们运行良好，它仍然是一个出色的框架。但自那以后，编码模型已经大幅提升，对于我们的应用和团队来说，用 Swift 和 Kotlin 构建相同的功能不再像过去那样带来成本。
原生开发仍然意味着要在两个平台上构建和维护软件，这一成本并未消失。改变的是，智能体现在能够完成足够多的实现、转换、测试和审查工作，使其不再是 2020 年那样的决定性因素。
React Native 应用可以很快。我们的应用就是如此。我们做出这一改变，是因为智能体降低了共享实现带来的优势，而针对每个平台构建的优势依然存在。原生开发让我们更贴近平台能力和第一方工具，我们的代码与平台之间的框架和依赖层更少。”
当然，选择原生而非跨平台一直都有利弊。在 AI 之前，情况是这样的：
改变的是，AI 编码智能体现在在生成 iOS 和 Android 代码方面能力大大增强。
React Native 如何渲染元素——回顾
毫无疑问，完全原生的应用构建良好，并且始终比基于 React Native 这类跨平台解释器构建的应用更高效。尽管如此，RN 已经取得了长足进步，性能大幅提升——在 RN 代码和原生代码之间增加了一个额外的抽象层——尤其是自 2024 年的新架构以来。让我们可视化它的工作原理：
React Native 的核心理念是通过昂贵的渲染操作来最小化 UI 上的更新。因此，RN 在屏幕上维护一个视觉元素的React 宿主树（可以理解为“逻辑树”），它转换为宿主视图树，即在 iOS 和 Android 上的表示。React 本身巧妙地最小化了重新渲染操作，从而节省了计算资源。
为什么原生应用在性能上必然胜出
如上所述，编写良好的原生应用自然优于 React Native 版本。要了解原因，最简单的方法是勾勒出原生应用渲染时发生的情况，并与 React Native 进行对比：
React Native 理论上可能性能更高，但前提是原生版本的结构编写不佳，或者 UIKit / Jetpack Compose 或任何其他原生库效率足够低，这种情况不太可能发生！但原生的抽象层要少得多。
自从 Shopify 转向原生开发以来，一个常见的问题是，为什么 Shop 应用没有迁移到新架构以改善启动性能等方面。我就此联系了移动端负责人 Mustafa Ali。他告诉我：
“我们实际上已将其他大型 Shopify 应用迁移到新架构。Shopify 和 Point of Sale 都已迁移，我相信我们是 Meta 之外首批这样做的大型团队之一。
这次迁移带来了一些性能提升，但幅度不大。Android 上的应用启动速度提高了约 10%，iOS 上提高了 3%，而一些复杂界面在调优之前实际上变慢了。”
该团队已详细撰文介绍迁移到新架构的过程。尽管如此，使用原生代码提供了更多提升性能的机会；毕竟，你现在可以控制整个渲染栈！此外，你还可以抛弃 Apple 构建的系统库（如 UIKit 或 ComposeKit），构建性能更高的库。Shopify 不打算走到这一步，但工程负责人 Farhan Thawar 告诉我，他们预期会获得性能提升：
“我认为这些原生应用能好到什么程度，我们现在才刚刚起步。我预计随着迁移后我们逐步梳理代码库，它们会变得更快——比如启动时间更短、交互更灵敏。”
一名工程师，借助 AI 开发两个平台
React Native 的一个好处是，不必同时拥有 iOS 工程师和 Android 工程师。但有了 AI，一名工程师就能为两个平台构建软件，Mustafa Ali 告诉我：
“过去转向 RN 的一个文化好处是，我们不像大多数原生开发团队那样，分设独立的 iOS 和 Android 团队。
我们只有一个团队，同一名开发者在 iOS 和 Android 上构建同一功能。这样上下文集中在一处，没有沟通开销。
随着 LLM 让在自己主要专业领域之外贡献代码变得容易，我预计未来几个月这种情况会变得更加普遍。”
Farhan 说得更简单：
“基本上，React 作为共享语言，现在已被英语取代，这要归功于 LLM。”
借助 AI，共享代码库变得更简单
转向原生的另一个缺点是，需要维护两个代码库，而它们在行为、功能和缺陷上往往会出现分歧。但有了 AI，Shopify 不再认为这是个大问题。Mustafa：
“在 LLM 出现之前，维护两个独立的代码库是件大事，但现在不是了。
智能体非常擅长将功能从 Android 移植到 iOS，或者反过来。 它们还擅长随时间比较两种实现。它们能发现代码中的差距，并通过并排测试发现并修复问题。”
Shopify 还在构建一套共享的验证测试套件，以验证两个应用完全一致。同样，来自 Mustafa 的说法：
“我们现在有一套共享测试套件，用于验证在 Swift 和 Kotlin 中实现的业务逻辑。这意味着，一个功能在通过两个平台上完全相同的测试之前无法发布。该逻辑在桌面端以无头方式运行，这为智能体提供了非常快速的反馈循环来进行迭代。”
聪明！这也印证了我的感觉：验证代码在与智能体协作时正变得非常重要，构建专门的验证层同样如此。
React Native 与原生开发如今的对比
让我们回到对比表，并针对原生 + AI 如何改变 Shopify 的处境来更新它：
我个人的感觉是，随着 AI 工具变得如此出色，原生开发的缺点正在消失，而 Shopify 现在完全掌控其原生应用的性能和架构。
在决定借助 AI 全面转向原生开发后，这家电商企业正致力于迁移其所有应用。借助 AI，这应该会比当初迁移到 React Native 更快。Mustafa 再次表示：
“我们将把旗下所有移动应用迁移到 Swift 和 Kotlin，并在整个过程中使用 AI。
Shop 已在短短 12 周内作为完全原生应用发布，Shopify 应用正在推进中，其余应用也将很快跟进。我们推进得很快，但并没有降低标准。
每一次重建都必须达到或超越人们如今所期望的性能、稳定性、无障碍性和产品质量。这不仅仅是把同样的应用用不同语言重写一遍。我们重建它们，是为了让人类和智能体都能快速理解、测试和修改它们。”
祝团队这次迁移顺利！我很期待听到他们从这次行动中学到了什么。
4. 这种反复来回，我们不是见过吗？
来源：Pragmatic Engineer · newsletter.pragmaticengineer.com