为何 Shopify 放弃 React Native 并不会威胁 Expo
解释了为何 Shopify 从 React Native 转向原生 Swift 和 Kotlin,并不意味着对大多数团队而言跨平台 Expo 开发就此终结。
2026年9月10日,Shopify宣布将把其核心移动应用从React Native中移出,转而使用Swift和Kotlin进行原生重写。几小时内,开发者论坛上便充满了各种猜测。社交媒体上的帖子纷纷讨论这是否意味着React Native的终结,还有些博客文章甚至宣称跨平台移动开发已经走到了尽头。
如果你使用Expo进行开发,就无需为这些担忧。
Shopify的实际举措及原因
Shopify给出的理由相当简单:人工智能编码助手使得为iOS和Android维护两个独立的原生代码库变得成本低廉得多。React Native最初的优点是通过跨平台共享代码来节省工程时间。而一旦人工智能工具能够高速生成原生Swift和Kotlin代码,对于Shopify这样规模的企业来说,这种成本收益计算方式就会发生变化。
关键在于“像Shopify这样规模的机构”。
Shopify运营着全球最为复杂的移动应用之一,拥有数百名工程师、数百万商家,其性能要求足以对任何开发框架进行压力测试。当Shopify称人工智能让原生开发变得更经济实惠时,这是基于其能够同时维护两个庞大且复杂的代码库的实际情况而言的。
大多数Expo开发者并不具备这样的条件,如今开发应用的普通团队也是如此。
Expo与Shopify解决的是不同的问题
对于 Shopify 而言,React Native 主要是一种在庞大的工程团队中降低成本的方式。而对于 Expo 开发者来说,React Native 是一种工具,让单个开发者或小团队无需成为任一原生平台的专家,就能在 iOS 和 Android 上发布功能完备、界面精美的应用。
这两种使用场景几乎没有任何共同点。
Expo 拥有一支专门的核心团队,多年来一直在不断优化移动端最出色的开发者体验之一。最近发布的 SDK 57 进一步提升了性能、构建工具以及开发者的日常使用体验。像 NativeWind、Reanimated 和 Expo Router 这样的配套库也比以往任何时候都更加稳定,更适合实际生产环境使用。
仅仅因为一家大型零售商决定放弃它,并不会改变这一切。
数据讲述着不同的故事
当评论者们忙着宣称 React Native 已经走向终结时,实际的使用数据却显示了另一番景象。
专为 React Native 设计的 Tailwind CSS 风格样式解决方案 NativeWind 在 2026 年的每周下载量已突破 130 万次,并且仍在持续上升。Expo 在开发者社区和各类讨论中依然占据重要地位。像 Uniwind 这样的新样式库也相继出现,仅在几个月内就获得了数十万的每周下载量。
这些数据并非表明该生态系统正在萎缩,而是说明它仍在不断成熟。
那些在 Shopify 发布公告后立即放弃 React Native 的人,很可能本来下个月就会找其他借口离开。而那些真正使用 Expo 开发实际产品的开发者们则并未重新考虑自己的选择。
AI 让 Expo 开发更高效,而非使其过时
所谓“人工智能导致了React Native的衰落”这一观点其实蕴含着极大的讽刺:实际上,人工智能工具让使用Expo进行开发变得明显更好,而非更差。
Claude、Cursor和GitHub Copilot这类助手对Expo生态系统有着深入的理解。只要有一份结构清晰的、记录了组件规范和架构模式的CLAUDE.md文件,这些助手就能在保持与整个代码库一致性的前提下,添加新界面、开发新功能并重构现有代码。
那些能从这种工作流程中获得最大价值的人,有时被称为“氛围编码者”,因为他们只需描述期望的结果,让助手负责实现细节,但他们仍然需要一个扎实的初始结构。人工智能工具在编写代码方面表现优异,但在做出架构决策、设计导航流程、构建主题系统或从零开始创建一套统一的共享组件方面则远不如人意。
正是这一缺口被精心设计的 Expo 启动模板所填补。这并非关乎人工智能助手能够按需生成的代码,而是关乎让人工智能辅助编码真正发挥效用的底层结构。
模板是人工智能辅助开发的基础层
当开发者打开 Cursor 或 Claude 开始开发新应用时,第一个实际需要考虑的问题就是他们将从哪个代码库开始。
从空的 create-expo-app 输出开始,意味着你需要花费最初的几个小时来设置导航、添加深色模式支持、构建基础 UI 组件,并确定开发规范。人工智能可以协助完成部分工作,但在建立起可用的基础之前,仍然需要人工决策、配置以及反复迭代。
而如果从已准备好的生产级模板开始,那么基础工作就已经完成。你只需打开人工智能编辑器,描述接下来想要的功能,助手就会提供一个结构清晰、组织良好的代码库供你扩展。
正因如此,那些专为人工智能辅助开发流程设计的模板——包含详尽的 CLAUDE.md 文档、清晰的组件级说明以及一致的编码模式——如今比两年前更为重要,而非更不重要。
真正应该担忧的开发者们
如果Shopify的这一举措会让谁感到担忧,那一定是那些在Expo生态系统之外开发纯React Native应用、直接依赖React Native CLI,并且面向拥有足够工程团队来支持全原生开发的企业级客户的开发者。
这其实只涵盖了使用React Native的人群中的极小一部分。
而对于独立开发者、自由职业者、小型工作室,或是那些主要通过向AI助手描述需求来开发首个应用的人而言,Expo依然是将想法快速转化为在两大主流移动平台上可发布的应用的最佳途径。Shopify的决策并不会改变这一事实。
这对您意味着什么
继续使用 Expo 进行开发,持续通过它发布应用。该生态系统发展良好,相关工具也在不断迭代优化,围绕它的社区也依然活跃。
如果你要启动一个新的 React Native 项目,建议从可直接投入生产的模板开始,而非空白项目,然后让 AI 助手在现有基础上处理具体实现细节。这样的组合能让你的发布速度远超从零开始开发。
有些开发者会因为某家公司的公告,在接下来的几周里反复研究各种观点并质疑自己的技术选择;而另一些开发者则会继续专注发布他们的应用。
努力成为后者吧。
相关阅读
- Nitro Modules:静态绑定为何能超越 React Native TurboModules — 阐述了 Nitro Modules 如何通过使用预编译的静态绑定而非动态查找,从而在性能上大幅优于 React Native 中的 TurboModules 和 Expo Modules。
- React Native、Flutter 及其他技术:2026 年的跨平台移动开发 — 从性能、开发者体验及生态系统成熟度等方面对 React Native、Flutter、Kotlin Multiplatform、Ionic、NativeScript 以及 PWA 进行了对比分析。