React Native Expo vs CLI


React Native Expo vs CLI Interview with follow-up questions

1. What is the difference between React Native Expo and CLI?

Both are ways to create and run React Native apps; the difference is how much of the native side they manage for you.

  • Expo is a framework and platform on top of React Native and is Meta's officially recommended way to start a new app in 2026. create-expo-app scaffolds a project (default template includes Expo Router for file-based routing), gives you a rich SDK of native modules (camera, notifications, secure storage), the Metro-based dev server with Expo Go / dev builds, EAS Build for cloud builds, and EAS Update for over-the-air updates. You describe native config in app.json/config plugins, and the native ios/android folders are generated on demand via Prebuild (Continuous Native Generation) — so you usually don't hand-edit them.
  • React Native CLI (Community CLI) scaffolds a bare project where you own the committed ios/android folders and wire up native dependencies and builds yourself. More direct control, but more setup and maintenance.

Key gotcha to correct: it's not "Expo can't do native code." Expo's bare workflow + config plugins + Prebuild let you add custom native modules without leaving Expo, which is why the old "you must eject to do native" framing is obsolete. Practical takeaway for an interview: start with Expo by default; reach for the bare CLI only for unusual native requirements Expo's tooling can't express.

↑ Back to top

Follow-up 1

Can you explain some advantages of using Expo over CLI?

Some advantages of using Expo over React Native CLI are:

  • Simplified Development: Expo abstracts away the complexities of native app development, making it easier to get started and iterate quickly.
  • Faster Iteration: With Expo, you can quickly test your app on physical devices using the Expo Client app, eliminating the need for complex build and deployment processes.
  • Access to Expo SDK: Expo provides a wide range of pre-built components and APIs through its SDK, allowing you to easily add features like push notifications, camera access, and more to your app.
  • Over-the-Air Updates: Expo allows you to push updates to your app without requiring users to download a new version from the app store.
  • Community and Ecosystem: Expo has a vibrant community and ecosystem, with many open-source libraries and tools built specifically for Expo projects.

Follow-up 2

In what scenarios would you prefer CLI over Expo?

There are a few scenarios where you might prefer using React Native CLI over Expo:

  • Custom Native Modules: If your app requires custom native modules that are not available in the Expo SDK, you will need to use React Native CLI to add and configure those modules.
  • Advanced Configuration: If you need fine-grained control over the build process, such as modifying the native code or integrating with third-party libraries that are not supported by Expo, React Native CLI provides more flexibility.
  • Ejecting from Expo: If you initially start your project with Expo but later decide that you need more control or want to use specific native features, you can eject from Expo and continue development with React Native CLI.

Follow-up 3

How does the development process differ when using Expo vs CLI?

The development process differs when using Expo vs React Native CLI in the following ways:

  • Project Setup: With Expo, project setup is simplified and requires fewer manual configurations compared to React Native CLI.
  • Running the App: Expo provides a development server that allows you to run the app on physical devices using the Expo Client app. React Native CLI requires additional steps to build and run the app on physical devices or emulators.
  • Access to Native APIs: Expo provides a set of pre-built components and APIs through its SDK, which can be used directly in your app. React Native CLI requires additional setup and configuration to access native APIs.
  • Over-the-Air Updates: Expo allows you to push updates to your app without requiring users to download a new version from the app store. React Native CLI requires manual app updates through the app store.
  • Publishing the App: Expo provides a simplified process for publishing your app to the Expo servers. React Native CLI requires manual configuration and signing of the app for distribution.

Follow-up 4

Can you explain how the build process differs between Expo and CLI?

The build process differs between Expo and React Native CLI in the following ways:

  • Expo Build Service: Expo provides a build service that allows you to build your app in the cloud. This service handles the compilation, bundling, and signing of your app for different platforms.
  • Over-the-Air Updates: Expo allows you to push updates to your app without requiring users to download a new version from the app store. This is done by publishing updates to the Expo servers and notifying the app to fetch the latest changes.
  • Manual Build Process: React Native CLI requires manual configuration and setup for building the app. You need to configure the build settings for each platform, handle code signing, and manage the release process through the respective app stores.
  • Native Code Compilation: React Native CLI allows you to write and compile custom native code modules, which requires additional setup and configuration compared to Expo.

2. What are the main features of Expo in React Native?

