Source: https://docs.expo.dev/more/expo-cli

Hide navigation

Search

Ctrl K

Home Guides EAS Reference Learn

Archive Expo Snack Discord and Forums Newsletter

Expo CLI

Edit page

Copy page

The Expo CLI is a command-line tool that is the primary interface between a developer and other Expo tools.

Edit page

Copy page

---

The expo package provides a small and powerful CLI tool npx expo which is designed to keep you moving fast during app development.

Highlights

---

• Start a server for developing your app: npx expo start.
• Generate the native Android and iOS directories for your project: npx expo prebuild.
• Build and run the native apps locally: npx expo run:ios and npx expo run:android.
• Install and update packages that work with the version of react-native in your project: npx expo install package-name.
• npx expo can be used with npx react-native simultaneously.

To view a list of available commands in Expo CLI, run the following in your project:

Terminal

Copy

- npx expo -h

You can also run yarn expo -h if you prefer to use yarn as the package manager.

The output should look something like below:

Usage $ npx expo <command> Commands start, export run:ios, run:android, prebuild install, customize, config login, logout, whoami, register Options --version, -v Version number --help, -h Usage info

You can run any command with the --help or -h flag to learn more about it:

Terminal

Copy

- npx expo login -h

Installation

---

Expo CLI is included in the expo package. You can install it with npm or yarn:

Terminal

Copy

- yarn add expo

Projects that are not using Expo Prebuild (also referred to as Bare projects) will need to perform additional setup to ensure all custom Expo bundling features work: Metro: Bare workflow setup .

Develop

---

Start a development server to work on your project by running:

Terminal

Copy

- npx expo start

You can also run npx expo as an alias to npx expo start.

This command starts a server on http://localhost:8081 that a client can use to interact with the bundler. The default bundler is Metro .

The UI that shows up in the process is referred to as the Terminal UI. It contains a QR code (for the dev server URL) and a list of keyboard shortcuts you can press:

| Keyboard shortcut | Description | | --- | --- | | A | Open the project on a connected Android device. | | Shift + A | Select an Android device or emulator to open. | | I | Open the project in an iOS Simulator. | | Shift + I | Select an iOS Simulator to open. | | W | Open the project in a web browser. This may require webpack to be installed in your project. | | R | Reload the app on any connected device. | | S | Switch the launch target between Expo Go and development builds. | | M | Open the dev menu on any connected native device (web not supported). | | Shift + M | Choose more commands to trigger on connected devices. <br>This includes toggling the performance monitor, opening the element inspector, reloading the device, and opening the dev menu. | | J | Open React Native DevTools for any connected device that is using Hermes as the JavaScript engine. Learn more<br>. | | O | Open project code in your editor. This can be configured with the EXPO_EDITOR and EDITOR environment variables<br>. | | E | Show the development server URL as a QR code in the terminal. | | ? | Show all Terminal UI commands. |

Launch target

The npx expo start command automatically launches the app in a development build if expo-dev-client is installed in the project. Otherwise, it launches the app in Expo Go.

Alternatively, you can force the launch target by passing the following flags to the command:

• --dev-client: Always launch the app in a development build.
• --go: Always launch the app in Expo Go.

You can also switch the launch target during runtime by pressing S in the Terminal UI. The run commands also use --dev-client after compiling the development build, by default.

Server URL

By default, the project is served over a LAN connection. You can change this behavior to localhost-only by using the flag npx expo start --localhost.

Other available options are:

• --port: Port to start the dev server on (does not apply to webpack or tunnel URLs ). Use --port 0 to automatically use the first available port. Default: 8081.
• --https: (Deprecated in favor of --tunnel) Start the dev server using a secure origin. This is currently only supported on web.

You can force the URL to be any value with the EXPO_PACKAGER_PROXY_URL environment variable. For example:

Terminal

- export EXPO_PACKAGER_PROXY_URL=http://expo.dev

- npx expo start

Will open apps to: exp://expo.dev:80 (the :80 is a temporary workaround for Android WebSockets).

Tunneling

