CI/CDEAS BuildexpoOTA 更新react-native

为什么 Expo 很适合新应用和现有应用

Expo 不是 Web 包装器，而是原生应用框架，让 iOS 和 Android 共用一条原生发布路径，AI agent 也能直接接入。

Expo BlogKeith Kurak7 分钟阅读

中文
中文日本語
复制
Why Expo is a great fit for new and existing React Native apps

什么是 Expo？

Expo 是一套用于构建原生 iOS 和 Android 应用的框架（SDK、CLI、Modules、Router、prebuild），此外还提供可选的 EAS 云服务，涵盖模拟器、构建、OTA 更新、应用提交和可观测性。它不是 Web 包装器。

是的。Expo 应用就是原生应用。你的 React 组件会映射到真实的 iOS 和 Android UI 原语；当需要用到尚未被封装的平台 API 时，可以用 Expo Modules API 编写 Swift 或 Kotlin。你仍然需要为 iOS 和 Android 发布商店二进制包。

AI agent 与单一原生发布路径

如今，编码 agent（Cursor、Claude Code、Codex 以及类似工具）承担了大量 UI 和业务逻辑的编写工作。这并不改变原生这一事实：产出最终仍要作为真正的 iOS 和 Android 应用编译并运行。真正值得问的是：你是想让 iOS 和 Android 共用一条原生发布路径、把 agent 放进这个流程里，还是维护两套彼此独立的原生代码库。

Expo 为 agent 提供了统一的项目形态：

  • 一份 TypeScript 代码库，在两个平台上渲染原生视图

  • 持续原生生成（CNG），让原生工程始终可重新生成，而不是被手工 fork 后永远维护下去

  • 当 agent（或你）需要在 JavaScript 之外使用 Swift 或 Kotlin 时，用 Expo Modules

  • EAS Build、EAS Update 和 development build，让从 PR 到设备的路径保持一致，无论 diff 是人写的还是 agent 写的

Expo MCP Server 和 Expo Skills 让 agent 掌握当前的 Expo API 与工作流。它们是给 agent 用的文档和工具，不是一个单独的「Expo Agent」产品。你不需要再买一个 agent 产品——把 Expo MCP 交给你的 agent，让它们去构建就行。

Agent 降低了编写平台代码的成本，但并没有消除同时维护两个产品的成本：两条发布节奏、两处修行为、两处做验证。当一个团队只负责一个应用时，共享的原生发布路径依然重要。而当共享 UI 很薄，或者组织要求技术栈分离时，双原生仍然是正确的选择。

Expo 应用是原生的吗？

Expo 应用就是原生应用。JSX 只是你在 Xcode 或 Android Studio 里会用到的那套 UI 组件之上的一层外壳。Expo 并不取代这个模型，它把大多数生产应用都需要的框架部件打包好：导航、设备 API、prebuild、构建、更新，以及用于自定义原生代码的 Modules API。

生产应用使用 development builds，把原生依赖直接打进去。需要时，CNG（npx expo prebuild）会根据 app config 和 config plugins 生成 android 和 ios。你维护的是原生定制的定义，而不是每个生成文件的永久 fork。参见 Continuous Native Generation。旧文档可能还在说 managed vs bare 或 React Native CLI，但对大多数新的 Expo 应用来说，这些说法已经过时了。

React Native vs native

团队纠结 React Native vs native 这个语义讨论时，通常指的是 Expo/React Native 与独立的 Swift、Kotlin 应用之间的取舍。下表有助于理清思路：

维度Expo + React Native独立的 iOS + Android 应用
UI 与业务逻辑一套共享的 TypeScript 代码库两套代码库（Swift/Kotlin 或类似）
原生 APIExpo SDK + Expo Modules（需要时写 Swift/Kotlin）第一天就能用上完整的平台 SDK
原生工程维护CNG + config plugins；原生目录可选是否提交持续手动维护 Xcode / Android Studio
商店二进制包EAS Build（或你自己的 CI）产出 iOS 和 Android 二进制包两条构建流水线
OTA（JS / 资源）EAS Update 处理兼容的 JS 和资源通常只能走商店，除非自建 OTA 方案
AI / agent 循环单一工程形态，MCP + Skills，共享 PR 路径agent 必须让两个应用保持同步

三个起点

对 React Native 感兴趣（来自双原生团队）。 跨平台只有在保住原生质量的前提下才有意义。Expo Modules 让你针对关键 API 或视图直接写 Swift 或 Kotlin，而不必放弃共享应用。如果你第一天就需要最新的 OS API、大量平台专属 UI 且共享逻辑很少，或者组织规定 iOS 和 Android 必须分团队且不共享运行时，那双原生仍然更合适。

准备上手 React Native（新的 RN 应用）。 从 Expo 开始。Meta 推荐新应用使用 React Native 框架。不用框架的话，导航、原生模块、构建工具和升级路径都得自己拼。CNG 把原生目录挡在外面，直到你需要它们。Expo SDK 覆盖了相机、通知、图片等常见需求，省得你第一天就选一套脆弱的方案。

熟悉 React Native（已有 RN 应用）。 安装 expo，然后逐步引入各部分：Modules、EAS Update、EAS Build，等你准备把原生定制写成 config plugin 时再上 CNG。不必一次性换掉整套工具链。参见渐进式采用。