Expo is the officially recommended framework for new React Native apps in 2026. Its main features:

  • Fast project setup: npx create-expo-app scaffolds a ready-to-run project; the default template ships with Expo Router (file-based routing built on React Navigation).

  • Dev experience: a Metro-based dev server with Fast Refresh, plus Expo Go (for quick prototyping) and development builds (for projects with custom native modules). Debug with React Native DevTools.

  • Rich native SDK: maintained, versioned modules for camera, notifications, location, secure storage, file system, etc. — no manual native linking.

  • Config-driven native code (CNG): you declare native settings in app.json and config plugins, and the ios/android projects are generated on demand via Prebuild. Custom native modules are supported without "ejecting."

  • EAS (Expo Application Services): EAS Build for cloud iOS/Android builds, EAS Submit for store uploads, and EAS Update for over-the-air JS updates that skip the store review for non-native changes.

The correction worth stating: the old expo-cli global tool and "managed-only" mindset are gone — you use the local expo/eas CLIs, and Expo now covers everything from prototype to full custom-native production apps.

↑ Back to top

Follow-up 1

How does Expo handle updates?

Expo provides a feature called Over-the-Air (OTA) updates, which allows you to deploy updates to your app without going through the App Store or Play Store review process. When you make changes to your app, you can use the expo publish command to publish a new version of your app to Expo's servers. Users of your app will receive a notification about the update and can choose to install it.

OTA updates in Expo work by bundling your JavaScript code and assets into a package that is hosted on Expo's servers. When a user opens your app, it checks for updates and downloads the latest package if one is available. This allows you to fix bugs and add new features to your app without requiring users to download a new version from the app store.

It's important to note that OTA updates in Expo have some limitations. For example, you cannot update native code or change the app's permissions through OTA updates. If you need to make changes to the native code or permissions, you will need to create a new build of your app and submit it to the app store for review.

Follow-up 2

Can you explain how Expo handles cross-platform compatibility?

Expo allows you to write your app once and deploy it to both iOS and Android platforms. This is achieved by providing a set of pre-built native modules that give you access to device features like camera, geolocation, and push notifications.

When you use Expo, you write your app using JavaScript and React Native components. Expo abstracts away the differences between iOS and Android platforms, so you don't have to write platform-specific code. Expo's native modules provide a consistent API that works across both platforms.

Under the hood, Expo uses React Native's bridge to communicate between JavaScript and native code. Expo's native modules are implemented using native code and are bundled with your app when you build it.

It's worth noting that while Expo provides a lot of convenience for cross-platform development, there may be cases where you need to write platform-specific code or use native libraries that are not supported by Expo. In such cases, you may need to eject from Expo and use React Native's native code capabilities.

Follow-up 3

What are some limitations of using Expo?

While Expo provides a lot of convenience for developing React Native apps, it also has some limitations:

  • Limited access to native APIs: Expo provides a set of pre-built native modules that give you access to device features like camera, geolocation, and push notifications. However, if you need to use a native API that is not supported by Expo, you may need to eject from Expo and use React Native's native code capabilities.

  • Limited control over the build process: When using Expo, you rely on Expo's build servers to create the binary files for your app. This means you have limited control over the build process and may not be able to customize certain aspects of your app, such as the app icon or the splash screen.

  • Limited support for custom native modules: While Expo provides a set of pre-built native modules, it may not cover all the functionality you need. If you need to use a custom native module that is not supported by Expo, you will need to eject from Expo and use React Native's native code capabilities.

Follow-up 4

How does Expo handle native modules?

Expo provides a set of pre-built native modules that give you access to device features like camera, geolocation, and push notifications. These native modules are implemented using native code and are bundled with your app when you build it.

When you use Expo, you can simply import and use these native modules in your JavaScript code without having to write any native code yourself. Expo abstracts away the complexities of communicating with native code and provides a consistent API that works across both iOS and Android platforms.

However, if you need to use a native module that is not supported by Expo, you will need to eject from Expo and use React Native's native code capabilities. Ejecting from Expo allows you to write your own native code and integrate it with your React Native app.

3. What are the main features of CLI in React Native?

The React Native Community CLI (@react-native-community/cli) is the tool for working with bare React Native projects, where you own the native ios/android folders. Its main features:

  • Create a project: npx @react-native-community/cli init MyApp scaffolds a bare app with the native projects committed in your repo.

  • Run on devices/simulators: npx react-native run-ios / run-android build and launch the app; under the hood it drives Xcode and Gradle.

  • Start the bundler: npx react-native start runs Metro, which bundles and serves your JS with Fast Refresh.

  • Manage native dependencies: autolinking wires native modules automatically when you install them (the old manual react-native link is deprecated/removed). On iOS you still run pod install for CocoaPods.

  • Diagnostics & upgrades: npx react-native doctor checks your environment, and the Upgrade Helper assists with version bumps.