Restrictive network conditions (common for public Wi-Fi), firewalls (common for Windows users), or Emulator misconfiguration can make it difficult to connect a remote device to your dev server over lan/localhost.

Sometimes it's easier to connect to a dev server over a proxy URL that's accessible from any device with internet access, this is referred to as tunneling. npx expo start provides built-in support for tunneling via ngrok .

To enable tunneling, first install @expo/ngrok:

Terminal

Copy

- npm i -g @expo/ngrok

Then run the following to start your dev server from a tunnel URL:

Terminal

Copy

- npx expo start --tunnel

This will serve your app from a public URL like: https://xxxxxxx.bacon.19000.exp.direct:80.

Use the EXPO_TUNNEL_SUBDOMAIN environment variable to experimentally set the subdomain for the tunnel URL. This is useful for testing universal links on iOS. This may cause unexpected issues with expo-linking and Expo Go. Select the exact subdomain to use by passing a string value that is not one of: true, false, 1, 0.

Drawbacks

• Tunneling is slower than local connections because requests must be forwarded to a public URL.
• Tunnel URLs are public and can be accessed by any device with a network connection. Expo CLI mitigates the risk of exposure by adding entropy to the beginning of the URL. Entropy can be reset by clearing the .expo directory in your project.
• Tunnels require a network connection on both devices, meaning this feature cannot be used with the --offline flag.

Tunneling requires a third-party hosting service, this means it may sometimes experience intermittent issues like ngrok tunnel took too long to connect or Tunnel connection has been closed. This is often related to intermittent connection problems with the Ngrok servers.... Be sure to check for Ngrok outages before reporting an issue. Some Windows users have also reported needing to modify their antivirus settings to allow Ngrok to work correctly.

Offline

You can develop without a network connection by using the --offline flag:

Terminal

Copy

- npx expo start --offline

Offline will prevent the CLI from making network requests. If you don't use the flag and your computer has no internet connection, then offline support will automatically be enabled, it will just take a bit longer to verify the reachability.

Expo CLI makes network requests to sign manifests with your user credentials to ensure sensitive information is sandboxed in reusable runtimes like Expo Go.

.expo directory

When you start the development server in a project for the first time, a .expo directory is created at the root of that project. It contains two files:

• devices.json: Contains information about devices that have opened this project recently.
• settings.json: Contains information about server configuration that is used to serve the project's manifest.

Both of these files have information that is specific to your local computer. This is the reason why .expo directory is included in the .gitignore file, by default, when a new project is created. It is not meant to be shared with other developers.

Building

---

A React Native app consists of two parts: a native runtime (compiling ), and static files like JavaScript bundles and assets (exporting ). Expo CLI provides commands for performing both tasks.

Compiling

You can compile your app locally with the run commands:

Terminal

# Build for iOS

- npx expo run:ios

# Build for Android

- npx expo run:android

Highlights

• Build directly on connected devices with no global side effects using the --device flag. Supports locked devices, letting you retry instantly instead of needing to rebuild.
• Automatically codesign iOS apps for development from the CLI without having to open Xcode.
• Smart log parsing shows warnings and errors from your project source code, unlike Xcode which surfaces hundreds of benign warnings from your node modules.
• Fatal errors causing your app to crash will be surfaced in the terminal preventing the need to reproduce in Xcode.

npx expo run:ios can only be run on a Mac, and Xcode must be installed. You can build the app in the cloud from any computer using eas build -p ios. Similarly, npx expo run:android requires Android Studio and Java to be installed and configured on your computer.

Building locally is useful for developing native modules and debugging complex native issues . Building remotely with eas build is a much more resilient option due to the pre-configured cloud environment.

If your project does not have the corresponding native directories, the npx expo prebuild command will run once to generate the respective directory before building.

For example, if your project does not have an ios directory in the root of your project, then npx expo run:ios will first run npx expo prebuild -p ios before compiling your app. For more information on this process, see Expo Prebuild .

Cross-platform arguments