一次跑通 Modules 和 CNG（只为验证，不是教程）

Expo Modules API。 用 Swift 和 Kotlin 编写模块和视图，样板代码比经典 bridge 更少。Modules 支持新架构，同时兼容旧架构。多数应用根本不需要编写原生代码，因为 Expo SDK 和社区库已经覆盖了常见场景。覆盖不到时，Modules 就是官方支持的扩展点。文档：Modules 概览。

CNG / prebuild。 原生工程在构建或调试时生成，来源是模板加上 app config 和 config plugin。升级更像是更新一个 JavaScript 依赖再加一次 npx expo prebuild --clean，而不是合并多年手工改动积累下来的原生代码差异。CNG 是可选的。已有的 React Native 应用可以继续把原生工程提交进仓库，同时照常使用 Expo 库和 EAS。文档：CNG。FAQ：eject 已废弃，改用 prebuild 和 development build（FAQ）。

EAS 简述

开源的 Expo 可以独立使用。Expo Application Services 则提供云端构建、提交、更新和工作流自动化，供你不想自己维护这套基础设施时使用。最近我们还新增了 Observability 服务。另外，截至本文写作时，我们的 Simulators 服务处于预览阶段。

  • EAS Build： 云端原生构建，带凭据管理

  • EAS Submit： 构建完成后提交到应用商店

  • EAS Update： 运行时匹配时，无需新二进制即可推送 JS 和资源修复

  • EAS Workflows： 面向 React Native 的 CI 任务（构建、更新、提交、测试）

  • EAS Hosting： 为 Expo Router 后端提供 Web 和 API 托管

  • EAS Observe：移动应用性能监控。

EAS 可以和现有 CI 配合使用，对开源技术栈来说不构成供应商锁定。Update 实现的是开放的 Updates 协议。

常见问题

Expo 应用是原生的吗？

是。React Native 会把你的 UI 映射到原生视图上。Expo 应用就是 React Native 应用，只是在其之上加了一层框架和服务。你提交到应用商店的是真正的 .ipa 和 .aab / APK 二进制包。另见 Expo 常见问题。

React Native 是原生的吗？

是。React Native 用的是原生平台视图，不是 WebView。Expo 在这一模型之上构建，并加上了框架和可选的 EAS 服务。

Expo 和 React Native 有什么区别？

React Native 是 UI 运行时。Expo 是框架（SDK、CLI、Modules、Router、prebuild）加上可选的 EAS 云服务。你几乎可以把 expo 加到任何 React Native 应用里。文档：常见问题。

React Native 和原生相比：我是不是应该分别做 iOS 和 Android 两个应用？

当共享 UI 很少、平台 API 主导路线图，或者团队无法共用同一运行时，就选双原生。当迭代速度是优先项，产品团队想要一套代码库、OTA Updates，并且随时能下沉到原生代码时，就选 Expo + React Native。

React Native（配合 Expo）有什么优势？

一套 TypeScript 代码库同时覆盖 iOS 和 Android；招聘时可以和 Web React 技能共用；通过 EAS Update 用 OTA Updates 修复 JS 和资源；需要平台深度时用 Expo Modules 写 Swift/Kotlin。对于系统首发当天就有的 API，以及组织强制要求两套技术栈的情况，双原生仍然更合适。

什么时候该用 Expo Modules，什么时候该继续用双原生？

想用 Swift 或 Kotlin 扩展一个 React Native 应用时，就用 Modules。如果根本不共享 React Native UI 层，就继续用双原生。

Expo 只有 Expo Go 吗？

不是。Expo Go 只是用来上手的沙盒。生产应用用的是 development build 和商店构建。见 Expo Go 与 development build 对比。

Expo + AI 和 Xcode 或 Android Studio + AI 相比如何？

Xcode 和 Android Studio 的 agent 只能在一个平台的工具链里帮忙。Expo + React Native 给 agent 的是一个可编辑的跨平台应用，再加上 MCP 和 Skills 做 Expo 相关的配置，然后用 EAS 构建、更新并提交到两个商店。当你深入生成的原生工程时，仍然要用 Xcode 或 Android Studio。除非你主动选择，否则不用维护两个完整应用。

AI 智能体已经能写 Swift 和 Kotlin，移动框架过时了吗？

没有。智能体降低的是敲平台代码的成本，但两个 App 的产品成本一分没少：两条发布流程、两处修行为、两处做验证，而且通常没有统一的 OTA 通道来推 JS 和资源修复。Expo + React Native 只保留一条原生发布路径，需要时通过 Expo Modules 写 Swift 和 Kotlin，运行时匹配时用 EAS Update 推送更新。共享 UI 很薄、系统新 API 必须首日支持，或者组织要求两套独立技术栈时，双原生依然是更好的选择。无论走哪条路，行为契约（测试、用户旅程、截图）都有价值，但它替代不了那个决定：一个团队维护一个 App，还是两个。

什么时候双原生依然更优？

需要在库出现之前首日接入全新的系统 API；App 以平台 UI 为主、共享逻辑很少；或者组织要求独立的原生技术栈和发布流程。

接下来看什么

来源: Expo Blog← 返回首页