Decision Guide
Choose Expo when the product needs real mobile distribution and shared React code is the fastest path to users.
Choose Expo
| Product shape | Why Expo fits |
|---|---|
| Cross-platform CRUD, content, commerce, learning, fitness, or marketplace app | Shared app code, native distribution, and enough native APIs through Expo SDK/community packages |
| Solo-dev mobile app | CNG, config plugins, and EAS reduce native project maintenance |
| React-heavy team | Existing component, state, TypeScript, API, and testing knowledge transfers well |
| App that needs OTA fixes | EAS Update can ship compatible JavaScript and asset changes faster than store review |
| Android and iOS launch both matter | One routing and UI architecture can cover both platforms |
Avoid Expo
| Constraint | Better default |
|---|---|
| Android-only app with heavy platform APIs | Android Kotlin Compose |
| App mainly needs content pages, forms, and shareable URLs | PWA or web app first |
| Deep custom native UI, long-running services, or unsupported platform SDKs | Native Android/iOS, or budget time for custom modules |
| Store policy depends on sensitive permissions | Prove policy eligibility before choosing the stack |
| Team cannot test real builds | Do not ship mobile; use web or defer release |
Default Recommendation
Use Expo for new cross-platform product apps unless one of these is true:
- The app is Android-first and the Android native APIs are central to the product.
- The app can ship as web and native distribution is not required.
- The first release depends on unsupported native SDKs or restricted permissions.
- The release team cannot access Apple Developer, Google Play Console, or at least one device/tester path.
The Native Boundary Test
Before committing to Expo, list every native requirement:
Native requirement: <camera, background audio, BLE, SMS, health data, payments>
Expo SDK module exists: <yes/no/link>
Community library exists: <yes/no/link>
Config plugin exists: <yes/no/link>
Development build required: <yes/no>
Store policy risk: <none/low/high>
Fallback if unavailable: <plan>If more than one core feature has no for module/plugin support, Expo can still work, but the project is no longer a simple shared-code mobile app.
Tip: Native module risk is not a reason to avoid Expo automatically. It is a reason to prototype the native feature first, before building the rest of the product.