• --no-build-cache: Clear the native cache before building. On iOS, this is the derived data directory. Cache clearing is useful for profiling your build times.
• --no-install: Skip installing dependencies. On iOS, this will also skip running npx pod-install if the dependencies field in the project's package.json has changed.
• --no-bundler: Skip starting the dev server. Enabled automatically if the dev server is already serving the app from a different process.
• -d, --device [device]: Device name or ID to build the app on. You can pass --device without arguments to select a device from a list of available options. This supports connected devices as well as virtual devices.
• -p, --port <port>: Port to start the development server. Default: 8081. This is only relevant for development builds. Production builds will export the project and embed the files in the native binary before installing them on a device.
• --binary <path>: File path to the binary to install on the device. When this is provided, the build process will be skipped and the binary will attempt to be installed directly. If the binary was not built for the correct device, for example, it is built for the simulator or installed on the device, then the command will fail.

Compiling Android

Android apps can have multiple different variants which are defined in the project's build.gradle file. Variants can be selected with the --variant flag:

debug variant

Use the debug variant for a debug build:

Terminal

Copy

- npx expo run:android --variant debug

debugOptimized variant

debugOptimized is available in SDK 54 and later.

Use the debugOptimized variant for faster development with performance close to release builds while keeping the overall build in a debug-friendly mode:

Terminal

Copy

- npx expo run:android --variant debugOptimized

When using this variant, keep the following in mind:

• Optimizes C++ libraries as in release builds, improving runtime performance

• In EAS Build, use a matching Gradle command like :app:assembleDebugOptimized in eas.json

• Limitation: C++ debugging is disabled and C++ crashes may have less readable stack traces

release variant

You can compile the Android app for production by running:

Terminal

Copy

- npx expo run:android --variant release

This build is not automatically code-signed for submission to the Google Play Store. This command should be used to test bugs that may only show up in production builds. To generate a production build that is code signed for the Play Store, we recommend using EAS Build .

Debugging native Android project

You can debug the native Android project using native debugging tools by opening the android directory in Android Studio:

Terminal

Copy

- open -a /Applications/Android Studio.app android

If you have a customized Android project using different product flavors, you can configure both the flavor and application ID using the --variant and --app-id flags:

Terminal

Copy

- npx expo run:android --variant freeDebug --app-id dev.expo.myapp.free

For more information, see the Local builds using Android product flavors guide.

Compiling iOS

An iOS app can have multiple schemes for representing different sub-apps like App Clips, watchOS apps, Safari Extensions, and so on. By default, npx expo run:ios will choose the scheme for your iOS app. You can pick a custom scheme with the --scheme <my-scheme> argument. If you pass in the --scheme argument alone, then Expo CLI will prompt you to choose a scheme from the list of available options in your Xcode project.

The scheme you select will filter out which --device options show up in the selection prompt, for example, selecting an Apple TV scheme will only show available Apple TV devices.

You can compile an iOS app for production by running:

Terminal

Copy

- npx expo run:ios --configuration Release

This build is not automatically code signed for submission to the Apple App Store. npx expo run:ios should mostly be used to test bugs that only show up in production builds. Native code signing requires several network requests and is prone to many different types of errors from the Apple servers. To generate a production build that is code signed for the App Store, we recommend using EAS Build .

When you compile your app onto a Simulator, the Simulator's native error logs will be piped to the Expo CLI process in the terminal. This is useful for quickly seeing bugs that may cause a fatal error. For example, missing permission messages. Error piping is not available for physical iOS devices.

You can debug using lldb and all of the native Apple debugging tools by opening the project in Xcode and rebuilding from Xcode:

Terminal

Copy

- xed ios

Building from Xcode is useful because you can set native breakpoints and profile any part of the application. Be sure to track changes in source control (git) in case you need to regenerate the native app with npx expo prebuild -p ios --clean.

iOS development signing

If you want to see how your app will run on your device, all you have to do is connect it, run npx expo run:ios --device, and select your connected device.

Expo CLI will automatically sign the device for development, install the app, and launch it.

If you don't have any developer profiles setup on your computer then you'll need to set them up manually outside of Expo CLI by following this guide: Setup Xcode signing .

