AI 杀死了 React Native 吗？从 Shopify 弃用说起

Shopify 的转向：从 React Native 回归原生

React Native 曾经的头号企业级背书者 Shopify，宣布放弃这套跨平台方案，重新回归 Swift 和 Kotlin 原生开发。这个消息在开发者圈引发了不小的震动。

回顾历史，Shopify 在 2020 年全面押注 React Native，收获颇丰：一次开发多平台复用、让没有移动端背景的开发者也能贡献代码、摆脱不断追赶功能对齐的负担。Shopify 工程师 Mustafa Ali 在此前的复盘文章中还写道，React Native 的未来一片光明，公司会继续投入。

但转折点来了。Shopify 官方给出的核心理由是：编码模型（LLM）显著变强了。用他们的话说，"用 Swift 和 Kotlin 构建相同功能，已经不再像 2020 年那样是决定性的成本因素。"当一个核心假设发生变化时，他们愿意从第一性原理重新评估整个移动技术栈。

他们重建了几个核心应用的部分模块进行验证，结果令人惊讶：AI Agent 可以参照 iOS 版本来实现 Android 功能，反之亦然；能帮助开发者快速上手非主力技术栈；还能通过共享规格、测试和评审检查点，大幅降低跨平台功能对齐的成本。Shop 应用是首个完成迁移的，从概念验证到应用商店上架，团队在 AI 辅助下仅用了 12 周。

被忽略的三个字母：OTA

视频作者 Theo（长期的 React Native 拥护者）认为，Shopify 的论述过度聚焦在"多平台复用"这个点上，而这从来都不是 React Native 最大的优势。真正让人难以割舍的是三个字母——OTA（Over The Air，空中更新）。

这里的关键在于理解 React Native 的本质。它不是网页，也不是原生的替代品，而是一个"控制原生元素如何渲染的指令层"。作者用了一个厨房的比喻：原生代码是厨房里技艺高超的厨师，而 React Native 的 JavaScript 层是那个告诉厨师做什么菜的人。App Store 不让你把厨师换出厨房，但你可以随时更换那个下达指令的人——这就是 OTA 的魔力。

为什么 OTA 如此重要？作者分享了他在 Twitch 时看到的真实数据：任意时刻都有一半以上用户运行着并非最新的 App 版本。他现场演示，自己手机上竟有 54 个应用待更新。这意味着你实际上并不只有一个 iOS App 或 Android App，而是拥有所有用户装过的、尚未淘汰的全部版本。一旦上线 bug，即便一小时后修复，报告还会持续几个月甚至几年。

原生开发遇到这种问题只能重新提交等待苹果审核；而用 React Native 配合 Expo，可以直接推送新的 JavaScript bundle 修复问题，绕过冗长的审核周期。作者特别指出，Shopify 并没有重度使用 Expo，这让它损失了 React Native 生态的大量红利——正如 Infinite Red 的 Jamin 所说："如果你用 React Native 却不用 Expo，你最终就是在重建 Expo。"

OTA（Over The Air）更新在技术层面的实现原理值得展开说明。React Native 应用的业务逻辑运行在 JavaScript 引擎（Hermes 或 JavaScriptCore）上，与原生二进制代码相互独立。应用商店的审核规则禁止替换已编译的原生二进制文件，但允许在运行时加载远程 JavaScript 包——React Native 的架构恰好满足这一条件。Expo 的 EAS Update（前身是 expo-updates）和 Microsoft 的 CodePush 正是利用这个机制，将新的 JS bundle 推送到已安装的应用上，整个过程对用户透明，无需经过 App Store 或 Google Play 审核。这意味着一个严重的线上 bug 可以在数分钟内修复并推送给所有用户，而原生应用的紧急修复版本通常需要等待数小时乃至数天的审核才能触达用户。对于面向消费者的高频使用 App，这种热更新能力直接影响用户留存和收入，其价值往往远超"一次开发多平台运行"带来的工程效率收益。

React Native 真正的短板在哪

作者也毫不避讳地列出了 React Native 的真实痛点，但顺序值得注意——性能、包体积这些常被吐槽的点，反而不在核心问题里。

关于包体积，一个有意思的数据：Shopify 从 React Native 迁移到原生后，App 竟然"大了 1MB"。React Native 运行时并不臃肿，默认的 Expo 应用大约在 20-30MB 区间。真正让应用膨胀的往往是本地化翻译文件和大量媒体资源，几张 PNG 就能让体积翻倍。

作者认为真正的短板有几个。第一是库的臃肿，但这更多归咎于 Xcode 里 CocoaPods 管理打包的混乱，而非 JavaScript 本身。第二是"陷阱"（foot guns）多——他甚至直言"普通 React Native 开发者的水平不如普通原生开发者"，因为原生更难，React Native 更容易上手，于是成了新手的默认选择，让陷阱更加显眼。第三是 React Native 作为移动目标的混乱性，版本升级往往痛苦不堪。第四则是对 Meta 的依赖——苹果出了新特性，你得等 Meta 支持或者自己写垫片。

Meta 团队变动：真正值得警惕的信号

文章最深刻的洞察在于 React Native 团队本身的状态。作者抛出一个问题：Meta 巅峰时期在 React 核心团队和 React Native 团队分别投入了多少工程师？答案是——React 核心/网页那边不到 30 人，而 React Native 一度超过 300 人，接近 10:1 的悬殊比例。

