Expo vs Bare React Native in 2026: Which Should You Start With?

A few years ago, "Expo vs React Native" was a real fork in the road. Expo was the easy start with a ceiling, and "ejecting" to bare React Native was the price of anything serious. Teams still choose based on that old picture, and it costs them weeks.

In 2026 the question is different. Expo isn't an alternative to React Native; it's the framework the React Native docs recommend for new apps, and it no longer limits what native code you can write. I've shipped apps on both Expo and bare workflows, including native modules in Swift and Kotlin, and here's how I'd decide today.

Key takeaways

• Expo is a framework on top of React Native, not a separate technology. The React Native docs recommend starting new apps with a framework, and Expo is the main one.
• You can write any native code in an Expo app: config plugins edit the native projects, and the Expo Modules API lets you write Swift and Kotlin modules.
• "Bare" now mostly means you commit and hand-maintain the ios and android folders. Expo's alternative, Continuous Native Generation, regenerates them from your config.
• Start with Expo unless you're adding React Native to an existing native app, or a team process requires hand-managed native projects.
• Expo's paid services are optional. You can use Expo's SDK and tooling with your own CI, and only pay for EAS Build, Submit or Update if they save you time.

What "Expo" and "bare" mean in 2026

The vocabulary has shifted, which is half the confusion.

• Expo (the framework): the SDK of native modules (camera, notifications, file system and many more), the CLI, Expo Router for navigation, and tooling around development builds. It's open source and free.
• EAS (Expo Application Services): cloud services for building, submitting and updating apps. Optional, with a free tier and paid plans.
• Expo Go: a sandbox app for trying things quickly. It only contains Expo's built-in modules, so real projects use development builds instead: your own debug app with your own native code.
• Bare React Native: a project where the ios and android folders are checked in and edited directly. You can still use Expo modules and EAS in a bare project.
• Continuous Native Generation (CNG): Expo's approach where native folders are generated from app.json and config plugins (npx expo prebuild), so upgrades regenerate them instead of patching by hand.

So the real choice isn't "Expo or React Native". It's "generated native projects (CNG) or hand-maintained native projects (bare)".

The comparison that matters

Myths that still cost teams time

When bare React Native still makes sense

Bare is the right call in a few specific situations:

1. Brownfield apps. You're adding React Native screens to an existing Swift or Kotlin app. You'll integrate React Native into that native project rather than generate it (Expo has brownfield tooling too, but the host app stays native).
2. Native projects that are products in themselves. Large custom native layers, unusual build targets or extensions that you'd rather edit in Xcode than express as config plugins.
3. Organisational rules. Some companies require native projects to be reviewed and built like any other native app, with their own signing and CI.

Even then, you can use Expo's SDK modules and EAS services inside a bare project. It's a spectrum, not a wall.

When Expo is the clear choice

• You're starting a new app and want to ship to both stores quickly.
• Your team is stronger in JavaScript and TypeScript than in Xcode and Gradle.
• You want predictable upgrades: Expo ships around three SDK releases a year, each pinned to a tested React Native version.
• You want over-the-air fixes, file-based routing, and web support without assembling them yourself.

From the field: I've shipped on both workflows and written native modules in Swift and Kotlin when JavaScript alone wouldn't do. My takeaway: needing native code is no longer a reason to leave Expo. Writing that module with the Expo Modules API is usually less ceremony than maintaining a hand-edited native project through every upgrade.

A decision checklist

Answer these in order. The first "yes" decides it.

1. Are you adding React Native to an existing native app? Brownfield, native host.
2. Does your company require hand-maintained native projects? Bare (with Expo modules where useful).
3. Otherwise: Expo with development builds and CNG. Add config plugins and Expo modules as native needs appear.

Getting started with Expo in five minutes

npx create-expo-app@latest my-app
cd my-app
npx expo start

Scan the QR code with Expo Go to see the app on your phone, or press i or a for a simulator. As soon as you add a library with its own native code, switch to a development build (npx expo run:ios, npx expo run:android or an EAS development build), which is your own app with your native code inside.

Expo vs React Native CLI: which is better?

The React Native documentation recommends starting new apps with a framework, and Expo is the main one. The React Native Community CLI (npx @react-native-community/cli@latest init) still creates a plain project with committed ios and android folders and no framework, which suits teams with established native tooling or brownfield apps. "Expo vs React Native" is a slightly misleading question: an Expo app is a React Native app, with tooling, a module library and optional cloud services on top.

Expo Go vs development builds

Expo Go is a ready-made app from the stores that runs your JavaScript, which is great for learning and quick experiments. It only contains the native modules Expo bundles into it, supports one SDK version at a time and, since September 2026, asks you to sign in. A development build is your own app with your own native code, and it's what real projects use day to day.

Moving between them

From bare to Expo: install Expo in the existing project (npx install-expo-modules), start using Expo modules, then move native customisations into config plugins until you can delete the native folders and regenerate them. Do it gradually, one change per release.

From Expo to bare: run npx expo prebuild, commit the generated ios and android folders, and maintain them by hand from then on. It's reversible in principle, but you lose the easy upgrades.

FAQ

Is Expo good enough for production apps?

Yes. Expo is used for large production apps, supports any native library through development builds, and gives you production tooling for builds, store submission and over-the-air updates. The old "Expo is for prototypes" reputation dates from before development builds and config plugins existed.

Can I use native code with Expo?

Yes. Third-party native libraries work in development builds, config plugins can modify the native projects during prebuild, and the Expo Modules API lets you write your own modules in Swift and Kotlin. Expo Go is the only environment limited to Expo's built-in modules.

Is Expo free?

The Expo framework, SDK and CLI are open source and free. EAS Build, Submit and Update are paid services with a free tier. You can skip EAS entirely and build on your own machine or CI.

What happened to "ejecting" from Expo?

It was replaced by prebuild and Continuous Native Generation. Instead of a one-way eject, you generate native folders from config when you need them, and you choose whether to commit and hand-maintain them (bare) or keep regenerating them (CNG).

Next steps

If you're starting a new app, or you're stuck maintaining a bare project that fights every upgrade, I can help you choose a setup and move to it safely. Get in touch, or see how I work as a React Native developer.

Sources

• Get started with React Native (frameworks), React Native docs
• Continuous Native Generation, Expo
• Config plugins, Expo
• Expo Modules API overview, Expo
• Development builds, Expo
• React Native Upgrade Helper, React Native Community