Exporting

You can export the JavaScript and assets for your app using Metro bundler by running:

Terminal

Copy

- npx expo export

This is done automatically when using eas update or when compiling the native runtime. The export command works similar to most web frameworks:

• A bundler transpiles and bundles your application code for production environments, stripping all code guarded by the __DEV__ boolean.
• All static files are copied into a static dist directory which can be served from a static host.
• Contents of the public directory are copied into the dist directory as-is.

The following options are provided:

• --platform <platform>: Choose the platform to compile for: 'ios', 'android', 'all'. Default: all. 'web' is also available if configured in the app config. For more information, see Customizing Metro .
• --dev: Bundle for development environments without minifying code or stripping the __DEV__ boolean.
• --output-dir <dir>: The directory to export the static files to. Default: dist
• --max-workers <number>: Maximum number of tasks to allow the bundler to spawn. Setting this to 0 will run all transpilation on the same process, meaning you can easily debug Babel transpilation.
• -c, --clear: Clear the bundler cache before exporting.
• --no-minify: Skip minifying JavaScript and CSS assets.
• --no-bytecode: Skip generating Hermes bytecode for native platforms. Only use this for analyzing bundle sizes and never ship UTF-8 bundles to native platforms as this will lead to drastically longer startup times.
• --no-ssg: Skip exporting static HTML files for web routes. This option only generates server code inside the dist directory. Useful for API routes .

Hosting with sub-paths

Experimental functionality.

You can configure the prefix for static assets by setting the experiments.baseUrl field in your app config :

app.json

Copy

{ "expo": { "experiments": { "baseUrl": "/my-root" } } }

This will export the website with all resources prefixed with /my-root. For example, an image at assets/image.png will be expected to be hosted at /my-root/assets/image.png. The actual file will be located in the same file system location as the entire directory is expected to be hosted at /my-root on the server.

Expo Router has built-in support for baseUrl. When using the Link and router APIs, the baseUrl will be automatically prepended to the URL.

app/blog/index.tsx

Copy

import { Link } from 'expo-router'; export default function Blog() { return <Link href="/blog/123">Go to blog post</Link>; }

This will export to the following:

Output HTML

Copy

<a href="/my-root/blog/123">Go to blog post</a>

If you use <a>, React Navigation, or the Linking API directly, you'll need to manually prepend the baseUrl.

The baseUrl functionality is production-only and must be set before exporting the website. If you change the value, you must re-export the website.

Images and other assets will work automatically if you require or import them. If you directly reference a resource URL then you will need to append the baseUrl manually.

app/index.tsx

Copy

import { Image } from 'expo-image'; export default function Blog() { return <Image source={require('@/assets/image.png')} />; }

This will export to the following:

Output HTML

Copy

<img src="/my-root/assets/assets/image.png" />

Manually passing a URL will need to be manually prefixed:

app/index.tsx

Copy

export default function Blog() { return <img src="/my-root/assets/image.png" />; }

Exporting with webpack

Deprecated: In SDK 50 and later, Expo Webpack has been deprecated in favor of universal Metro (npx expo export). Learn more in migrating from Webpack to Expo Router .

You can export the JavaScript and assets for your web app using webpack by running the following:

Terminal

Copy

- npx expo export:web

• --dev: Bundle in 'development' mode without minifying code or stripping the __DEV__ boolean.
• -c, --clear: Clear the bundler cache before exporting.

This command will be disabled if your project is configured to use metro for bundling web projects in the app.json via the expo.web.bundler: 'metro' field.

Prebuild

---

Terminal

Copy

- npx expo prebuild

Native source code must be generated before a native app can compile. Expo CLI provides a unique and powerful system called prebuild, that generates the native code for your project. To learn more, read the Expo Prebuild docs .

Lint

---

Terminal

Copy

- npx expo lint

Linting helps enforce best practices and ensure your code is consistent. The npx expo lint command will set up ESLint with Expo-specific settings and run the npx eslint command with options that are optimized for the Expo framework. By running npx expo lint --fix, linting issues can be fixed automatically.

