Choosing between Expo and a React Native CLI setup affects how quickly your team can start, how native code enters the project, and how much build and release work you own. This guide provides a reusable decision checklist for comparing both approaches before starting a React Native app development project or changing an existing workflow.
Overview
Expo and React Native CLI are not entirely separate app platforms. Both support React Native application development, JavaScript or TypeScript code, native iOS and Android builds, navigation libraries, testing tools, and custom native integrations. The practical difference is how much of the native project is exposed and how much tooling is provided around it.
Expo supplies a managed development experience, a set of libraries for common device features, project configuration conventions, and optional cloud build and submission workflows. An Expo project can still use custom native code through development builds, config plugins, and generated native projects when the app requires them.
A React Native CLI, often called a bare or directly managed React Native setup, gives the team native ios and android projects from the beginning. That can make unusual native changes more direct, but it also means the team owns more configuration, dependency integration, signing setup, and maintenance.
The right choice is therefore less about which tool is universally better and more about the constraints of the app. A simple product with standard device features may benefit from Expo’s conventions. A product with extensive native SDK work, custom build requirements, or an existing native codebase may be more comfortable with direct native project ownership. The decision can also change over time; Expo development builds make the boundary between the two approaches less rigid than it once was.
Checklist by scenario
Choose Expo first when speed and standardization matter
- You are starting a new app. Expo gives a team a defined project path, which reduces the number of setup decisions during the first iteration.
- Your requirements use common mobile capabilities. Review the available Expo modules for notifications, camera access, location, media, authentication support, and other device features before adding third-party native packages.
- You want repeatable builds. Expo’s development-build and build-service workflows can help standardize local, preview, and production builds. Confirm that the workflow matches your organization’s credentials, approval, and CI requirements.
- Your team has limited native platform experience. Expo can reduce the amount of iOS and Android configuration needed for everyday development, while still leaving an upgrade path for native work.
- You value convention over customization. A consistent project structure is often helpful when several developers, product teams, or contractors need to work in the same codebase.
Choose direct React Native CLI ownership when native control is central
- The app depends on proprietary or unusual native SDKs. If an SDK requires repeated edits to Gradle, Xcode, native lifecycle code, or custom build phases, direct native project access may reduce friction.
- You already have native applications. A team maintaining an established iOS or Android codebase may prefer to integrate React Native into existing projects rather than reorganize around an Expo workflow.
- Your release pipeline has strict platform-specific requirements. Consider the ownership model for signing, provisioning, flavors, schemes, certificates, internal distribution, and compliance checks.
- You need custom native behavior that is not well represented by configuration. Config plugins and generated projects can cover many cases, but frequent low-level changes should be evaluated carefully before committing to a higher-level workflow.
- Your organization already has strong native tooling. Existing knowledge of Xcode, Android Studio, Gradle, CocoaPods, and native CI systems may make direct project management a reasonable choice.
Use a comparison matrix before deciding
| Concern | Expo-oriented setup | Direct CLI setup |
|---|---|---|
| Initial setup | Usually more guided and convention-driven | More native configuration from the outset |
| Native modules | Use supported modules, development builds, config plugins, or generated native projects | Add and modify native dependencies directly |
| Build workflow | Can use Expo tooling and optional build services | Usually assembled around native CI and local platform tools |
| Customization | Strong when the required changes fit the Expo workflow | Direct control over native projects and build settings |
| Maintenance | Requires alignment among Expo, React Native, and installed modules | Requires ownership of native project and dependency changes |
| Migration risk | Low when requirements remain within supported modules; plan carefully for custom native work | Lower friction for existing native projects, but more setup is owned immediately |
What to double-check
Before selecting a workflow, write down the app’s native requirements rather than relying on a general preference. For every native dependency, check whether it supports the React Native version, the Expo version used by the project, both target platforms, and the intended build workflow. A package that works in a local development environment may still require additional permissions, entitlements, manifest entries, Gradle settings, or Xcode configuration for release builds.
Test the hardest integration early. Push notifications, background tasks, Bluetooth, biometric authentication, camera processing, deep links, payment SDKs, and enterprise identity providers can expose workflow limitations sooner than ordinary screens do. Build a small proof of concept that includes installation, permissions, a development build, and a release-like build.
Also compare team responsibilities. Who owns native dependency upgrades? Who can repair a failed iOS build? Where are signing credentials stored? How will preview builds reach testers? How will CI reproduce a developer’s local build? These questions matter more than whether the first screen can be rendered quickly.
Do not use app size as a standalone deciding factor. Final size depends on the JavaScript bundle, assets, native dependencies, build configuration, and platform packaging. Measure representative release builds instead of assuming one workflow will always produce a smaller app.
For release planning, pair this decision with a React Native CI/CD workflow guide and a production readiness checklist. If performance is a concern, profile the actual release configuration using the React Native performance optimization checklist.
Common mistakes
- Treating Expo as a permanent restriction. Development builds and native project generation can support custom native requirements. Verify the exact integration before ruling Expo out.
- Treating CLI as a no-maintenance option. Direct native access provides control, but it also creates responsibility for platform upgrades, build files, signing, and dependency compatibility.
- Choosing based only on the first day. Compare the expected cost of upgrades, onboarding, CI failures, release preparation, and native debugging over the full product lifecycle.
- Adding native libraries without an ownership plan. Record required permissions, platform settings, version constraints, and release steps for every native dependency.
- Testing only in a simulator or development client. Validate physical devices, production-like builds, permissions, notifications, deep links, and offline behavior before the architecture is difficult to change.
- Using outdated terminology and migration assumptions. Workflows evolve. Confirm the current documentation and migration path for the versions your project actually uses instead of relying on older advice about ejecting or unsupported packages.
When to revisit
Revisit the Expo versus React Native CLI decision before a major planning cycle, when adding a high-risk native capability, after a React Native or Expo upgrade, and when changing the CI/CD or app-store release process. It is also worth reviewing after a team change: a project with strong native platform ownership may make different trade-offs from a small team focused mainly on shared JavaScript and TypeScript code.
Use this short review sequence:
- List every native module and platform-specific build change currently required.
- Mark which requirements are supported directly, supported through a development build or plugin, or require manual native edits.
- Run a release-like build on both platforms and record failures, manual steps, and credential dependencies.
- Ask whether the team can maintain the chosen workflow through the next upgrade cycle.
- Document the decision, assumptions, and signals that would justify switching workflows later.
For many new applications, starting with Expo is a sensible default when the requirements fit its tooling. Direct React Native CLI ownership is the clearer choice when native customization is a core product capability or an existing platform investment. The durable best practice is to validate that assumption with the app’s hardest integration and its real release process before development accelerates.
