Expo vs bare React Native: what changes before launch
A practical guide to choosing Expo, prebuild, or bare React Native when a mobile app is moving from prototype to launch.
Expo is a launch accelerator when the constraints fit
Expo can be an excellent path for a React Native V1. It simplifies setup, standardizes common native capabilities, supports EAS builds, and lets teams move quickly without owning every native project detail from day one.
But Expo is not a promise that native complexity disappears. Before launch, teams need to understand whether their app can stay comfortably in Expo managed workflows, needs prebuild/config plugins, or should be treated as a bare React Native app.
The wrong choice is not “Expo” or “bare.” The wrong choice is discovering the constraint after the release plan is already sold.
When Expo managed is a good fit
Expo managed is often right when the app uses standard product flows:
- onboarding and auth;
- forms and API integration;
- camera or media with supported modules;
- push notifications with normal requirements;
- maps or location within common patterns;
- standard app icons, splash screens, and updates;
- no unusual native SDK ownership.
For many founder-led V1s, this is enough. It keeps the team focused on product scope, QA, and release rather than native project plumbing.
When prebuild enters the picture
Prebuild becomes relevant when the app needs native configuration that Expo can generate but not hide completely. Config plugins, permissions, custom native settings, and dependency-specific setup can all require more care.
Prebuild is not bad. It is a sign that native assumptions should be documented. The team should know which files are generated, which config plugins are responsible for changes, and how builds are reproduced.
If nobody understands why a permission, entitlement, or Gradle setting exists, launch risk increases.
When bare React Native may be safer
Bare React Native may be appropriate when the project needs deeper native control:
- custom Swift/Kotlin modules;
- platform SDKs without good Expo support;
- complex background behavior;
- advanced Bluetooth/audio/video/device integration;
- heavy native customization;
- an existing native codebase;
- a team that already owns iOS and Android projects.
Bare gives control, but it also gives responsibility. The team must manage native dependencies, build settings, signing, and platform divergence more directly.
The decision should be feature-led
Do not choose the workflow based on taste. Choose based on the features required for launch.
For each mobile feature, ask:
- Does Expo support it cleanly?
- Does it need a config plugin?
- Does it require custom native code?
- Does it create store review or permission risk?
- Can the V1 simplify it?
- Who owns the native code after handover?
The answer should be written before implementation. This protects the future team from inheriting mysterious native decisions.
Watch for release blockers
Common Expo/React Native launch blockers include mismatched SDK versions, stale config plugins, inconsistent EAS profiles, missing environment variables, permissions that do not match store copy, and native dependencies that work in development but fail in release builds.
A React Native delivery pass should identify these issues before the final week. The goal is not to argue about tooling. The goal is to make iOS and Android builds predictable.
Handover matters
If the team plans to hire later, document the workflow clearly:
- Expo SDK and React Native versions;
- EAS profiles;
- config plugins;
- generated native project assumptions;
- environment variables;
- release commands;
- native module risks;
- known platform differences.
Expo can make handover easier, but only if the decisions are visible.
A practical rule
Use Expo managed when the V1 fits standard mobile capabilities and speed matters. Use prebuild when native configuration is needed but can be generated and controlled. Use bare when native behavior is central enough that owning iOS and Android projects is the safer long-term path.
If you are unsure, map native risk before choosing. Get a 24h risk reply with your feature list, target launch date, and native dependencies, and Stateless will tell you where Expo is enough and where native ownership needs planning.