Running npx expo lint targets all files in the src, app, and components directories by default. You can also pass custom files or directories to the lint command as arguments. For example:

Terminal

Copy

- npx expo lint ./utils constants.ts

All files matching .js, .jsx, .ts, .tsx, .mjs, .cjs extensions will be linted by default. You can customize the extensions by passing the --ext flag. For example, to lint only .ts and .tsx files, you can use the --ext option: npx expo lint --ext .ts,.tsx or npx expo lint --ext .js --tsx .tsx.

If you need additional customization, you can pass extra arguments using the -- operator. For example, to pass the --no-error-on-unmatched-pattern flag to ESLint, you can run:

Terminal

Copy

- npx expo lint -- --no-error-on-unmatched-pattern

If you need more customization, you can use npx eslint directly.

Using ESLint

Learn more about ensuring best practices with ESLint in an Expo project.

Config

---

Evaluate the app config (app.json, or app.config.js) by running:

Terminal

Copy

- npx expo config

• --full: Include all project config data.
• --json: Output in JSON format, useful for converting an app.config.js to an app.config.json.
• -t, --type: Type of config to show.

Config type

There are three different config types that are generated from the app config:

• public: The manifest file to use with OTA updates. Think of this like an index.html file's <head /> element but for native apps.
• prebuild: The config that is used for Expo Prebuild including async modifiers. This is the only time the config is not serializable.
• introspect: A subset of the prebuild config that only shows in-memory modifications like Info.plist or AndroidManifest.xml changes. Learn more about introspection .

Install

---

Unlike the web, React Native is not backwards compatible. This means that npm packages often need to be the exact right version for the currently installed copy of react-native in your project. Expo CLI provides a best-effort tool for doing this using a list of popular packages and the known working version combinations. Simply use the install command as a drop-in replacement for npm install:

Terminal

Copy

- npx expo install expo-camera

Running a single instance of this command, you can also install multiple packages:

Terminal

Copy

- npx expo install typescript expo-sms

You can directly pass arguments to the underlying package manager by using the -- operator:

Terminal

Copy

- yarn expo install typescript -- -D

# yarn add typescript -D

Version validation

You can perform validation and correction with the --check and --fix flags:

• --check: Check which installed packages need to be updated.
• --fix: Automatically update any invalid package versions.

Example:

Terminal

Copy

# Check all packages for incorrect versions, prompt to fix locally

- npx expo install --check

npx expo install --check prompts you about packages that are installed incorrectly. It also prompts about installing these packages to their compatible versions locally. It exits with non-zero in Continuous Integration (CI). This means you can use this to do continuous immutable validation. In contrast, npx expo install --fix will always fix packages if needed, regardless of the environment.

You can validate specific packages by passing them:

Terminal

Copy

# Check only react-native and expo-sms

- npx expo install react-native expo-sms --check

The command npx expo install expo-camera and npx expo install expo-camera --fix serve the same purpose, the --fix command is useful for upgrading all packages in your project like:

Terminal

Copy

- npx expo install --fix

Configuring dependency validation

There may be circumstances where you want to use a version of a package that is different from the version recommended by npx expo install. In this case, you can exclude specific packages from version checking by using the expo.install.exclude property in your project's package.json.

Install package managers

npx expo install has support for bun, npm, pnpm, and yarn.

You can force the package manager using a named argument:

• --bun: Use bun to install dependencies. Default when bun.lockb or bun.lock exists.
• --npm: Use npm to install dependencies. Default when package-lock.json exists.
• --pnpm: Use pnpm to install dependencies. Default when pnpm-lock.yaml exists.
• --yarn: Use yarn to install dependencies. Default when yarn.lock exists.

Authentication

---

Expo CLI provides authentication methods to use with the npx expo start command. Authentication is used to "code sign" manifests for secure OTA usage. Think of this like HTTPS on the web.

1. Register an account with npx expo register.
2. Login to your account with npx expo login.
3. Check which account is currently authenticated with npx expo whoami.
4. Logout with npx expo logout.