原因不难理解：React Native 要在单一代码库里向 JavaScript 层暴露 iOS 和 Android 几乎全部的原生功能，其工程难度远超只需处理 DOM 的 React。而且团队里聚集的恰恰是最顶尖的原生开发者——正是因为他们太热爱原生，才不希望一个刚毕业的广告团队 JavaScript 新手把 App 搞砸，于是写出了最好的原生绑定。

但现在情况变了。Meta 一直在解散 React 和 React Native 团队，像 React Compiler 的核心工程师 Lauren 这样的人才纷纷流向 Cursor 等公司。团队规模缩小、投入减少，意味着我们过去依赖的那份卓越工程质量正在退潮。新架构（New Architecture）算是团队在动荡中交出的一曲"天鹅之歌"，如今已成为默认选项，大幅提升了原生层与 JavaScript 层的桥接性能。

React Native 的"新架构"（New Architecture）是理解当前生态健康度的重要背景。旧架构使用异步 JSON 序列化桥（Bridge）在 JavaScript 线程与原生线程之间传递消息，这一设计导致频繁的跨线程通信成为性能瓶颈，也使得某些同步操作（如手势响应、布局测量）难以实现。新架构的核心是用 JSI（JavaScript Interface）替换旧桥，让 JavaScript 可以直接持有原生对象的 C++ 引用并同步调用，彻底消除序列化开销；配套的 Fabric 渲染器和 TurboModules 分别重构了 UI 树管理与原生模块加载方式。从 React Native 0.76 起，新架构已成为默认选项。这套架构的落地耗费了 Meta 团队数年时间，被视为团队在规模收缩前交出的集大成之作，为社区留下了一个性能与扩展性都更为扎实的基础，但后续迭代能否延续这一势头，仍取决于开源社区与 Expo 能否填补 Meta 撤退留下的真空。

AI 让原生开发的门槛塌陷

作者的核心论点浮出水面：过去你不得不用 React Native，很大程度上是因为 Meta 雇的原生工程师比你团队里的强得多，蹭他们的成果能让 App 更好。但现在，Codex、Sora 这类 Agent 在原生代码上同样出色，这个技能鸿沟被极大地填平了。

作者用亲身经历佐证：他把自己的 React Native 版 T3 Code 应用，用 AI（主要靠 Sol 模型）分别移植成了 UIKit 版和 SwiftUI 版，每次构建耗时不到三小时，由 Agent 在循环中自动完成。他坦言自己"一行代码都没读过"，但应用运行良好，正是他每天写代码用的工具。

他因此对 Shopify 的"翻车"感到困惑，怀疑他们可能过度依赖了 OpenAI 的模型或不成熟的 computer use 工具。他也批评了 Shopify 那套名为 Helix 的迁移系统"过度工程化"，认为把 CRUD 应用的数据层做成 headless 供 Agent 测试是舍近求远——Expo 本可以解决大部分问题。

不过作者也承认，即便 AI 填平了技能差距，他仍会怀念 OTA、怀念真正好用的列表组件、依旧要忍受苹果的开发流程折磨。他甚至讲了一段 SwiftUI 原生导航的坑：官方导航栈只支持从屏幕最左侧滑动返回，而大量用户习惯从屏幕中间滑动——连苹果自家的设置和 iMessage 都没用官方导航栈，就是为了兼容各种返回手势。这再次说明所谓"最可靠的原生方案"有时反而会坑到用户。

文中提到的 UIKit 与 SwiftUI 代表了 iOS 原生开发的两个时代，理解二者差异有助于判断 AI 移植的难度。UIKit 是苹果 2008 年随初代 iPhone SDK 推出的命令式框架，开发者通过显式操作视图对象的属性和层级来描述界面；SwiftUI 则是 2019 年推出的声明式框架，语法风格与 React 高度相似——用状态驱动视图，组件化组合，这也是为什么有 React 背景的开发者往往更容易上手 SwiftUI。然而 SwiftUI 至今仍存在若干成熟度问题：部分复杂布局行为与文档不符、旧系统版本支持有限，且如文中导航手势案例所示，某些"原汁原味的原生体验"反而需要混入 UIKit 才能实现。AI 在生成 SwiftUI 代码方面表现更为稳定，原因之一是 SwiftUI 的声明式模式与训练数据中大量的 React/HTML 代码具有结构相似性，这在一定程度上解释了作者为何能以如此低的门槛完成移植实验。

结语：一场值得尊敬的豪赌

作者最终把 Shopify 的决定看作一次有价值的实验。React Native 本身当年就是一场豪赌——一群才华横溢的人看到 React 在网页上的成功，大胆地想"如果用它重新发明移动开发会怎样"，结果成了。

Shopify 现在的赌注异曲同工：既然 Agent 这么擅长移植软件，何不用它们把应用迁回原生？作者强调，他自始至终没有把"多平台"当作 React Native 的核心卖点，也不认为原生天生更优越。React Native 的精髓从来不是"一次编写到处运行"，而是"一次学习到处理解"——懂了 React，再理解移动端的手感，就能做出好应用。

无论选择 React Native 还是原生，真正决定 App 好坏的，是有没有人愿意在 iOS 和 Android 上都认真测试。作者半开玩笑地说，最好的办法不是选什么框架，而是逼团队里的人真正去日常使用 Android 手机。