Blog · Cross-platform
Expo or bare React Native in 2026
The old framing was “Expo for beginners, bare React Native for real apps”. It has been wrong for a while and in 2026 it is backwards: Expo is the way React Native’s own documentation tells you to start, and most of what people thought they lost by using it is no longer lost. Here is the decision as a short tree.
1. What Expo actually is now
React Native, plus three things:
- Prebuild. The
iosandandroidfolders are generated from your config rather than hand-maintained. You can still open them in Xcode or Android Studio, and since SDK 57 prebuild clears and regenerates them by default, so they never drift from the config. - Config plugins. Native settings (permissions, entitlements, build properties) live in your app config and are applied at prebuild, instead of in files you edit by hand and forget.
- Development builds. Your own native app with the developer tools inside it, which replaced “Expo Go” as the way to run an app with custom native code. Expo’s own blog explains the two better than anyone, so this post will not.
You write native modules when you need them. You use any React Native library. The “Expo cannot do X” list from a few years ago is mostly empty.
2. The tree
- Are you adding React Native to an existing native iOS or Android app? Yes: bare. Expo’s generation assumes it owns the native project. No: continue.
- Do you already run a native build pipeline you must keep (custom Xcode configurations, your own CI with native caching, strict release tooling)? Yes: bare, or Expo with prebuild run once and the folders committed. No: continue.
- Everything else: Expo.
That is the whole tree. The second branch is the one people overestimate: most teams who think they need a custom native pipeline need a config plugin.
3. What changed the answer recently
- The New Architecture is mandatory. From SDK 55 (February 2026) the legacy React Native architecture cannot be used in an Expo project. That removed the biggest source of “it works in Expo but not with this library” confusion, because every library that still ships supports the new one.
- Hermes V1 by default. SDK 56 made the new engine the default; Expo reports Android cold starts around 40% faster. The performance objection to “the Expo way” is gone.
- System controls through Expo. Native tabs, the Liquid Glass material on iOS 26, Compose primitives on Android: these arrive through Expo packages first. Bare projects can use them too, but the path is longer.
4. The honest costs
Expo adds a layer, and a layer is something to learn: prebuild, plugins, the SDK release cadence (three a year, each a bump). An Expo project also needs a development build for anything with custom native code, which means a Mac for the iPhone build like any React Native project. None of this is hidden, but none of it is free either.
Where to start
New app, no existing native code: create it with Expo, make a development build on day one, and never touch the generated native folders by hand. If step 1 or 2 of the tree is you, go bare and know why.
Apps exported from the App Builder are Expo projects for this reason: a normal, current React Native project your coding agent can keep building on, with the native edge handled through Expo’s own packages and a config you can read.