These credentials are shared across Expo CLI and EAS CLI.

Customizing

---

Sometimes you may want to customize a project file that would otherwise be generated in memory by Expo CLI. When utilizing tools other than Expo CLI, you'll need to have the default config files present, otherwise your app may not work as expected. You can generate files by running:

Terminal

Copy

- npx expo customize

From here, you can choose to generate basic project files like:

• babel.config.js -- The Babel configuration. This is required to be present if you plan to use tooling other than Expo CLI to bundle your project.
• webpack.config.js -- The default webpack config for web development.
• metro.config.js -- The default Metro config for universal development. This is required for usage with npx react-native.
• tsconfig.json -- Create a TypeScript config file and install the required dependencies.

Environment variables

---

| Name | Type | Description | | --- | --- | --- | | HTTP_PROXY | string | HTTP/HTTPS proxy URL to connect for all network requests. Configures Undici EnvHttpProxyAgent<br>. | | EXPO_NO_WEB_SETUP | boolean | Prevents the CLI from forcing web dependencies (react-dom, react-native-web, @expo/webpack-config) to be installed before using web functionality. <br>This is useful for cases where you wish to perform non-standard web development. | | EXPO_OFFLINE | boolean | Skip all network requests when applicable. This leads to faster development in areas with poor network connection. | | EXPO_NO_TYPESCRIPT_SETUP | boolean | Prevents the CLI from forcing TypeScript to be configured on npx expo start. <br>For more information, see TypeScript guide<br>. | | DEBUG=expo:* | string | Enables debug logs for the CLI, you can configure this using the debug convention<br>. | | EXPO_DEBUG | boolean | An alias for DEBUG=expo:*. | | EXPO_PROFILE | boolean | Enable profiling stats for the CLI, this does not profile your application. | | EXPO_NO_CACHE | boolean | Disable all global caching. By default, app config JSON schemas, Expo Go binaries for simulators and emulators, and project templates are cached in the global .expo directory on your machine. | | CI | boolean | When enabled, the CLI will disable interactive functionality, skip optional prompts, and fail on non-optional prompts. <br>Example: CI=1 npx expo install --check will fail if any installed packages are outdated. | | EXPO_NO_TELEMETRY | boolean | Disables anonymous usage collection. Learn more about telemetry<br>. | | EXPO_NO_GIT_STATUS | boolean | Skips warning about git status during potentially dangerous actions like npx expo prebuild --clean. | | EXPO_NO_REDIRECT_PAGE | boolean | Disables the redirect page for selecting an app, that shows when a user has expo-dev-client installed, and starts the project with npx expo start instead of npx expo start --dev-client. | | EXPO_PUBLIC_FOLDER | string | Public directory path to use with Metro for web. Learn more about customizing Metro<br>. <br>Default: public | | EDITOR | string | Name of the editor to open when pressing O in the Terminal UI. This value is used across many command line tools. | | EXPO_EDITOR | string | An Expo-specific version of the EDITOR variable which takes higher priority when defined. | | EXPO_IMAGE_UTILS_NO_SHARP | boolean | Disable the usage of global Sharp CLI installation in favor of the slower Jimp package for image manipulation. This is used in places like npx expo prebuild for generating app icons. | | EXPO_TUNNEL_SUBDOMAIN | boolean | Experimental<br><br>Disable using exp.direct as the hostname for --tunnel connections. This enables https:// forwarding which can be used to test universal links on iOS. This may cause unexpected issues with expo-linking and Expo Go. Select the exact subdomain to use by passing a string value that is not one of: true, false, 1, 0. | | EXPO_METRO_NO_MAIN_FIELD_OVERRIDE | boolean | Force Expo CLI to use the resolver.resolverMainFields<br> from the project's metro.config.js for all platforms. By default, Expo CLI will use ['browser', 'module', 'main'], which is the default for webpack, for the web and the user-defined main fields for other platforms. | | ~EXPO_NO_INSPECTOR_PROXY~ | boolean | Deprecated<br><br>Disable the customized inspector proxy with improved support for the Chrome DevTools protocol. <br>This includes support for the network inspector. | | EXPO_NO_CLIENT_ENV_VARS | boolean | Prevent inlining EXPO_PUBLIC_ environment variables in client bundles. | | EXPO_NO_DOTENV | boolean | Prevent all .env file loading across Expo CLI. | | EXPO_NO_METRO_LAZY | boolean | Prevent adding the lazy=true query parameter to Metro URLs (metro@0.76.3 and greater). This disables import() support. | | EXPO_USE_TYPED_ROUTES | boolean | Use expo.experiments.typedRoutes to enable statically typed routes in Expo Router. | | ~EXPO_METRO_UNSTABLE_ERRORS~ | boolean | Deprecated<br><br>Disable inverse dependency stack trace for Metro bundling errors. Enabled by default. | | ~EXPO_USE_METRO_WORKSPACE_ROOT~ | boolean | Deprecated: SDK 52+<br><br>Enable auto server root detection for Metro. This will change the server root to the workspace root. Useful for monorepos. | | EXPO_NO_METRO_WORKSPACE_ROOT | boolean | SDK 52+<br><br>Disable auto server root detection for Metro. Disabling will not change the server root to the workspace root. Enabling this is useful for monorepos. | | ~EXPO_USE_UNSTABLE_DEBUGGER~ | boolean | Deprecated: SDK 52+<br><br>Enable the experimental debugger from React Native. | | EXPO_ADB_USER | string | Set the user number that should be passed to --user with ADB commands. Used for installing APKs on Android devices with multiple profiles. Defaults to 0. | | EXPO_NO_TELEMETRY_DETACH | boolean | SDK 51+<br><br>Send telemetry events in the main thread of @expo/cli. This causes the CLI to slow down as it waits for all the events to be sent. | | EXPO_UNSTABLE_ATLAS | boolean | Experimental<br><br>SDK 51+<br><br>Gather Metro bundle information during development or export. Starting from SDK 53, this environment variable is deprecated in favor of EXPO_ATLAS. | | EXPO_ATLAS | boolean | SDK 53+<br><br>Gather Metro bundle information during development or export. | | EXPO_NO_BUNDLE_SPLITTING | boolean | Experimental<br><br>SDK 51+<br><br>Disable Metro splitting chunks on async imports in production (web-only). | | EXPO_USE_METRO_REQUIRE | boolean | SDK 52+<br><br>Enable the use of Expo's custom Metro require implementation and string based module IDs. This enables better debugging and deterministic IDs for React Server Components. Does not support legacy RAM bundles. | | EXPO_UNSTABLE_METRO_OPTIMIZE_GRAPH | boolean | Experimental<br><br>SDK 52+<br><br>Enable eager bundling where transformation runs uncached after the entire bundle has been created. This is required for production tree shaking and is less optimized for development bundling. | | EXPO_UNSTABLE_TREE_SHAKING | boolean | Experimental<br><br>SDK 52+<br><br>Enable unstable tree shaking support across all platforms. See tree shaking<br> for more details. | | EXPO_NO_REACT_NATIVE_WEB | boolean | Experimental<br><br>SDK 52+<br><br>Enable experimental mode where React Native Web isn't required to run Expo apps on web. | | EXPO_NO_DEPENDENCY_VALIDATION | boolean | SDK 52+<br><br>Disable built-in dependency validation when installing packages through npx expo install and npx expo start. | | EXPO_WEB_DEV_HYDRATE | boolean | Enable React hydration in development for a web project. This can help you identify hydration issues early. | | EXPO_UNSTABLE_LIVE_BINDINGS | boolean | Experimental<br><br>SDK 54+<br><br>Disable live binding in experimental import export support. Enabled by default. Live bindings improve circular dependencies support, but can lead to slightly worse performance. |

Telemetry

---

Expo dev tools collect anonymous data about general usage. This helps us know when a feature is not working as expected. Telemetry is completely optional, you can opt out by using the EXPO_NO_TELEMETRY=1 environment variable.