The one-sentence answer
React Native is an open-source framework (from Meta) that lets you write an app in JavaScript/TypeScript and render it to real native iOS and Android UI — not a webview. Expo is a company and an open-source platform that wraps React Native with the boring-but-essential infrastructure: project setup, a huge library of native modules, over-the-air updates, and cloud build servers.
You do not choose one instead of the other. You choose whether to let Expo handle the plumbing (recommended for almost everyone) or to manage the native build yourself.
Expo vs bare React Native, side by side
| Dimension | With Expo | Bare React Native |
|---|---|---|
| What it is | A toolkit + build service on top of React Native | The core framework that renders native UI from JS |
| Native build setup | None — no Xcode/Android Studio needed to start | You configure and maintain ios/ and android/ yourself |
| Over-the-air updates | Built in (EAS Update) | DIY (CodePush or a custom setup) |
| Cloud builds | EAS Build — no local Mac required for iOS | You run local builds or wire up your own CI |
| Native modules | Large built-in library + any RN module via prebuild | Anything — full native access from day one |
| Best for | Almost every new app in 2026 | Custom native work or embedding in an existing app |
Notice there’s no “Expo can’t do X” row anymore. The old objection — “Expo blocks custom native code” — died with the ejection model. Since Expo’s Continuous Native Generation (prebuild), you can drop into the native folders whenever you want and still keep everything Expo gives you.
When bare React Native is actually the right call
Expo is the default in 2026. The honest exceptions where you might skip it:
- You’re embedding React Native into an existing native app. A brownfield iOS/Android app that adds a few RN screens is a bare-workflow scenario.
- You need a native module with deep custom build configthat isn’t expressible as an Expo config plugin — rare, and shrinking every release.
- Your org already has a mature native CI/CD pipelineand doesn’t want EAS in the mix.
For a brand-new standalone app — a startup MVP, a side project, an indie product — none of those apply. Start with Expo.
What this means if you’re building with AI
When an AI app builder generates a “React Native app,” it almost always means a React Native app scaffolded with Expo— because Expo is what makes the output installable on a real phone without a native toolchain. That’s the right default: you get standard React Native code you fully own, plus Expo’s device preview and build path so you can actually run it.
ShipNative generates exactly this: a complete Expo + React Native project with navigation, screens, and data from a single description — previewable on your device in minutes, and exportable as a normal Expo project you can open in any editor. You’re not locked into a proprietary format; you get the same code you’d write by hand, minus the setup week.
The verdict
Use Expo. It isReact Native, with the painful parts removed and an escape hatch to the native layer whenever you need it. “Bare React Native” is a specialist choice for embedding and deep native work — not the starting point it used to be.
Want to see it in practice? Describe your app at shipnative.dev and get a running Expo + React Native app on your phone in minutes — then read React Native authentication for the next piece most apps need.