Two honest caveats for 2026: (1) Expo is the recommended default now — the bare CLI is for teams that specifically want to own the native build setup; and (2) production builds typically happen through Xcode/Gradle or EAS Build, not a single CLI "build" command.

↑ Back to top

Follow-up 1

How does CLI handle updates?

CLI in React Native handles updates by providing commands to update the React Native version and its dependencies. You can use the react-native upgrade command to upgrade the React Native version of your project. This command will update the necessary files and dependencies to the latest version. Additionally, CLI also provides commands to update individual dependencies using the react-native link command.

Follow-up 2

Can you explain how CLI handles cross-platform compatibility?

CLI in React Native handles cross-platform compatibility by providing commands to run and build the React Native project for different platforms such as iOS and Android. The react-native run-ios command is used to run the project on iOS simulator or device, while the react-native run-android command is used to run the project on Android emulator or device. Similarly, the react-native build-ios and react-native build-android commands are used to build the project for iOS and Android platforms respectively.

Follow-up 3

What are some limitations of using CLI?

Some limitations of using CLI in React Native are:

  • Limited customization: CLI provides a set of predefined commands and configurations, which may limit the customization options for certain use cases.

  • Platform-specific commands: CLI commands for running, building, and managing the project are different for iOS and Android, which may require additional learning and effort.

  • Native module integration: CLI provides some support for integrating native modules, but it may require additional manual steps and configuration.

  • Dependency management: CLI provides commands to manage dependencies, but it may not handle complex dependency scenarios or conflicts.

Follow-up 4

How does CLI handle native modules?

CLI in React Native handles native modules by providing commands to link and unlink native modules with the React Native project. The react-native link command is used to automatically link native modules, which adds the necessary configuration files and dependencies to the project. On the other hand, the react-native unlink command is used to remove the link and configuration of a native module from the project. Additionally, CLI also provides commands to manually configure and integrate native modules if required.

4. Can you explain the process of ejecting from Expo to CLI?

Important correction first: "expo eject" no longer exists. It was removed years ago and replaced by Expo Prebuild / Continuous Native Generation (CNG). So in 2026 the right answer is "you don't eject — you generate native projects on demand," and you should explain that workflow:

  1. You usually don't need native folders at all. With CNG, Expo generates the ios/android projects from your app.json and config plugins whenever it builds. You keep working in the managed/Continuous Native Generation flow and never commit native folders.

  2. When you do need them, run npx expo prebuild. This generates the ios and android directories from your config so you can hand-edit native code — this is the modern equivalent of the old "eject."

  3. Treat prebuilt folders as disposable. The recommended pattern is to keep changes in config plugins and re-run prebuild, rather than maintaining hand-edited native folders forever (--clean regenerates them).

  4. Build with EAS. eas build runs Prebuild for you in the cloud if the native folders aren't present, so you can stay config-driven all the way to store-ready binaries.

The one-liner: "Expo doesn't eject anymore — you run expo prebuild (CNG) to generate native projects when you need raw native access, and EAS Build does this automatically during cloud builds."

↑ Back to top

Follow-up 1

What are the reasons one might want to eject from Expo to CLI?

There are several reasons why one might want to eject from Expo to a bare React Native project:

  1. Need for native code: If you need to write custom native code, you'll need to eject. Expo's managed workflow doesn't allow for custom native code.

  2. Specific packages: Some packages may not be compatible with Expo, or may require linking that can only be done in a bare project.

  3. Greater control: Ejecting gives you full control over your project configuration.

Follow-up 2

What are the challenges faced during the ejecting process?

The main challenges faced during the ejecting process are:

  1. Increased complexity: Once you eject, you'll need to manage the native iOS and Android projects yourself. This can be complex if you're not familiar with them.

  2. Loss of Expo services: Services like OTA updates, push notifications, and build services will no longer be available.

  3. Dependency issues: Some packages may have dependencies that need to be manually linked in the native projects.

Follow-up 3

What changes in the project structure after ejecting?

After ejecting, the project structure changes significantly. The main change is the addition of ios and android directories at the root of your project. These directories contain the native code for your project. You'll also lose the app.json file, as it's replaced by app.config.js. Your JavaScript code will remain in the same place.

Follow-up 4

How does the build process change after ejecting?

After ejecting, you'll need to build your app using the native build tools: Xcode for iOS and Android Studio for Android. You'll no longer be able to use expo build to build your app. Instead, you'll need to use react-native run-ios or react-native run-android to run your app on a device or emulator.

5. How do you decide whether to start a project with Expo or CLI?

