Shopify 宣布放弃 React Native，AI 编码智能体让回归原生开发成为新选择
Why has Shopify dropped React Native?
Shopify 宣布原生开发是其移动开发的未来，Shop 应用已在 12 周内用 AI 重写为完全原生的 Swift 和 Kotlin 应用，其余应用将陆续迁移。
文章梳理了 Shopify 从 React Native 转回原生的决策过程，核心变化是 AI 智能体降低了跨平台共享代码的优势。
译文尚不完整，完整内容请切换到原文。
Before we start: given this article is about native mobile development, I want to offer my 2021 ebook, ‘Building Mobile Apps at Scale: 39 engineering challenges’, for free to all readers. (normally costs $20). The book remains relevant on the challenges to solve for large-scale mobile applications, and lists the technologies covered below in this article, Kotlin Multiplatform included.
此优惠有效期至 10 月 2 日星期五。结账时，只需选择“电子书：本书的 PDF 和 EPUB 版本”。无需信用卡！欢迎将链接分享给构建或从事移动应用的同事。
最近，Shopify 投下了一枚重磅炸弹，宣布原生开发现在是该电商平台移动开发的未来。这在移动开发社区引发了大量反响，其规模堪比六年前 Shopify 最初转向 React Native 时引发的轰动。
但时代已经变了，我们都知道这次的变革推动者：AI 智能体！最新一代模型在编码能力上的提升，已经到了让 Shopify 不再满足于 React Native（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）。那时，移动端是该平台非常重要的渠道，10 个客户中有 7 个在移动设备上使用它。作为工程主管，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的OS版本。
在低端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 app）。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 在一篇回顾文章《Five years of 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 宣布 Native 现在是 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（RSS） · newsletter.pragmaticengineer.com