Expo vs Bare React Native: Which Workflow Should Your Team Choose?

Expo provides tools for building, updating, and distributing React Native apps. Compare those tools with the native project control and build infrastructure your team needs, including whether you will generate or maintain the iOS and Android directories.

What the Expo Toolchain Provides

Expo is not a simplified version of React Native. It is a full-featured toolchain built on top of React Native that provides:

• Expo SDK: a set of well-maintained native modules for common capabilities (camera, location, notifications, filesystem, biometrics, and more)
• Expo Go: a development client for fast iteration without building natively
• EAS Build: cloud builds for iOS and Android without needing a Mac for iOS builds
• EAS Submit: automated app store submission
• EAS Update: over-the-air JS bundle updates without a store release
• Continuous Native Generation (CNG): generate the native iOS and Android project from your app.json config on demand

The old distinction between "managed" Expo (no native code allowed) and "bare" React Native (full native access) is largely obsolete. CNG lets you stay in the Expo workflow while writing any native code you need via config plugins — the native iOS and Android directories are generated when needed and not committed to source control.

Build and Maintenance Trade-offs

Build Infrastructure

With Expo, EAS Build gives you cloud builds for both iOS and Android. You do not need a Mac to ship an iOS app, and you do not need to manage Xcode or Android Studio configuration on your CI server.

With bare React Native, you own your build pipeline. If you are on a team with existing Fastlane or Bitrise configuration, this might be fine. If you are starting from scratch, setting up iOS provisioning, certificates, build signing, and Android keystore management from nothing is a multi-day project before you have shipped a single feature.

Native Code Access

Expo supports several ways to integrate native functionality:

• Config plugins: modify the native project during expo prebuild without touching the native directories manually
• Custom dev clients: a custom Expo Go-equivalent that includes your native modules
• Bare workflow via expo prebuild --clean: eject to a full bare project any time

If you need a native module that is not in the Expo SDK, the Expo Modules API lets you write it in Swift and Kotlin and integrate it cleanly.

Over-the-Air Updates

EAS Update lets you push JavaScript bundle updates to users without going through the app store review process. This is significant for fixing bugs and shipping small features fast.

Bare React Native can use EAS Update too — it is not Expo-exclusive. But setup is simpler in the Expo workflow.

Vendor Lock-In

The concern about being locked into Expo is real but often overstated. You can eject from Expo's managed workflow to a full bare project at any point. The output is a standard React Native project.

The actual lock-in is in EAS Build and EAS Submit, which are Expo's cloud services. These have per-build pricing above the free tier. If you move to self-hosted CI, budget for reproducing signing, provisioning, build configuration, and distribution steps.

Expo vs Bare React Native: When to Choose Each

Start with Expo if:

• You are building a new project and do not have an existing native infrastructure
• Your team is primarily JavaScript/TypeScript engineers without deep iOS or Android experience
• You want OTA updates without a store release cycle
• You want iOS builds without owning a Mac
• You want to reduce the amount of build infrastructure needed for an MVP
• You have standard native requirements that the Expo SDK covers

Choose or stay with bare React Native if:

• You have an existing native codebase with significant Objective-C or Java code
• You need to integrate with native SDKs that have no config plugin and you need deep control over the native project structure
• Your organization requires self-hosted builds for compliance or security reasons and you cannot use a cloud build service
• You have a mobile platform team with strong iOS/Android native expertise who prefer direct native project control

The Practical Recommendation

For a new app with a JavaScript-first team, test an Expo development build with the native integrations you expect to use. That prototype can reveal whether the toolchain fits your requirements.

For a team inheriting a large bare React Native codebase: do not migrate to Expo just to migrate. Adopt EAS Build incrementally if your build pipeline is painful, and adopt EAS Update if you want OTA updates. Expo's tools are modular.

App Store Submission with EAS Submit

EAS Submit automates the store submission steps that are tedious and error-prone manually:

• iOS: uploading the .ipa, setting the build metadata, submitting to TestFlight or production
• Android: uploading the .aab, configuring release tracks (internal, alpha, beta, production)

It is configured via eas.json and triggered with a single command. Compare the time saved with the plan cost and your current release workflow.

Discuss a React Native workflow with LinkIT.