In 2026 the honest default is: start with Expo unless you have a specific reason not to — it's Meta's officially recommended framework, and its Prebuild/CNG + config plugins let you add custom native code without "ejecting," so the old "Expo for simple apps, CLI for serious apps" split no longer holds.

Factors to weigh out loud:

  • Speed & DX: Expo gives you faster setup, a maintained native SDK, EAS Build (cloud builds), and EAS Update (over-the-air JS updates). Big wins for most teams.
  • Native requirements: Almost all needs are covered by Expo's SDK or config plugins. Even custom native modules work via Prebuild. You'd only consider the bare Community CLI if you need full hands-on control of the native build setup, or depend on a native SDK with no Expo-compatible plugin.
  • Team & infra: A team that already owns a native build pipeline (custom Gradle/Xcode config, existing native app to embed into) may prefer the bare CLI; a JS-focused team almost always benefits from Expo.
  • Updates & delivery: If over-the-air updates and managed builds matter, Expo/EAS is a strong pull.

Soundbite: "Default to Expo for the tooling and CNG; reach for the bare CLI only when you genuinely need to own the native build, since ejecting is no longer the trade-off it used to be."

↑ Back to top

Follow-up 1

What factors do you consider when making this decision?

  1. Project Requirements: Consider the specific requirements of the project. If the project requires access to native modules or functionality that is not available in Expo, then using the CLI might be a better choice.

  2. Third-Party Libraries: Check if the project relies on any third-party libraries or modules that are not supported by Expo. If Expo does not support the required libraries, using the CLI would be necessary.

  3. Customization: Evaluate the level of customization needed for the project. If the project requires extensive customization or native code integration, using the CLI would provide more flexibility.

  4. Publishing and Distribution: Consider how the project will be published and distributed. Expo provides an easy way to publish and share projects, while the CLI requires additional steps for building and distributing the app.

These factors will help in determining whether to choose Expo or CLI for a project.

Follow-up 2

Can you give an example of a project where you would prefer Expo over CLI and vice versa?

Sure! Let's consider two examples:

  1. Example 1: If you are building a simple mobile app that does not require access to native modules or extensive customization, Expo would be a good choice. Expo provides a lot of pre-built functionality and makes it easy to develop and test the app without having to deal with native code.

  2. Example 2: On the other hand, if you are building a complex app that requires access to native modules or extensive customization, using the CLI would be more suitable. The CLI allows for greater control and customization, making it easier to integrate native code and third-party libraries.

These examples demonstrate how the specific requirements of a project can influence the choice between Expo and CLI.

Follow-up 3

How does the project's requirements affect this decision?

The project's requirements play a crucial role in deciding whether to use Expo or CLI. If the project requires access to native modules or functionality that is not available in Expo, then using the CLI becomes necessary. Similarly, if the project relies on third-party libraries or modules that are not supported by Expo, the CLI would be a better choice. Additionally, if the project requires extensive customization or native code integration, the CLI provides more flexibility and control. On the other hand, if the project has simple requirements and does not need access to native modules or extensive customization, Expo can be a good choice as it simplifies the development process and provides pre-built functionality.

Follow-up 4

How does the team's familiarity with React Native affect this decision?

The team's familiarity with React Native can also influence the decision to use Expo or CLI. If the team is already experienced with Expo and has a good understanding of its limitations and capabilities, it might be more efficient to use Expo for the project. Expo provides a higher level of abstraction and simplifies the development process, which can be beneficial for teams with less experience in React Native. On the other hand, if the team is more experienced with React Native and has a strong understanding of native code integration and customization, using the CLI might be a better choice. The CLI provides more flexibility and control, allowing the team to leverage their expertise in React Native to build a more customized and optimized app.

6. How do you ship over-the-air (OTA) updates in React Native, and what changed with CodePush?

Because most RN code is JS, you can push JS/asset updates without an App Store/Play review — only native changes need a store release. Interviewers want you to know the current tooling, not CodePush.

  • Microsoft App Center / CodePush has been retired, so it's no longer the recommended path.
  • The modern standard is EAS Update (Expo's hosted service, works with bare and managed apps), built around expo-updates. You publish an update to a channel/branch and clients fetch it on next launch.

Key correctness points: OTA updates can only change the JS bundle and assets — anything touching native code (new native module, SDK bump, permissions) still requires a new binary. You must keep the runtime/native version compatible with the update (runtime versions/channels exist precisely to prevent shipping JS that calls native APIs the installed binary doesn't have). Also respect Apple/Google policy: OTA is for fixes and improvements, not for materially changing the app's purpose.

↑ Back to top

Live mock interview

Mock interview: React Native Expo vs CLI

Intermediate ~5 min Your own free AI key

Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.