# Expo SDK Documentation Documentation for Expo SDK libraries, app configuration files, Expo CLI, create-expo-app, and more. --- modificationDate: February 25, 2026 title: create-expo-app description: A command-line tool to create a new Expo and React Native project. --- # create-expo-app A command-line tool to create a new Expo and React Native project. `create-expo-app` is a command-line tool to create and set up a new Expo and React Native project. This tool simplifies the initialization process by providing various templates to get started quickly without the need for manual configuration. ## Create a new project To create a new project, run the following command: ```sh # npm npx create-expo-app@latest # yarn yarn create expo-app # pnpm pnpm create expo-app # bun bun create expo ``` Running the above command will prompt you to enter the app name of your project. This app name is also used in the app config's [`name`](/versions/latest/config/app#name) property. ```sh What is your app named? my-app ``` ## Options Uses the following options to customize the command behavior. ### `--yes` Uses the default options to create a new project. ### `--no-install` Skips installing npm dependencies or CocoaPods. ### `--template` Running `create-expo-app` with a [Node Package Manager](/more/create-expo#node-package-managers-support) initializes and sets up a new Expo project using the default template. You can use the `--template` option to select one of the following templates or pass it as an argument to the option. For example, `--template default`. > Looking for more templates? Check out the [`--example`](/more/create-expo#--example) option to initialize your project with one of the example apps that demonstrate specific features and integrations. | Template | Description | | --- | --- | | [`default`](https://github.com/expo/expo/tree/main/templates/expo-template-default) | Default template. Designed to build multi-screen apps. Includes recommended tools such as Expo CLI, Expo Router library and TypeScript configuration enabled. Suitable for most apps. | | [`blank`](https://github.com/expo/expo/tree/main/templates/expo-template-blank) | Installs minimum required npm dependencies without configuring navigation. | | [`blank-typescript`](https://github.com/expo/expo/tree/main/templates/expo-template-blank-typescript) | A Blank template with TypeScript enabled. | | [`tabs`](https://github.com/expo/expo/tree/main/templates/expo-template-tabs) | Installs and configures file-based routing with Expo Router and TypeScript enabled. | | [`bare-minimum`](https://github.com/expo/expo/tree/main/templates/expo-template-bare-minimum) | A Blank template with native directories (**android** and **ios**) generated. Runs [`npx expo prebuild`](/workflow/prebuild) during the setup. | ### `--example` Use this option to initialize a project using an example from [expo/examples](https://github.com/expo/examples). For example: - Running `npx create-expo-app --example with-router` sets up a project with the Expo Router library - Running `npx create-expo-app --example with-react-navigation` sets up a project similar to the default template, but configured with plain React Navigation library ### `--version` Prints the version number and exits. ### `--help` Prints the list of available options and exits. ## Node Package Managers support Creating a new project with `create-expo-app` also handles setting up additional configuration needed for a specific Node Package Manager. **If you are migrating from one package manager to another**, you've to manually carry out the additional configuration in your project. **If you are using [EAS](/eas)**, you also have to configure your project for any additional required steps manually. All the additional steps for each package manager are listed below. ### npm #### Local installation npm is installed as part of Node.js installation. See [Node.js documentation](https://nodejs.org/en/download/package-manager) for installation instructions. #### EAS installation Supported by default if the project directory contains **package-lock.json**. ### Yarn 1 (Classic) #### Local installation Yarn 1 (Classic) is usually installed as a global dependency of npm. See [Yarn 1 documentation](https://classic.yarnpkg.com/en/docs/getting-started) for installation instructions. #### EAS installation Supported by default if the project directory contains **yarn.lock**. ### Yarn 2+ (Modern) #### Local installation See [Yarn documentation](https://yarnpkg.com/getting-started/install) for installation instructions. Yarn 2+ handles package management differently than Yarn 1. One of the core changes in Yarn 2+ is the [Plug'n'Play (PnP)](https://yarnpkg.com/features/pnp) node linking model that does not work with React Native. By default, a project created with `create-expo-app` and Yarn 2+ uses [`nodeLinker`](https://yarnpkg.com/features/linkers#nodelinker-node-modules) with its value set to `node-modules` to install dependencies. ```yaml nodeLinker: node-modules ``` #### EAS installation Yarn Modern on EAS requires adding [`eas-build-pre-install` hook](/build-reference/npm-hooks). In your project's **package.json**, add the following configuration: ```json { "scripts": { "eas-build-pre-install": "corepack enable && yarn set version 4" } } ``` ### pnpm #### Local installation Requires installing Node.js. See [pnpm documentation](https://pnpm.io/installation) for installation instructions. By default, a project created with `create-expo-app` and pnpm uses [`node-linker`](https://pnpm.io/npmrc#node-linker) with its value set to `hoisted` to install dependencies. ```ini node-linker=hoisted ``` > In **SDK 54** and later, Expo supports isolated installations, and you can delete the `node-linker` setting if you prefer to use isolated dependencies. #### EAS installation Supported by default if the project directory contains **pnpm-lock.yaml**. ### Bun See [Bun](/guides/using-bun) guide for details on creating a new Expo project with `bun`, migration from another package manager, and usage with EAS. --- --- modificationDate: February 25, 2026 title: Expo CLI description: The Expo CLI is a command-line tool that is the primary interface between a developer and other Expo tools. --- # Expo CLI The Expo CLI is a command-line tool that is the primary interface between a developer and other Expo tools. 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](/more/expo-cli#develop) for developing your app: `npx expo start`. - [Generate the native Android and iOS directories](/more/expo-cli#prebuild) for your project: `npx expo prebuild`. - [Build and run](/more/expo-cli#compiling) the native apps locally: `npx expo run:ios` and `npx expo run:android`. - [Install and update packages](/more/expo-cli#install) 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: ```sh 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: ```sh Usage $ npx expo 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: ```sh npx expo login -h ``` ## Installation Expo CLI is included in the `expo` package. You can install it with npm or yarn: ```sh yarn add expo ``` > Projects that are not using [Expo Prebuild](/more/expo-cli#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](/versions/latest/config/metro#bare-workflow-setup). ## Develop Start a development server to work on your project by running: ```sh 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](https://metrobundler.dev/). 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.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](/guides/using-hermes#javascript-inspector-for-hermes). | | O | Open project code in your editor. This can be configured with the `EXPO_EDITOR` and `EDITOR` [environment variables](/more/expo-cli#environment-variables). | | 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](/more/expo-cli#tunneling)). 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: ```sh 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](https://ngrok.com). To enable tunneling, first install `@expo/ngrok`: ```sh npm i -g @expo/ngrok ``` Then run the following to start your dev server from a _tunnel_ URL: ```sh 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](https://status.ngrok.com/) 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: ```sh 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](/more/expo-cli#compiling)), and static files like JavaScript bundles and assets ([exporting](/more/expo-cli#exporting)). Expo CLI provides commands for performing both tasks. ### Compiling You can compile your app locally with the `run` commands: ```sh npx expo run:ios 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](/debugging/runtime-issues#native-debugging). 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](/workflow/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 to start the development server. **Default: 8081**. This is only relevant for development builds. Production builds will [export](/more/expo-cli#exporting) the project and embed the files in the native binary before installing them on a device. - `--binary `: 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: ```sh 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: ```sh 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**](/build-reference/apk#configuring-a-profile-to-build-apks) - **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: ```sh 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](/build/introduction). ##### Debugging native Android project You can debug the native Android project using native debugging tools by opening the **android** directory in Android Studio: ```sh 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: ```sh npx expo run:android --variant freeDebug --app-id dev.expo.myapp.free ``` For more information, see the [Local builds using Android product flavors](/guides/local-app-development#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 ` 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: ```sh 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](/build/introduction). 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: ```sh 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](https://expo.fyi/setup-xcode-signing). ### Exporting You can export the JavaScript and assets for your app using Metro bundler by running: ```sh 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 `: 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](/guides/customizing-metro). - `--dev`: Bundle for **development** environments without minifying code or stripping the `__DEV__` boolean. - `--output-dir `: The directory to export the static files to. **Default: dist** - `--max-workers `: 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](/router/web/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](/workflow/configuration): ```json { "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. ```jsx import { Link } from 'expo-router'; export default function Blog() { return Go to blog post; } ``` This will **export** to the following: ```html Go to blog post ``` If you use ``, 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. ```jsx import { Image } from 'expo-image'; export default function Blog() { return ; } ``` This will **export** to the following: ```html ``` Manually passing a URL will need to be manually prefixed: ```jsx export default function Blog() { return ; } ``` ### 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](/router/migrate/from-expo-webpack). You can export the JavaScript and assets for your web app using webpack by running the following: ```sh 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 ```sh 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](/workflow/prebuild). ## Lint ```sh 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: ```sh 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: ```sh npx expo lint -- --no-error-on-unmatched-pattern ``` If you need more customization, you can use `npx eslint` directly. [Using ESLint](/guides/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: ```sh 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](/more/expo-cli#config-type) 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 `` element but for native apps. - `prebuild`: The config that is used for [Expo Prebuild](/workflow/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](/config-plugins/development-and-debugging#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`: ```sh npx expo install expo-camera ``` Running a single instance of this command, you can also install multiple packages: ```sh npx expo install typescript expo-sms ``` You can directly pass arguments to the underlying package manager by using the `--` operator: ```sh yarn expo install 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: ```sh 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: ```sh 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: ```sh 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`](/versions/latest/config/package-json#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: ```sh 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](https://github.com/nodejs/undici/blob/main/docs/docs/api/EnvHttpProxyAgent.md). | | `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.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`.For more information, see [TypeScript guide](/guides/typescript). | | `DEBUG=expo:*` | **string** | Enables debug logs for the CLI, you can configure this using the [`debug` convention](https://github.com/debug-js/debug#conventions). | | `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.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](/more/expo-cli#telemetry). | | `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](/guides/customizing-metro).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** | , ExperimentalDisable 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`](https://metrobundler.dev/docs/configuration/#resolvermainfields) 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** | , DeprecatedDisable the customized inspector proxy with improved support for the Chrome DevTools protocol.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** | , DeprecatedDisable inverse dependency stack trace for Metro bundling errors. Enabled by default. | | ~`EXPO_USE_METRO_WORKSPACE_ROOT`~ | **boolean** | , Deprecated: SDK 52+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+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+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+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, SDK 51+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+Gather Metro bundle information during development or export. | | `EXPO_NO_BUNDLE_SPLITTING` | **boolean** | , Experimental, SDK 51+Disable Metro splitting chunks on async imports in production (web-only). | | `EXPO_USE_METRO_REQUIRE` | **boolean** | , SDK 52+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, SDK 52+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, SDK 52+Enable unstable tree shaking support across all platforms. See [tree shaking](/guides/tree-shaking) for more details. | | `EXPO_NO_REACT_NATIVE_WEB` | **boolean** | , Experimental, SDK 52+Enable experimental mode where React Native Web isn't required to run Expo apps on web. | | `EXPO_NO_DEPENDENCY_VALIDATION` | **boolean** | , SDK 52+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, SDK 54+Disable live binding in experimental import export support. Enabled by default. Live bindings improve circular dependencies support, but can lead to slightly worse performance. | | `EXPO_UNSTABLE_LOG_BOX` | **boolean** | , Experimental, SDK 55+Enable the experimental LogBox error overlay for native applications. Enabled by default for web. | | `EXPO_NO_QR_CODE` | **boolean** | Prevents the CLI from showing the QR code on console. | ## 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. --- --- modificationDate: February 25, 2026 title: Glossary of terms description: List of non-obvious terms used within the documentation, related to Expo or cross-platform development in general. --- # Glossary of terms List of non-obvious terms used within the documentation, related to Expo or cross-platform development in general. ### Android The mobile operating system that is sponsored by Google for use with **Android** devices. ### App config A file named **app.json**, **app.config.json**, **app.config.js**, or **app.config.ts** in the root project directory. For more information, see [app config configuration](/workflow/configuration). This file is used for the following purposes: - To configure how [Expo CLI](/more/glossary-of-terms#expo-cli) works. - Generate a project's public [manifest](/more/glossary-of-terms#manifest) in EAS Update (think **index.html** but for native apps). - List Expo [config plugins](/more/glossary-of-terms#config-plugin) which influence how `npx expo prebuild` generates native code. ### app.json An [app config](/more/glossary-of-terms#app-config) file. ### Apple capabilities Cloud services that are provided by Apple. These services must be enabled for an application in the [Apple Developer Portal](/more/glossary-of-terms#apple-developer-portal). ### Apple Developer Portal Apple's [official website](https://developer.apple.com/) for managing application code signing. EAS Credentials automate most of the common reasons a developer might visit this website when developing an app. ### Auto capability signing A feature of EAS Build that automatically enables or disables [Apple capabilities](/more/glossary-of-terms#apple-capabilities) based on the project's entitlements file. [Learn more](/build-reference/ios-capabilities). ### Autolinking A cross-platform tool for automatically linking native modules to native apps via native package managers. - On Android the tool is used in the **android/app/build.gradle** and invoked during the [Gradle](/more/glossary-of-terms#gradle) sync process. - On iOS the tool is used in [CocoaPods](/more/glossary-of-terms#cocoapods) **ios/Podfile** and invoked during `pod install`. There are two versions of Autolinking: [Expo Autolinking](/more/glossary-of-terms#expo-autolinking), and [Community Autolinking](/more/glossary-of-terms#community-autolinking). The default [Prebuild template](/more/glossary-of-terms#prebuild-template) includes support for [Expo Autolinking](/more/glossary-of-terms#expo-autolinking), and the [Community Autolinking](/more/glossary-of-terms#community-autolinking) fork. ### Babel Transpiler used for removing language features that aren't available in the runtime's [JavaScript engine](/more/glossary-of-terms#javascript-engine). [Metro](/more/glossary-of-terms#metro-bundler) uses Babel internally. Projects can configure how Babel is used by modifying the [**babel.config.js**](/versions/latest/config/babel) file in the project directory. This file is optional when using [Expo CLI](/more/glossary-of-terms#expo-cli). Expo projects should extend the default Babel preset [`babel-preset-expo`](https://github.com/expo/expo/tree/main/packages/babel-preset-expo). ### Bare workflow Describes the approach when the native projects (in the **android** and **ios** directories) are versioned in Git and maintained manually. It's typical for **existing "bare" React Native apps** where you manually make changes to the native projects. There is freedom to customize them but also high maintenance overhead. This is in contrast to using [app config and prebuild](/workflow/prebuild), where the native projects are not versioned. Instead, they are generated on demand using the `npx expo prebuild`, which is the [recommended approach](/workflow/prebuild#pitch). ### Bun A JavaScript runtime and a drop-in alternative for Node.js. Bun can also be used as a [package manager for JavaScript](/more/glossary-of-terms#package-manager). For more information about usage with Expo and EAS, see [using Bun](/guides/using-bun) guide. ### CocoaPods The iOS package manager that is used to link native modules to the native iOS project. This package manager is configured using the **ios/Podfile** file and updated when a user runs `pod install` in the **ios** directory. ### Community Autolinking This refers to the React Native community [fork](https://github.com/react-native-community/cli/issues/248#issue-422591744) of the [Expo Autolinking](/more/glossary-of-terms#expo-autolinking). The requirements for linking a module are different from [Expo Autolinking](/more/glossary-of-terms#expo-autolinking), however, the implementation is the same. ### Config introspection A process for evaluating the results of [`npx expo prebuild`](/more/glossary-of-terms#prebuild) in-memory without persisting any code changes. This is used in [Auto Capability Signing](/more/glossary-of-terms#auto-capability-signing) to determine what the entitlements file will look like without generating any native code. This process is also used in the [VS Code Expo](/more/glossary-of-terms#vs-code-expo) extension to debug [Config Mods](/more/glossary-of-terms#config-mods). ### Config Mods Async functions that are appended to the [app config](/more/glossary-of-terms#app-config) for use in [Prebuild](/more/glossary-of-terms#prebuild). These functions are given a single native file to modify such as **AndroidManifest.xml** or **Info.plist**. Config mods are chained together and come from the package `@expo/config-plugins`. For more information, see [Config plugins](/config-plugins/introduction). ### Config Plugin A JavaScript function that is used to append [config mods](/more/glossary-of-terms#config-mods) to the [app Config](/more/glossary-of-terms#app-config) for use in [Prebuild](/more/glossary-of-terms#prebuild). For more information, see [Config Plugins](/config-plugins/introduction). ### Continuous Native Generation (CNG) An abstract concept that describes the process of generating native projects from a set of inputs. In the context of Expo, CNG is implemented via the [`prebuild`](/more/glossary-of-terms#prebuild) command. See [CNG](/workflow/continuous-native-generation) and [Expo Prebuild](/workflow/prebuild) for more information. ### create-expo-app A standalone command line tool (CLI) for bootstrapping new React Native apps with the `expo` package installed. See [`create-expo-app` reference](/more/create-expo) for more information. ### create-react-native-app A standalone command line tool (CLI) for bootstrapping new React Native apps with the `expo` package installed and the native code generated. This CLI also enables the use of bootstrapping from an example project in [expo/examples](https://github.com/expo/examples). This package can be used by running any of the following commands: - `npx create-expo-app` - `yarn create expo-app` - `npm create expo-app` ### Dangerous mods Config [modifiers](/more/glossary-of-terms#config-mods) that apply unstable changes to a native project during [prebuild](/more/glossary-of-terms#prebuild). Using these modifiers is unpredictable and prone to breaking changes between major version bumps in [Expo SDK](/more/glossary-of-terms#expo-sdk). For more information, see [Using a dangerous mod](/config-plugins/dangerous-mods). ### Development build A development build is a debug build of your app that contains the `expo-dev-client` package. It's like an evolution of [Expo Go](/more/glossary-of-terms#expo-go) which doesn't have Expo Go's limitations and can be customized to your application's needs. This is the recommended approach for building production-grade apps with Expo. For more information, see [Development builds](/get-started/set-up-your-environment?mode=development-build). ### Dev clients `expo-dev-client` is a library that allows you to create a development build and includes useful development tools. You might also come across "custom dev client", a synonym for [Development builds](/more/glossary-of-terms#development-build). ### Development server A development server (or dev server) is a server that is started locally, usually by running `npx expo start` from [Expo CLI](/more/glossary-of-terms#expo-cli). The development server is typically hosted on `http://localhost:8081`. It hosts a [manifest](/more/glossary-of-terms#manifest) from `/` which the client uses to request the JavaScript bundle from the bundler. ### EAS [Expo Application Services (EAS)](/eas) are deeply integrated cloud services for Expo and React Native apps, such as [EAS Build](/build/introduction), [EAS Submit](/submit/introduction) and [EAS Update](/eas-update/introduction). ### EAS CLI The command-line tool for working with EAS. ### EAS Config The **eas.json** file used to configure [EAS CLI](/more/glossary-of-terms#eas-cli). For more information, see [Configuring EAS Build with eas.json](/build/eas-json). ### EAS Metadata A command-line tool for uploading and downloading Apple App Store metadata as JSON. This tool is available in the [EAS CLI](/more/glossary-of-terms#eas-cli) package and should be used to improve the iOS submission process. For more information, see [EAS Metadata](/eas/metadata). ### EAS Update 1. The cloud hosting service [EAS Update](/eas-update/introduction) that is used for OTA Updates. 2. The CLI command `eas update` from [EAS CLI](/more/glossary-of-terms#eas-cli) used to publish static files to the cloud hosting service. ### Emulator Emulator is used to describe software emulators of Android devices on your computers. Typically, iOS emulators are referred to as [Simulators](/more/glossary-of-terms#simulator). ### Entry point The entry point usually refers to the initial JavaScript file used to load an application. In apps using [Expo CLI](/more/glossary-of-terms#expo-cli), the default entry point is **./node_modules/expo/AppEntry.js** which simply imports the **App.js** file from the root project directory and registers it as the initial component in the native app. ### Experience A synonym for an app that usually implies something more single-use and smaller in scope, sometimes artistic and whimsical. ### Expo Autolinking The original [Autolinking](/more/glossary-of-terms#autolinking) system is designed for projects using `expo-modules-core`. This system links modules based on the existence of an **expo-module.config.json** in the library's root directory. ### Expo CLI The command-line tool for working with Expo. This term now refers to the [Local Expo CLI](/more/glossary-of-terms#local-expo-cli), but historically referred to the [Global Expo CLI](/more/glossary-of-terms#global-expo-cli). For more information, see [Expo CLI](/more/expo-cli). ### Expo client The former name for the [Expo Go](/more/glossary-of-terms#expo-go) app. ### Expo export Refers to the command `npx expo export` from [Expo CLI](/more/glossary-of-terms#expo-cli). This command is used to bundle the app's JavaScript and assets, and then export them into a static directory that can be uploaded to a hosting service like [EAS Update](/more/glossary-of-terms#eas-update), and embedded in a [native runtime](/more/glossary-of-terms#native-runtime) for offline use. ### Expo Go The Android and iOS app that serves as a sandbox for learning and experimenting with React Native. Due to its limitations (such as the inability to include custom native code), it's not recommended for building and distributing production apps. Instead, use a [development build](/more/glossary-of-terms#development-build). ### Expo install Refers to the command `npx expo install` from [Expo CLI](/more/glossary-of-terms#expo-cli). This command is used to install npm packages containing [native modules](/more/glossary-of-terms#native-module) that work with the currently installed version of `expo` in the project. Not all packages are supported. This command wraps the globally installed [package managers](/more/glossary-of-terms#package-manager). ### Expo Module Config A file named **expo-module.config.json** that lives in the root directory of a [native module](/more/glossary-of-terms#native-module). For more information, see [Module Config](/modules/module-config). ### Expo SDK A collection of [npm](/more/glossary-of-terms#npm) packages containing [native modules](/more/glossary-of-terms#native-module) that provides access to device/system functionality such as camera, push notification, contacts, file system, and more. - Each package supports Android, iOS, and web whenever possible. - The interface is completely written in [TypeScript](/more/glossary-of-terms#typescript). - All packages in the Expo SDK work with each other and can safely be compiled together. - Any package in the SDK can be used in any [React Native](/more/glossary-of-terms#react-native) app, with minimal, shared setup. [Learn more](/bare/installing-expo-modules). - All packages are [open source](https://github.com/expo/expo/tree/main/packages) and can be freely customized. ### Expo start Refers to the command `npx expo start` from [Expo CLI](/more/glossary-of-terms#expo-cli). This command is used to start a local [development server](/more/glossary-of-terms#development-server) that a [client](/more/glossary-of-terms#expo-client) connects to interact with the [Metro bundler](/more/glossary-of-terms#metro-bundler). ### Fabric The React Native rendering system which is used to create and manage native views. For more information, see [Fabric Renderer](https://reactnative.dev/architecture/fabric-renderer). ### Flipper A mobile app debugger used internally at Meta. It was previously recommended for use with React Native, but the integration is now deprecated and no longer supported by the React Native team [(RFC-0641)](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0641-decoupling-flipper-from-react-native-core.md). ### FYI Sometimes referred to as **Expo FYI**, is a collection of tailored solutions to complex issues that live at [expo.fyi](https://expo.fyi/). FYI links are utilized throughout Expo's developer tooling to help provide a better developer experience to users. ### Global Expo CLI The package `expo-cli` was installed globally on the user's machine and used across all projects. This CLI was introduced in SDK 30 (2018), and deprecated in favor of the [Local Expo CLI](/more/glossary-of-terms#local-expo-cli) in SDK 46 (2022). ### Gradle Gradle is a build automation tool for multi-language software development. It's used to build Android apps. It controls the development process in the tasks of compilation and packaging to testing, deployment, and publishing. ### Hermes engine A [JavaScript engine](/more/glossary-of-terms#javascript-engine) developed by [Meta](/more/glossary-of-terms#meta) specifically for use with [React Native](/more/glossary-of-terms#react-native). Hermes features ahead-of-time static optimization and compact bytecode to improve performance with focus on mobile devices, and is the default JS engine. ### iOS The operating system used on iPhone, iPad, and Apple TV. [Expo Go](/more/glossary-of-terms#expo-go) currently runs on iOS for iPhone and iPad. ### JavaScript engine A native package that can evaluate JavaScript on-device. In React Native, we predominantly use [Hermes](/more/glossary-of-terms#hermes-engine) by [Meta](/more/glossary-of-terms#meta). Other options include [JavaScriptCore](/more/glossary-of-terms#javascriptcore-engine) by Apple, and V8 by Google. ### JavaScriptCore engine A [JavaScript engine](/more/glossary-of-terms#javascript-engine) developed by Apple and built-in to [iOS](/more/glossary-of-terms#ios). React Native for [Android](/more/glossary-of-terms#android) also can use a version of JavaScriptCore for parity. Debugging with JavaScriptCore is less sophisticated than V8 or [Hermes](/more/glossary-of-terms#hermes-engine) which implement the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/). ### Linking Linking can mean [deep linking into apps similar to how you link to websites on the web](/linking/overview) or [autolinking](/more/glossary-of-terms#autolinking). ### Local Expo CLI The package `@expo/cli` is installed with the `expo` package. This is sometimes referred to as the "Versioned Expo CLI" because it is installed inside the user's project as opposed to the now deprecated `expo-cli` which was installed globally. ### Manifest An Expo app manifest is similar to a [web app manifest](https://developer.mozilla.org/en-US/docs/Web/Manifest). It provides information that Expo Go needs to know how to run the app and other relevant data. ### Meta Formerly Facebook, Meta is the group that develops [React Native](/more/glossary-of-terms#react-native), [Metro Bundler](/more/glossary-of-terms#metro-bundler), [Hermes Engine](/more/glossary-of-terms#hermes-engine), [Yoga](/more/glossary-of-terms#yoga) and more. The Expo team collaborates with Meta to deliver the best possible developer experience. ### Metro bundler The bundler used for converting JavaScript files and assets into a format that runs on a [native runtime](/more/glossary-of-terms#native-runtime). This bundler is maintained by [Meta](/more/glossary-of-terms#meta) and used for React Native (including web) apps. For more information, see [Metro documentation](https://metrobundler.dev/). ### Metro config The **metro.config.js** file used to configure [Metro bundler](/more/glossary-of-terms#metro-bundler). This should extend the package `@expo/metro-config` when using [Expo CLI](/more/glossary-of-terms#expo-cli). For more information, see [Customizing Metro](/guides/customizing-metro). ### Monorepo A project that has multiple sub-projects which are all linked together via the package manager. A monorepo is a great way to maintain codebase for a cross-platform app. ### Native directory The React Native ecosystem has thousands of libraries. Without a purpose-built tool, it's hard to know what the libraries are, to search through them, to determine the quality, try them out, and filter out the libraries that won't work for your project (some don't work with Expo, some don't work with Android or iOS). [React Native Directory](https://reactnative.directory/) is a website that aims to solve this problem, we recommend you use it to find packages to use in your projects. ### Native module A module written in native code that exposes native platform functionality to the JavaScript engine via the JS global. This functionality is usually accessed via `import { NativeModules } from 'react-native';`. ### Native runtime A native application containing a [JavaScript engine](/more/glossary-of-terms#javascript-engine), and is capable of running a React application. This includes [Expo Go](/more/glossary-of-terms#expo-go), [development build](/more/glossary-of-terms#development-build), [standalone apps](/more/glossary-of-terms#standalone-app), and even web browsers like Chrome. ### npm [npm](https://www.npmjs.com/) is a [package manager for JavaScript](/more/glossary-of-terms#package-manager) and the registry where the packages are stored. ### Package manager Automates the process of installing, upgrading, configuring, and removing libraries, also known as dependencies, from your project. See [Bun](/more/glossary-of-terms#bun), [npm](/more/glossary-of-terms#npm), [pnpm](/more/glossary-of-terms#pnpm), and [Yarn](/more/glossary-of-terms#yarn). ### Package manager workspaces The recommended [monorepo](/more/glossary-of-terms#monorepo) solution for Expo users. See [Working with Monorepos](/guides/monorepos) guide for more information on how to configure workspaces with supported package managers. ### Platform extensions Platform extensions are a feature of the [Metro bundler](/more/glossary-of-terms#metro-bundler) which enables users to substitute files on a per-platform basis given a specific filename. For example, if a project has a **.index.js** file and a **.index.ios.js** file, then the **index.ios.js** will be used when bundling for iOS, and the **index.js** file will be used when bundling for all other platforms. By default, platform extensions are resolved in `@expo/metro-config` using the following formula: - Android: **\*.android.js**, **\*.native.js**, **\*.js** - iOS: **\*.ios.js**, **\*.native.js**, **\*.js** - Web: **\*.web.js**, **\*.js** ### pnpm [pnpm](https://pnpm.io/) is [package manager for JavaScript](/more/glossary-of-terms#package-manager), focused on disk space efficiency. ### Prebuild The process of generating the temporary native **android** and **ios** directories for a React Native project based on the [app config](/more/glossary-of-terms#app-config). This process is performed by running the command `npx expo prebuild` from [Expo CLI](/more/glossary-of-terms#expo-cli) in a project directory. See [Prebuild template](/more/glossary-of-terms#prebuild-template) and [Autolinking](/more/glossary-of-terms#autolinking) for further information. ### Prebuild template The React Native project template is used as the first step of [Prebuilding](/more/glossary-of-terms#prebuild). This template is versioned with the [Expo SDK](/more/glossary-of-terms#expo-sdk), and the template is chosen based on the installed version of `expo` in a project. After the template is cloned, `npx expo prebuild` evaluates the [app config](/more/glossary-of-terms#app-config) and runs the [Config mods](/more/glossary-of-terms#config-mods) which modify various files in the template. Although the template can be changed by using the `npx expo prebuild --template /path/to/template` flag, the default prebuild template contains important initial defaults that the `npx expo prebuild` command makes assumptions about. The default template currently lives at [`expo-template-bare-minimum`](https://github.com/expo/expo/tree/main/templates/expo-template-bare-minimum). ### Publish We use the word "publish" as a synonym for "deploy". When you publish an app, it becomes available at a persistent URL from Expo Go, or in the case of [Standalone apps](/more/glossary-of-terms#standalone-app), it updates the app. ### React Native [React Native](https://reactnative.dev/) lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components. ### React Native Web A high-performing abstraction on top of `react-dom` that enables core primitives from [React Native](/more/glossary-of-terms#react-native) to run in the browser. React Native for web (RNW) was developed at X and is currently used for their [main website](https://x.com). [Expo SDK](/more/glossary-of-terms#expo-sdk) and [Expo CLI](/more/glossary-of-terms#expo-cli) have first-class support for RNW. ### React Navigation The preferred navigation library for React Native apps, developed and sponsored by the Expo team. ### Remote Debugging Remote Debugging is a deprecated way of debugging React Native apps. A better alternative today is to use [Hermes](/more/glossary-of-terms#hermes-engine), as you can connect React Native DevTools to it. Also known as Async Chrome Debugging, it was an experimental system for debugging React Native apps. The system works by executing the application JavaScript in a Chrome tab's web worker, then sending native commands over a websocket to the native device. ### Simulator An emulator for iOS devices that you can run on macOS (or in [Snack](/more/glossary-of-terms#snack)) to work on your app without having to have a physical device handy. ### Slug `slug` in the \[app config\]((#appjson) is a URL-friendly name for your project. It is unique across your Expo account. ### Snack [Snack](https://snack.expo.dev/) is an in-browser development environment where you can build Expo [experiences](/more/glossary-of-terms#experience) without installing any tools on your phone or computer. ### Software Mansion A development agency in Kraków, Poland. Maintainers of `react-native-gesture-handler`, `react-native-screens`, and `react-native-reanimated`. The platform team at Expo is composed of a number of contractors from Software Mansion. All of Software Mansion's core React Native libraries are supported in [Expo Go](/more/glossary-of-terms#expo-go). ### Standalone app Synonymous with "Production build". An application binary that can be submitted to the Google Play Store or Apple App Store. For more information, see [Build your project for app stores](/deploy/build-project) or [Run builds locally or on your own infrastructure](/build-reference/local-builds). ### Store config The **store.config.json** file used to configure [EAS Metadata](/more/glossary-of-terms#eas-metadata). This file can be generated from an existing App Store entry using `eas metadata:pull`. ### Sweet API The Swift and Kotlin API for writing React Native modules. This API is provided by the library `expo-modules-core` which is shipped with the `expo` package. For more information, see [Module API](/modules/module-api). ### TypeScript TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale. The Expo SDK is written in TypeScript, and we highly recommend using it. For more information, see our [TypeScript guide](/guides/typescript). ### Updates Traditionally, apps for Android and iOS are updated by submitting an updated binary to the App and Play stores. Updates allow you to push an update to your app without the overhead of submitting a new release to the stores. For more information, see [Publishing](/eas-update/introduction) documentation. ### VS Code Expo Tools The VS Code extension for improving the developer experience of working with app config files. This extension provides autocomplete and intellisense for the [app config](/more/glossary-of-terms#app-config), [Store Config](/more/glossary-of-terms#store-config), [Expo Module Config](/more/glossary-of-terms#expo-module-config), and [EAS Config](/more/glossary-of-terms#eas-config). For more information, see the [VS Code Expo Tools extension](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools). ### Watchman The file watcher used by [Metro](/more/glossary-of-terms#metro-bundler) to perform hot reloads during development. Watchman contains native code and may cause issues when installed globally. Watchman is maintained by [Meta](/more/glossary-of-terms#meta). ### webpack The deprecated bundler used by [Expo CLI](/more/glossary-of-terms#expo-cli) for developing [`react-native-web`](/more/glossary-of-terms#react-native-web) apps. ### Yarn [Yarn](https://yarnpkg.com/) is a [package manager for JavaScript](/more/glossary-of-terms#package-manager), created at Meta. It has two mainline versions [Yarn v1 (Classic)](https://classic.yarnpkg.com/lang/en/) and [Yarn Berry](https://github.com/yarnpkg/berry). ### Yoga A native cross-platform library used by React Native internally to provide [CSS FlexBox](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_flexible_box_layout/Basic_concepts_of_flexbox) support to native views. React Native styles are passed to Yoga to lay out and style elements on the screen. For more information, see [Yoga](https://github.com/facebook/yoga) documentation. --- --- modificationDate: February 25, 2026 title: qr.expo.dev description: Reference for the QR code generator at qr.expo.dev. --- # qr.expo.dev Reference for the QR code generator at qr.expo.dev. qr.expo.dev is a cloud function that generates Expo-branded QR codes. This function creates QR codes for [EAS Update](/eas-update/introduction), which are used to preview updates in [development builds](/develop/development-builds/introduction) and Expo Go. For example, if you and your team have a development build, and you'd like to load the latest update on a specific build's channel, you could go to the following endpoint to generate a QR code: ```text https://qr.expo.dev/eas-update?projectId=your-project-id&runtimeVersion=your-runtime-version&channel=your-channel ``` Which would produce the following QR code SVG: This QR code represents the following URL: ```text exp+your-slug://expo-development-client/?url=https://u.expo.dev/your-project-id?runtime-version=your-runtime-version&channel-name=your-channel ``` This URL will deep link into a development build and instruct it to fetch the latest update on the specified channel. > If sharing the URL is more convenient, you can request the URL directly by adding `format=url` to the query parameters. ## General The following parameters apply to the `/eas-update` endpoint. ### Base query parameters The following base query parameters can be included with any request to `/eas-update`. | Param | Required | Default | Description | | --- | --- | --- | --- | | `slug` | No | exp | Use [`slug`](/versions/latest/config/app#slug) from [app config](/workflow/configuration) to target a development build. Otherwise use "exp" to target Expo Go. | | `appScheme` (deprecated) | No | exp | Replaced by `slug`. Use `slug` instead. | | `host` | No | u.expo.dev | The hostname of the server that handles update requests. | | `format` | No | svg | Endpoints respond with SVGs by default. To receive a plain text URL, use `url`. | ### Update by device traits Preview and production builds make requests to the EAS Update service with `runtimeVersion` and `channel` properties. You can emulate this behavior with the following query parameters: | Param | Required | Description | | --- | --- | --- | | `projectId` | Yes | The ID of the project | | `runtimeVersion` | Yes | The [runtime version](/eas-update/runtime-versions) of the build | | `channel` | Yes | The channel name of the build | #### Example ```text https://qr.expo.dev/eas-update?projectId=your-project-id&runtimeVersion=your-runtime-version&channel=your-channel ``` ### Update by ID You can create a QR code for a specific update given its platform-specific ID. | Param | Required | Description | | --- | --- | --- | | `updateId` | Yes | The ID of the update | #### Example ```text https://qr.expo.dev/eas-update?updateId=your-update-id ``` ### Update by group ID You can create a QR code for an update group given the update's group ID. | Param | Required | Description | | --- | --- | --- | | `projectId` | Yes | The ID of the project | | `groupId` | Yes | The ID of the update group | #### Example ```text https://qr.expo.dev/eas-update?projectId=your-project-id&groupId=your-update-id ``` ### Update by branch ID You can create a QR code with a branch's ID, which will return the latest update available on that branch. | Param | Required | Description | | --- | --- | --- | | `projectId` | Yes | The ID of the project | | `branchId` | Yes | The ID of the branch | #### Example ```text https://qr.expo.dev/eas-update?projectId=your-project-id&branchId=your-branch-id ``` ### Update by channel ID You can create a QR code with a channel's ID, which will return the latest update available on the branch or branches that are mapped to that channel. | Param | Required | Description | | --- | --- | --- | | `projectId` | Yes | The ID of the project | | `channelId` | Yes | The ID of the channel | #### Example ```text https://qr.expo.dev/eas-update?projectId=your-project-id&channelId=your-channel-id ``` --- --- modificationDate: February 25, 2026 title: Release statuses description: Learn about alpha, preview, beta, and stable release statuses and how they affect feature stability when using Expo SDK and Expo Application Services (EAS). --- # Release statuses Learn about alpha, preview, beta, and stable release statuses and how they affect feature stability when using Expo SDK and Expo Application Services (EAS). Expo uses different release statuses to indicate the stability and readiness of its tools and services. Understanding these statuses can help you make informed decisions about which features and versions to use in your projects. ## Alpha Alpha features are available for early testing but may have significant limitations. These features are in the earliest stage of development and are shared with the community to gather feedback and shape their direction. **What to expect:** - APIs are subject to breaking changes without major version bumps - Implementation may change substantially based on feedback - May have known bugs or performance issues - Not recommended for production apps Alpha features are opportunities to influence the future of Expo. We encourage you to test these features in development environments and [provide feedback](https://expo.dev/contact) to help us refine them before they reach a wider audience. ## Preview Preview features provide an early look at a slice of new functionality. Unlike alpha releases, preview features are designed with minimal overhead and limited scope, but they are not yet feature-complete. **What to expect:** - A focused slice of functionality, not the full feature set - Designed with minimal overhead, but not yet fully validated for all production scenarios - APIs may evolve as the feature is built out further - Can be used in production with thorough testing, though functionality is limited The purpose of a preview is to share new functionality early and gather feedback about a specific slice before building it out further. Your input directly helps shape the direction of the feature. [Share your feedback](https://expo.dev/contact) to help us prioritize what to build next. ## Beta Beta features are feature-complete and undergoing final validation. These features have core functionality implemented and are being prepared for stable release. **What to expect:** - Core functionality is complete and API shape is mostly settled - May have minor bugs or edge cases that are being addressed - Breaking changes are possible but unlikely unless critical issues are found - Can be used in production with thorough testing Beta features are ready for real-world testing. While we don't expect major changes, we recommend testing thoroughly if you plan to use them in production. [Your feedback](https://expo.dev/contact) during this stage helps us catch any remaining issues before the stable release. ## Stable Features without any status badge are considered stable and are fully released for production use. These features have been thoroughly tested and follow semantic versioning for any future changes. **What to expect:** - Production-ready with full support - Breaking changes only occur in major version releases - Performance and stability have been validated - Documentation and examples available Stable features are ready for use in any application. You can rely on them following semantic versioning principles, meaning breaking changes will only occur in major version updates. ## Deprecated Deprecated features are those that are no longer recommended for use and will be removed in future releases. We provide deprecation warnings to give developers time to transition away from these features. **What to expect:** - Warnings in documentation and code when using deprecated features - No new features or improvements will be made - Removal in future major releases When you encounter a deprecated feature, we recommend planning to migrate to the suggested alternatives as soon as possible to ensure your projects remain up-to-date and maintainable. --- --- modificationDate: May 24, 2021 title: Expo Structured Field Values description: Version 0 --- # Expo Structured Field Values Version 0 Structured Field Values for HTTP, [IETF RFC 8941](https://tools.ietf.org/html/rfc8941), is a proposal to formalize header syntax and facilitate nested data. Since it is still a work in progress, Expo maintains a custom version that only implements the following subset of the protocol defined in [IETF RFC 8941](https://tools.ietf.org/html/rfc8941): - All key values - String, integer, and decimal items - Dictionaries --- --- modificationDate: March 13, 2023 title: Expo Updates v1 description: Version 1 --- # Expo Updates v1 Version 1 ## Introduction This is the specification for Expo Updates, a protocol for delivering updates to Expo apps running on multiple platforms. ### Conformance Conforming servers and client libraries must fulfill all normative requirements. Conformance requirements are described in this document by both descriptive assertions and key words with clearly defined meanings. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative portions of this document are to be interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119). These key words may appear in lowercase and still retain their meaning unless explicitly declared as non-normative. A conforming implementation of this protocol MAY provide additional functionality, but MUST NOT where explicitly disallowed or would otherwise result in non-conformance. Where relevant, unknown fields should be allowed and ignored by conforming clients. ### Overview Conforming servers and client libraries MUST follow the HTTP spec as described in [RFC 7231](https://tools.ietf.org/html/rfc7231) as well as the more precise guidance described in this spec. - An _update_ is defined as a [_manifest_](/technical-specs/expo-updates-1#manifest-body) together with the assets referenced inside the manifest. - A [_directive_](/technical-specs/expo-updates-1#directive-body) is defined as a message from the server that instructs clients to perform an action. Expo Updates is a protocol for assembling and delivering updates and directives to clients. The primary audiences of this spec are Expo Application Services and organizations that wish to manage their own update server to satisfy internal requirements. ## Client > See the [reference client library](https://github.com/expo/expo/tree/main/packages/expo-updates). An app running a conformant Expo Updates client library MUST load the most recent _update_ saved in the client library's update database, possibly after filtering by the contents of the update's manifest [_metadata_](/technical-specs/expo-updates-1#manifest-body). The following describes how a conformant Expo Updates client library MUST retrieve a new update from a conformant server: 1. The client library MUST make a [request](/technical-specs/expo-updates-1#request) for the most recent update and directive, with constraints specified in the headers. 2. If a [response](/technical-specs/expo-updates-1#response) is received, the client library MUST process its contents: - For a response containing an _update_, the client library SHALL proceed to make additional requests to download and store any new assets specified in the manifest. The manifest and assets together are considered a new _update_. The client library will edit its local state to reflect that a new update has been added to the local storage. It will also update the local state with the new `expo-manifest-filters` and `expo-server-defined-headers` found in the response [headers](/technical-specs/expo-updates-1#manifest-response-headers). - For a response containing a _directive_, the client library will consume the directive depending on the directive type and edit its local state accordingly. ## Request A conformant client library MUST make a GET request with the headers: 1. `expo-protocol-version: 1`, to specify version 1 of this Expo Updates specification. 2. `expo-platform`, to specify the platform type the client is running on. - iOS MUST be `expo-platform: ios`. - Android MUST be `expo-platform: android`. - If it is not one of these platforms, the server SHOULD return a 400 or a 404 3. `expo-runtime-version` MUST be a runtime version compatible with the client. A runtime version stipulates the native code setup a client is running. It should be set when the client is built. For example, in an iOS client, the value may be set in a plist file. 4. Any headers stipulated by a previous responses' [server defined headers](/technical-specs/expo-updates-1#response). A conformant client library MAY send one of `accept: application/expo+json`, `accept: application/json`, or `accept: multipart/mixed` based on the [supported response structures](/technical-specs/expo-updates-1#response), though it SHOULD send `accept: application/expo+json, application/json, multipart/mixed`. A conformant client library MAY express preference using "q" parameters as specified in [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.1), which default to `1`. A conformant client library configured to perform [code signing](/technical-specs/expo-updates-1#code-signing) verification MUST send a `expo-expect-signature` header to indicate that it expects the conformant server to include the `expo-signature` header in the manifest response. `expo-expect-signature` is an [Expo SFV](/technical-specs/expo-sfv-0) dictionary which MAY contain any of the following key value pairs: - `sig` SHOULD contain the boolean `true` to indicate that it requires a conformant server to respond with the signature in the `sig` key. - `keyid` SHOULD contain the keyId of the public key the client will use to verify the signature - `alg` SHOULD contain the algorithm the client will use to verify the signature Example: ```text expo-protocol-version: 1 accept: application/expo+json;q=0.9, application/json;q=0.8, multipart/mixed expo-platform: * expo-runtime-version: * expo-expect-signature: sig, keyid="root", alg="rsa-v1_5-sha256" ``` ## Response A conformant server MUST return a response structured in at least one of the two following response structures, MAY support either or both response structures, and when an unsupported response structure is requested the server SHOULD respond with an HTTP `406` error status. A server that wishes to respond with an incompatible response for the requested protocol version SHOULD also respond with an HTTP `406` error status instead. - For a response with `content-type: application/json` or `content-type: application/expo+json`, the [common response headers](/technical-specs/expo-updates-1#common-response-headers) and [other response headers](/technical-specs/expo-updates-1#other-response-headers) MUST be sent in the response headers and the [manifest body](/technical-specs/expo-updates-1#manifest-body) MUST be sent in the response body. This format of response does not support multiple response parts and therefore does not support _directives_, and SHOULD respond with an HTTP `406` error status when the most recent response to be served is not an _update_. - For a response with `content-type: multipart/mixed`, the response MUST be structured as specified in the [multipart response](/technical-specs/expo-updates-1#multipart-response) section. - A [multipart response](/technical-specs/expo-updates-1#multipart-response) with no parts MAY respond with an HTTP `204` status and no content, and thus no `content-type` response header. The choice of update and headers are dependent on the values of the request headers. A conformant server MUST respond with the most recent update, ordered by creation time, satisfying all parameters and constraints imposed by the [request headers](/technical-specs/expo-updates-1#request). The server MAY use any properties of the request like its headers and source IP address to choose among several updates that all satisfy the request's constraints. ### Common response headers ```text expo-protocol-version: 1 expo-sfv-version: 0 expo-manifest-filters: expo-server-defined-headers: cache-control: * content-type: * ``` - `expo-protocol-version` describes the version of the protocol defined in this spec and MUST be `1`. - `expo-sfv-version` MUST be `0`. - `expo-manifest-filters` is an [Expo SFV](/technical-specs/expo-sfv-0) dictionary. It is used to filter updates stored by the client library by the `metadata` attribute found in the [manifest](/technical-specs/expo-updates-1#manifest-body). If a field is mentioned in the filter, the corresponding field in the metadata must either be missing or equal for the update to be included. The client library MUST store the manifest filters until it is overwritten by a newer response. - `expo-server-defined-headers` is an [Expo SFV](/technical-specs/expo-sfv-0) dictionary. It defines headers that a client library MUST store until overwritten by a newer dictionary, and they MUST be included in every subsequent [update request](/technical-specs/expo-updates-1#request). - `cache-control` MUST be set to an appropriately short period of time. A value of `cache-control: private, max-age=0` is recommended to ensure the newest manifest is returned. Setting longer cache ages could result in stale updates. - `content-type` MUST be determined by _proactive negotiation_ as defined in [RFC 7231](https://tools.ietf.org/html/rfc7231#section-3.4.1). Since the client library is [required](/technical-specs/expo-updates-1#request) to send an `accept` header with each manifest request, this will always be either `application/expo+json`, `application/json`; otherwise the request would return a `406` error. ### Other response headers ```text expo-signature: * ``` - `expo-signature` SHOULD contain the signature of the manifest to be used during the validation step of [code signing](/technical-specs/expo-updates-1#code-signing) if the request for the manifest contained the `expo-expect-signature` header. This is an [Expo SFV](/technical-specs/expo-sfv-0) dictionary which MAY contain any of the following key value pairs: - `sig` MUST contain the signature of the manifest. The name of this field matches that of `expo-expect-signature`. - `keyid` MAY contain the keyId of the key the server used to sign the response. The client SHOULD use the certificate that matches this `keyid` to verify the signature. - `alg` MAY contain the algorithm the server used to sign the response. The client SHOULD use this field only if it matches the algorithm defined for the certificate matching `keyid`. ### Multipart response An update response of this format is defined by the `multipart/mixed` MIME type as defined by [RFC 2046](https://tools.ietf.org/html/rfc2046#section-5.1). Headers for this response format are the [common response headers](/technical-specs/expo-updates-1#common-response-headers), with the following exceptions: - `content-type` SHOULD have a `multipart/mixed` value as defined by [RFC 2046](https://tools.ietf.org/html/rfc2046#section-5.1) Part order is not strict. A multipart response with no parts (zero-length body) should be considered a no-op (no updates or directives available), though headers for the response SHOULD be sent nevertheless and processed by the client. Each part is defined as follows: 1. OPTIONAL `"manifest"` part: - MUST have part header `content-disposition: form-data; name="manifest"`. The first parameter (`form-data`) does not need to be `form-data`, but the `name` parameter must have `manifest` as a value. - MUST have part header `content-type: application/json` or `application/expo+json`. - SHOULD have part header `expo-signature` as defined in [other response headers](/technical-specs/expo-updates-1#other-response-headers) if code signing is being used. - The [manifest body](/technical-specs/expo-updates-1#manifest-body) MUST be sent in the part body. 2. OPTIONAL `"extensions"` part: - MUST have part header `content-disposition: form-data; name="extensions"`. The first parameter (`form-data`) does not need to be `form-data`, but the `name` parameter must have `extensions` as a value. - MUST have part header `content-type: application/json`. - The [extensions-body](/technical-specs/expo-updates-1#extensions-body) MUST be sent in the part body. 3. OPTIONAL `"directive"` part: - MUST have part header `content-disposition: form-data; name="directive"`. The first parameter (`form-data`) does not need to be `form-data`, but the `name` parameter must have `directive` as a value. - MUST have part header `content-type: application/json` or `application/expo+json`. - SHOULD have part header `expo-signature` as defined in [other response headers](/technical-specs/expo-updates-1#other-response-headers) if code signing is being used. - The [directive body](/technical-specs/expo-updates-1#directive-body) MUST be sent in the part body. ### Manifest body Defined as JSON conforming to both the following `Manifest` definition expressed in [TypeScript](https://www.typescriptlang.org/) and the detailed descriptions for each field: ```ts type Manifest = { id: string; createdAt: string; runtimeVersion: string; launchAsset: Asset; assets: Asset[]; metadata: { [key: string]: string }; extra: { [key: string]: any }; }; type Asset = { hash?: string; key: string; contentType: string; fileExtension?: string; url: string; }; ``` - `id`: The ID MUST uniquely specify the manifest and MUST be a UUID. - `createdAt`: The date and time at which the update was created is essential as the client library selects the most recent update (subject to any constraints supplied by the `expo-manifest-filters` header). The datetime should be formatted according to [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). - `runtimeVersion`: Can be any string defined by the developer. It stipulates what native code setup is required to run the associated update. - `launchAsset`: A special asset that is the entry point of the application code. The `fileExtension` field will be ignored for this asset and SHOULD be omitted. - `assets`: An array of assets used by the update bundle, such as JavaScript, pictures, and fonts. All assets (including the `launchAsset`) should be downloaded to disk before executing the update, and a mapping of asset `key`s to locations on disk should be provided to application code. - Properties of each asset object: - `hash`: Base64URL-encoded SHA-256 hash of the file to guarantee integrity. Base64URL encoding is defined by [IETF RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648#section-5). - `key`: Key used to reference this asset from the update's application code. This key, for example, may be generated by a separate build step that processes the application code, such as a bundler. - `contentType`: The MIME type of the file as defined by [RFC 2045](https://tools.ietf.org/html/rfc2045). For example, `application/javascript`, `image/jpeg`. - `fileExtension`: The suggested extension to use when a file is saved on a client. Some platforms, such as iOS, require certain file types to be saved with an extension. The extension MUST be prefixed with a `.`. For example, **.jpeg**. In some cases, such as the launchAsset, this field will be ignored in favor of a locally determined extension. If the field is omitted and there is no locally stipulated extension, the asset will be saved without an extension. For example, `./filename` with no `.` at the end. A conforming client SHOULD prefix a file extension with a `.` if a file extension is not empty and missing the `.` prefix. - `url`: Location at which the file may be fetched. - `metadata`: The metadata associated with an update. It is a string-valued dictionary. The server MAY send back anything it wishes to be used for filtering the updates. The metadata MUST pass the filter defined in the accompanying `expo-manifest-filters` header. - `extra`: For storage of optional "extra" information such as third-party configuration. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID may be included: ```json "extra": { "eas": { "projectId": "00000000-0000-0000-0000-000000000000" } } ``` ### Extensions body Defined as JSON conforming to both the following `Extensions` definition expressed in [TypeScript](https://www.typescriptlang.org/) and the detailed descriptions for each field: ```ts type Extensions = { assetRequestHeaders: ExpoAssetHeaderDictionary; ... } type ExpoAssetHeaderDictionary = { [assetKey: string]: { [headerName: string]: string, }; } ``` - `assetRequestHeaders`: MAY contain a dictionary of header (key, value) pairs to include with asset requests. Key and value MUST both be strings. ### Directive body Defined as JSON conforming to both the following `Directive` definition expressed in [TypeScript](https://www.typescriptlang.org/) and the detailed descriptions for each field: ```ts type Directive = { type: string; parameters?: { [key: string]: any }; extra?: { [key: string]: any }; }; ``` - `type`: The type of directive. - `parameters`: MAY contain any extra information specific to the `type`. - `extra`: For storage of optional "extra" information such as third-party information. For example, if the update is hosted on Expo Application Services (EAS), the EAS project ID may be included. A conformant client library and server MAY specify and implement directive types specific to the needs of the application. For example, Expo Application Services makes use of one type thus far, `rollBackToEmbedded`, which directs the expo-updates library to use the update embedded in the host application instead of any other downloaded updates. ## Asset request A conformant client library MUST make a GET request to the asset URLs specified by the manifest. The client library SHOULD include a header accepting the asset's content type as specified in the manifest. Additionally, the client library SHOULD specify the compression encoding the client library is capable of handling. Example headers: ```text accept: image/jpeg, */* accept-encoding: br, gzip ``` A conformant client library MUST also include any header (key, value) pairs included in [`assetRequestHeaders`](/technical-specs/expo-updates-1#manifest-extensions) for this asset key. ## Asset response An asset located at a particular URL MUST NOT be changed or removed since client libraries may fetch assets for any update at any time. A conformant client MUST verify that the base64url-encoded SHA-256 hash of the asset matches the `hash` field for the asset from the manifest. ### Asset response headers The asset MUST be encoded using a compression format that the client supports according to the request's `accept-encoding` header. The server MAY serve uncompressed assets. The response MUST include a `content-type` header with the MIME type of the asset. For example: ```text content-encoding: br content-type: application/javascript ``` An asset is RECOMMENDED to be served with a `cache-control` header set to a long duration as an asset located at a given URL must not change. For example: ```text cache-control: public, max-age=31536000, immutable ``` ### Compression Assets SHOULD be capable of being served with [Gzip](https://www.gnu.org/software/gzip/) and [Brotli](https://github.com/google/brotli) compression. ## Code signing Expo Updates supports code signing the manifest and directive bodies. Code signing the manifest also transitively signs the assets since their hashes are present in the manifest and verified by a conformant client. A conformant client MAY request the manifest or directive be signed using a private key, and then MUST verify the signature of the manifest or directive using the corresponding code signing certificate before it is used or any corresponding manifest assets are downloaded. The client MUST verify that the signing certificate is either a self-signed, trusted root certificate or is in a certificate chain signed by a trusted root certificate. In either case, the root certificate MUST be embedded in the application or device's operating system. --- --- title: app.json / app.config.js description: A reference of available properties in Expo app config. --- # app.json / app.config.js A reference of available properties in Expo app config. The following is a list of properties that are available for you under the `"expo"` key in **app.json** or **app.config.json**. These properties can be passed to the top level object of **app.config.js** or **app.config.ts**. [Configuration with app config](/workflow/configuration) — For information on app configuration, the differences between various app config files, and how to use them dynamically. ## Properties ### `name` Type: `string` The name of your app as it appears both within Expo Go and on your home screen as a standalone app. Existing React Native app? To change the name of your app, edit the 'Display Name' field in Xcode and the `app_name` string in `android/app/src/main/res/values/strings.xml` ### `description` Type: `string` A short description of what your app is and why it is great. ### `slug` Type: `string` A URL-friendly name for your project that is unique across your account. ### `owner` Type: `string` The name of the Expo account that owns the project. This is useful for teams collaborating on a project. If not provided, the owner defaults to the username of the current user. ### `currentFullName` Type: `string` The auto generated Expo account name and slug used for display purposes. It is not meant to be set directly. Formatted like `@username/slug`. When unauthenticated, the username is `@anonymous`. For published projects, this value may change when a project is transferred between accounts or renamed. ### `originalFullName` Type: `string` The auto generated Expo account name and slug used for services like Notifications and AuthSession proxy. It is not meant to be set directly. Formatted like `@username/slug`. When unauthenticated, the username is `@anonymous`. For published projects, this value will not change when a project is transferred between accounts or renamed. ### `sdkVersion` Type: `string` The Expo sdkVersion to run the project on. This should line up with the version specified in your package.json. ### `runtimeVersion` One of types: - `string` matching the following pattern: `^[a-zA-Z\d][a-zA-Z\d._+()-]{0,254}$` - `string` matching the following pattern: `^exposdk:((\d+\.\d+\.\d+)|(UNVERSIONED))$` - An `object` with the following properties: #### `policy` Type: `enum` • Path: `runtimeVersion.policy` Valid values: `nativeVersion`, `sdkVersion`, `appVersion`, `fingerprint`. Property indicating compatibility between a build's native code and an OTA update. ### `version` Type: `string` Your app version. In addition to this field, you'll also use `ios.buildNumber` and `android.versionCode` — read more about how to version your app [here](https://docs.expo.dev/distribution/app-stores/#versioning-your-app). On iOS this corresponds to `CFBundleShortVersionString`, and on Android, this corresponds to `versionName`. The required format can be found [here](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring). Existing React Native app? To change your app version, edit the 'Version' field in Xcode and the `versionName` string in `android/app/build.gradle` ### `platforms` Type: `array` Platforms that your project explicitly supports. If not specified, it defaults to `["ios", "android"]`. Example `[ "ios", "android", "web" ]` ### `githubUrl` Type: `string` If you would like to share the source code of your app on Github, enter the URL for the repository here and it will be linked to from your Expo project page. Example `"https://github.com/expo/expo"` ### `orientation` Type: `enum` Locks your app to a specific orientation with portrait or landscape. Defaults to no lock. Valid values: `default`, `portrait`, `landscape` ### `userInterfaceStyle` Type: `enum` Configuration to force the app to always use the light or dark user-interface appearance, such as "dark mode", or make it automatically adapt to the system preferences. If not provided, defaults to `light`. Requires `expo-system-ui` be installed in your project to work on Android. ### `backgroundColor` Type: `string` The background color for your app, behind any of your React views. This is also known as the root view background color. Requires `expo-system-ui` be installed in your project to work on iOS. 6 character long hex color string, for example, `'#000000'`. Default is white: `'#ffffff'` ### `primaryColor` Type: `string` On Android, this will determine the color of your app in the multitasker. Currently this is not used on iOS, but it may be used for other purposes in the future. 6 character long hex color string, for example, `'#000000'` ### `icon` Type: `string` Local path or remote URL to an image to use for your app's icon. We recommend that you use a 1024x1024 png file. This icon will appear on the home screen and within the Expo Go app. Existing React Native app? To change your app's icon, edit or replace the files in `ios//Assets.xcassets/AppIcon.appiconset` (we recommend using Xcode), and `android/app/src/main/res/mipmap-`. Be sure to follow the guidelines for each platform ([iOS](https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/app-icon/), [Android 7.1 and below](https://material.io/design/iconography/#icon-treatments), and [Android 8+](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive)) and to provide your new icon in each existing size. ### `notification` Type: `object` @deprecated in favor of the expo-notifications config plugin. This field will be removed in SDK 55. Configuration for remote (push) notifications. #### `icon` Type: `string` • Path: `notification.icon` (Android only) Local path or remote URL to an image to use as the icon for push notifications. 96x96 png grayscale with transparency. We recommend following [Google's design guidelines](https://material.io/design/iconography/product-icons.html#design-principles). If not provided, defaults to your app icon. #### `color` Type: `string` • Path: `notification.color` (Android only) Tint color for the push notification image when it appears in the notification tray. Defaults to `#ffffff` 6 character long hex color string, for example, `'#000000'` #### `iosDisplayInForeground` Type: `boolean` • Path: `notification.iosDisplayInForeground` Whether or not to display notifications when the app is in the foreground on iOS. `_displayInForeground` option in the individual push notification message overrides this option. [Learn more.](https://docs.expo.dev/push-notifications/receiving-notifications/#foreground-notification-behavior) Defaults to `false`. #### `androidMode` Type: `enum` • Path: `notification.androidMode` Show each push notification individually (`default`) or collapse into one (`collapse`). #### `androidCollapsedTitle` Type: `string` • Path: `notification.androidCollapsedTitle` If `androidMode` is set to `collapse`, this title is used for the collapsed notification message. For example, `'#{unread_notifications} new interactions'`. ### `androidStatusBar` Type: `object` Configuration for the status bar on Android. For more details navigate to [Configuring StatusBar](https://docs.expo.dev/guides/configuring-statusbar/). #### `barStyle` Type: `enum` • Path: `androidStatusBar.barStyle` Configures the status bar icons to have a light or dark color. Valid values: `light-content`, `dark-content`. Defaults to `dark-content` #### `backgroundColor` Type: `string` • Path: `androidStatusBar.backgroundColor` Specifies the background color of the status bar. Defaults to `#00000000` (transparent) for `dark-content` bar style and `#00000088` (semi-transparent black) for `light-content` bar style 6 character long hex color string `'#RRGGBB'`, for example, `'#000000'` for black. Or 8 character long hex color string `'#RRGGBBAA'`, for example, `'#00000088'` for semi-transparent black. #### `hidden` Type: `boolean` • Path: `androidStatusBar.hidden` Instructs the system whether the status bar should be visible or not. Defaults to `false` #### `translucent` Type: `boolean` • Path: `androidStatusBar.translucent` When false, the system status bar pushes the content of your app down (similar to `position: relative`). When true, the status bar floats above the content in your app (similar to `position: absolute`). Defaults to `true` to match the iOS status bar behavior (which can only float above content). Explicitly setting this property to `true` will add `android:windowTranslucentStatus` to `styles.xml` and may cause unexpected keyboard behavior on Android when using the `softwareKeyboardLayoutMode` set to `resize`. In this case you will have to use `KeyboardAvoidingView` to manage the keyboard layout. ### `androidNavigationBar` Type: `object` Configuration for the bottom navigation bar on Android. Can be used to configure the `expo-navigation-bar` module in EAS Build. #### `visible` Type: `enum` • Path: `androidNavigationBar.visible` Determines how and when the navigation bar is shown. [Learn more](https://developer.android.com/training/system-ui/immersive). Requires `expo-navigation-bar` be installed in your project. Valid values: `leanback`, `immersive`, `sticky-immersive` `leanback` results in the navigation bar being hidden until the first touch gesture is registered. `immersive` results in the navigation bar being hidden until the user swipes up from the edge where the navigation bar is hidden. `sticky-immersive` is identical to `'immersive'` except that the navigation bar will be semi-transparent and will be hidden again after a short period of time. #### `barStyle` Type: `enum` • Path: `androidNavigationBar.barStyle` Configure the navigation bar icons to have a light or dark color. Supported on Android Oreo and newer. Valid values: `'light-content'`, `'dark-content'` #### `backgroundColor` Type: `string` • Path: `androidNavigationBar.backgroundColor` Specifies the background color of the navigation bar. 6 character long hex color string, for example, `'#000000'` #### `enforceContrast` Type: `boolean` • Path: `androidNavigationBar.enforceContrast` Determines whether the operating system should keep the navigation bar translucent to provide contrast between the navigation buttons and app content. Defaults to true. ### `developmentClient` Type: `object` Settings that apply specifically to running this app in a development client #### `silentLaunch` Type: `boolean` • Path: `developmentClient.silentLaunch` If true, the app will launch in a development client with no additional dialogs or progress indicators, just like in a standalone app. ### `scheme` One of types: - `string` matching the following pattern: `^[a-z][a-z0-9+.-]*$` `{ "type": "array", "items": { "type": "string", "pattern": "^[a-z][a-z0-9+.-]*$" } }` URL scheme(s) to link into your app. For example, if we set this to `'demo'`, then demo:// URLs would open your app when tapped. This is a build-time configuration, it has no effect in Expo Go. String beginning with a **lowercase** letter followed by any combination of **lowercase** letters, digits, "+", "." or "-" Existing React Native app? To change your app's scheme, replace all occurrences of the old scheme in `Info.plist` and `AndroidManifest.xml` ### `extra` Type: `object` Any extra fields you want to pass to your experience. Values are accessible via `Constants.expoConfig.extra` ([Learn more](https://docs.expo.dev/versions/latest/sdk/constants/#constantsmanifest)) ### `updates` Type: `object` Configuration for the expo-updates library #### `enabled` Type: `boolean` • Path: `updates.enabled` Whether the updates system will run. Defaults to true. If set to false, builds will only use code and assets bundled at time of build. #### `checkAutomatically` Type: `enum` • Path: `updates.checkAutomatically` By default, expo-updates will check for updates every time the app is loaded. Set this to `ON_ERROR_RECOVERY` to disable automatic checking unless recovering from an error. Set this to `NEVER` to disable automatic checking. Valid values: `ON_LOAD` (default value), `ON_ERROR_RECOVERY`, `WIFI_ONLY`, `NEVER` #### `useEmbeddedUpdate` Type: `boolean` • Path: `updates.useEmbeddedUpdate` Whether to load the embedded update. Defaults to true. If set to false, an update will be fetched at launch. When set to false, ensure that `checkAutomatically` is set to `ON_LOAD` and `fallbackToCacheTimeout` is large enough for the initial remote update to download. This should not be used in production. #### `fallbackToCacheTimeout` Type: `number` • Path: `updates.fallbackToCacheTimeout` How long (in ms) to wait for the app to check for and fetch a new update upon launch before falling back to the most recent update already present on the device. Defaults to 0. Must be between 0 and 300000 (5 minutes). If the startup update check takes longer than this value, any update downloaded during the check will be applied upon the next app launch. #### `url` Type: `string` • Path: `updates.url` URL from which expo-updates will fetch update manifests #### `codeSigningCertificate` Type: `string` • Path: `updates.codeSigningCertificate` Local path of a PEM-formatted X.509 certificate used for verifying codesigned updates. When provided, all updates downloaded by expo-updates must be signed. #### `codeSigningMetadata` Type: `object` • Path: `updates.codeSigningMetadata` Metadata for `codeSigningCertificate` ##### `alg` Type: `enum` • Path: `updates.codeSigningMetadata.alg` Algorithm used to generate manifest code signing signature. Valid values: `rsa-v1_5-sha256` ##### `keyid` Type: `string` • Path: `updates.codeSigningMetadata.keyid` Identifier for the key in the certificate. Used to instruct signing mechanisms when signing or verifying signatures. #### `requestHeaders` Type: `object` • Path: `updates.requestHeaders` Extra HTTP headers to include in HTTP requests made by `expo-updates` when fetching manifests or assets. These may override preset headers. #### `assetPatternsToBeBundled` Type: `array` • Path: `updates.assetPatternsToBeBundled` Array of glob patterns specifying which files should be included in updates. Glob patterns are relative to the project root. A value of `['**']` will match all asset files within the project root. When not supplied all asset files will be included. Example: Given a value of `['app/images/**/*.png', 'app/fonts/**/*.woff']` all `.png` files in all subdirectories of `app/images` and all `.woff` files in all subdirectories of `app/fonts` will be included in updates. #### `disableAntiBrickingMeasures` Type: `boolean` • Path: `updates.disableAntiBrickingMeasures` Whether to disable the built-in expo-updates anti-bricking measures. Defaults to false. If set to true, this will allow overriding certain configuration options from the JS API, which is liable to leave an app in a bricked state if not done carefully. This should not be used in production. #### `useNativeDebug` Type: `boolean` • Path: `updates.useNativeDebug` Enable debugging of native code with updates enabled. Defaults to false. If set to true, the EX_UPDATES_NATIVE_DEBUG environment variable will be set in Podfile.properties.json and gradle.properties. This causes Xcode and Android Studio debug builds to be built with expo-updates enabled, and JS debugging (with dev client or packager) disabled. This should not be used in production. #### `enableBsdiffPatchSupport` Type: `boolean` • Path: `updates.enableBsdiffPatchSupport` Whether to enable support for downloading and applying bundle diffs using bsdiff. Defaults to false. ### `locales` Type: `object` Provide per-locale values for System Dialog prompts such as Permissions Boxes. Platform-specific locale strings should be nested under `ios` and `android` keys. Existing React Native app? To add or change language and localization information in your iOS app, you need to use Xcode. ### `plugins` Type: `array` Config plugins for adding extra functionality to your project. [Learn more](https://docs.expo.dev/guides/config-plugins/). Existing React Native app? Plugins that add modifications can only be used with [prebuilding](https://expo.fyi/prebuilding) and managed EAS Build ### `splash` Type: `object` Configuration for loading and splash screen for standalone apps. Existing React Native app? To change your app's icon, edit or replace the files in `ios//Assets.xcassets/AppIcon.appiconset` (we recommend using Xcode), and `android/app/src/main/res/mipmap-` (Android Studio can [generate the appropriate image files for you](https://developer.android.com/studio/write/image-asset-studio)). Be sure to follow the guidelines for each platform ([iOS](https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/app-icon/), [Android 7.1 and below](https://material.io/design/iconography/#icon-treatments), and [Android 8+](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive)) and to provide your new icon in each required size. #### `backgroundColor` Type: `string` • Path: `splash.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` Existing React Native app? For Android, edit the `colorPrimary` item in `android/app/src/main/res/values/colors.xml` #### `resizeMode` Type: `enum` • Path: `splash.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover` or `contain`, defaults to `contain`. #### `image` Type: `string` • Path: `splash.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ### `jsEngine` Type: `enum` @deprecated This field will be removed in a future release. When it is removed, you can continue using JavaScriptCore instead of Hermes by following the instructions in [@react-native-community/javascriptcore](https://github.com/react-native-community/javascriptcore). Specifies the JavaScript engine for Android apps. Defaults to `hermes`. Valid values: `hermes`, `jsc`. Existing React Native app? To change the JavaScript engine, update the `expo.jsEngine` value in `ios/Podfile.properties.json` or `android/gradle.properties` ### `newArchEnabled` Type: `boolean` A Boolean value that indicates whether the app should use the new architecture. Defaults to true. ### `buildCacheProvider` Type: `undefined` Enable downloading cached builds from remote. ### `ios` Type: `object` Configuration that is specific to the iOS platform. #### `appleTeamId` Type: `string` • Path: `ios.appleTeamId` The Apple development team ID to use for all native targets. You can find your team ID in [the Apple Developer Portal](https://developer.apple.com/help/account/manage-your-team/locate-your-team-id/). #### `publishManifestPath` Type: `string` • Path: `ios.publishManifestPath` The manifest for the iOS version of your app will be written to this path during publish. #### `publishBundlePath` Type: `string` • Path: `ios.publishBundlePath` The bundle for the iOS version of your app will be written to this path during publish. #### `bundleIdentifier` Type: `string` • Path: `ios.bundleIdentifier` The bundle identifier for your iOS standalone app. You make it up, but it needs to be unique on the App Store. See [this StackOverflow question](http://stackoverflow.com/questions/11347470/what-does-bundle-identifier-mean-in-the-ios-project). iOS bundle identifier notation unique name for your app. For example, `host.exp.expo`, where `exp.host` is our domain and `expo` is our app name. Existing React Native app? Set this value in `info.plist` under `CFBundleIdentifier` #### `buildNumber` Type: `string` • Path: `ios.buildNumber` Build number for your iOS standalone app. Corresponds to `CFBundleVersion` and must match Apple's [specified format](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion). (Note: Transporter will pull the value for `Version Number` from `expo.version` and NOT from `expo.ios.buildNumber`.) Existing React Native app? Set this value in `info.plist` under `CFBundleVersion` #### `backgroundColor` Type: `string` • Path: `ios.backgroundColor` The background color for your iOS app, behind any of your React views. Overrides the top-level `backgroundColor` key if it is present. Requires `expo-system-ui` be installed in your project to work on iOS. 6 character long hex color string, for example, `'#000000'` #### `scheme` One of types: - `string` matching the following pattern: `^[a-z][a-z0-9+.-]*$` `{ "type": "array", "items": { "type": "string", "pattern": "^[a-z][a-z0-9+.-]*$" } }` URL scheme(s) to link into your iOS app. Schemes added to this field will be merged with the schemes in the `scheme` key at the top level of the config. String beginning with a **lowercase** letter followed by any combination of **lowercase** letters, digits, "+", "." or "-" Existing React Native app? To change your app's scheme, replace all occurrences of the old scheme in `Info.plist` and `AndroidManifest.xml` #### `icon` One of types: - `string` matching the following pattern: `\.icon$` - `string` - An `object` with the following properties: ##### `light` Type: `string` • Path: `ios.icon.light` The light icon. It will appear when neither dark nor tinted icons are used, or if they are not provided. ##### `dark` Type: `string` • Path: `ios.icon.dark` The dark icon. It will appear for the app when the user's system appearance is dark. See Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/app-icons#iOS-iPadOS) for more information. ##### `tinted` Type: `string` • Path: `ios.icon.tinted` The tinted icon. It will appear for the app when the user's system appearance is tinted. See Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/app-icons#iOS-iPadOS) for more information. Local path or remote URL to an image to use for your app's icon on iOS. Alternatively, an object specifying different icons for various system appearances (e.g., dark, tinted) can be provided. You can also provide a path to a .icon directory. If specified, this overrides the top-level `icon` key. Use a 1024x1024 icon which follows Apple's interface guidelines for icons, including color profile and transparency. Expo will generate the other required sizes. This icon will appear on the home screen and within the Expo Go app. #### `appStoreUrl` Type: `string` • Path: `ios.appStoreUrl` URL to your app on the Apple App Store, if you have deployed it there. This is used to link to your store page from your Expo project page if your app is public. Example `"https://apps.apple.com/us/app/expo-client/id982107779"` #### `bitcode` Type: `undefined` • Path: `ios.bitcode` Enable iOS Bitcode optimizations in the native build. Accepts the name of an iOS build configuration to enable for a single configuration and disable for all others, e.g. Debug, Release. Not available in Expo Go. Defaults to `undefined` which uses the template's predefined settings. #### `config` Type: `object` • Path: `ios.config` Note: This property key is not included in the production manifest and will evaluate to `undefined`. It is used internally only in the build process, because it contains API keys that some may want to keep private. ##### `branch` Type: `object` • Path: `ios.config.branch` [Branch](https://branch.io/) key to hook up Branch linking services. ##### `apiKey` Type: `string` • Path: `ios.config.branch.apiKey` Your Branch API key ##### `usesNonExemptEncryption` Type: `boolean` • Path: `ios.config.usesNonExemptEncryption` Sets `ITSAppUsesNonExemptEncryption` in the standalone ipa's Info.plist to the given boolean value. ##### `googleMapsApiKey` Type: `string` • Path: `ios.config.googleMapsApiKey` [Google Maps iOS SDK](https://developers.google.com/maps/documentation/ios-sdk/start) key for your standalone app. ##### `googleMobileAdsAppId` Type: `string` • Path: `ios.config.googleMobileAdsAppId` [Google Mobile Ads App ID](https://support.google.com/admob/answer/6232340) Google AdMob App ID. ##### `googleMobileAdsAutoInit` Type: `boolean` • Path: `ios.config.googleMobileAdsAutoInit` A boolean indicating whether to initialize Google App Measurement and begin sending user-level event data to Google immediately when the app starts. The default in Expo (Go and in standalone apps) is `false`. [Sets the opposite of the given value to the following key in `Info.plist`.](https://developers.google.com/admob/ios/eu-consent#delay_app_measurement_optional) #### `googleServicesFile` Type: `string` • Path: `ios.googleServicesFile` [Firebase Configuration File](https://support.google.com/firebase/answer/7015592) Location of the `GoogleService-Info.plist` file for configuring Firebase. #### `supportsTablet` Type: `boolean` • Path: `ios.supportsTablet` Whether your standalone iOS app supports tablet screen sizes. Defaults to `false`. Existing React Native app? Set this value in `info.plist` under `UISupportedInterfaceOrientations~ipad` #### `isTabletOnly` Type: `boolean` • Path: `ios.isTabletOnly` If true, indicates that your standalone iOS app does not support handsets, and only supports tablets. Existing React Native app? Set this value in `info.plist` under `UISupportedInterfaceOrientations` #### `requireFullScreen` Type: `boolean` • Path: `ios.requireFullScreen` If true, indicates that your standalone iOS app does not support Slide Over and Split View on iPad. Defaults to `false` Existing React Native app? Use Xcode to set `UIRequiresFullScreen` #### `userInterfaceStyle` Type: `enum` • Path: `ios.userInterfaceStyle` Configuration to force the app to always use the light or dark user-interface appearance, such as "dark mode", or make it automatically adapt to the system preferences. If not provided, defaults to `light`. #### `infoPlist` Type: `object` • Path: `ios.infoPlist` Dictionary of arbitrary configuration to add to your standalone app's native Info.plist. Applied prior to all other Expo-specific configuration. No other validation is performed, so use this at your own risk of rejection from the App Store. #### `entitlements` Type: `object` • Path: `ios.entitlements` Dictionary of arbitrary configuration to add to your standalone app's native \*.entitlements (plist). Applied prior to all other Expo-specific configuration. No other validation is performed, so use this at your own risk of rejection from the App Store. #### `privacyManifests` Type: `object` • Path: `ios.privacyManifests` Dictionary of privacy manifest definitions to add to your app's native PrivacyInfo.xcprivacy file. [Learn more](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files) ##### `NSPrivacyAccessedAPITypes` Type: `array` • Path: `ios.privacyManifests.NSPrivacyAccessedAPITypes` A list of required reasons of why your app uses restricted API categories. [Learn more](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api) ##### `NSPrivacyAccessedAPIType` Type: `string` • Path: `ios.privacyManifests.NSPrivacyAccessedAPITypes.NSPrivacyAccessedAPIType` A string that identifies the category of required reason APIs your app uses ##### `NSPrivacyAccessedAPITypeReasons` Type: `array` • Path: `ios.privacyManifests.NSPrivacyAccessedAPITypes.NSPrivacyAccessedAPITypeReasons` A list of reasons for a specific category. ##### `NSPrivacyTrackingDomains` Type: `array` • Path: `ios.privacyManifests.NSPrivacyTrackingDomains` A list of domains that your app uses for tracking. ##### `NSPrivacyTracking` Type: `boolean` • Path: `ios.privacyManifests.NSPrivacyTracking` A Boolean that indicates whether your app or third-party SDK uses data for tracking. ##### `NSPrivacyCollectedDataTypes` Type: `array` • Path: `ios.privacyManifests.NSPrivacyCollectedDataTypes` A list of collected data types that your app uses. ##### `NSPrivacyCollectedDataType` Type: `string` • Path: `ios.privacyManifests.NSPrivacyCollectedDataTypes.NSPrivacyCollectedDataType` ##### `NSPrivacyCollectedDataTypeLinked` Type: `boolean` • Path: `ios.privacyManifests.NSPrivacyCollectedDataTypes.NSPrivacyCollectedDataTypeLinked` ##### `NSPrivacyCollectedDataTypeTracking` Type: `boolean` • Path: `ios.privacyManifests.NSPrivacyCollectedDataTypes.NSPrivacyCollectedDataTypeTracking` ##### `NSPrivacyCollectedDataTypePurposes` Type: `array` • Path: `ios.privacyManifests.NSPrivacyCollectedDataTypes.NSPrivacyCollectedDataTypePurposes` #### `associatedDomains` Type: `array` • Path: `ios.associatedDomains` An array that contains Associated Domains for the standalone app. [Learn more](https://developer.apple.com/documentation/safariservices/supporting_associated_domains). Entries must follow the format `applinks:[:port number]`. [Learn more](https://developer.apple.com/documentation/safariservices/supporting_associated_domains). Existing React Native app? Build with EAS, or use Xcode to enable this capability manually. [Learn more](https://developer.apple.com/documentation/safariservices/supporting_associated_domains). #### `usesIcloudStorage` Type: `boolean` • Path: `ios.usesIcloudStorage` A boolean indicating if the app uses iCloud Storage for `DocumentPicker`. See `DocumentPicker` docs for details. Existing React Native app? Use Xcode, or ios.entitlements to configure this. #### `usesAppleSignIn` Type: `boolean` • Path: `ios.usesAppleSignIn` A boolean indicating if the app uses Apple Sign-In. See `AppleAuthentication` docs for details. #### `usesBroadcastPushNotifications` Type: `boolean` • Path: `ios.usesBroadcastPushNotifications` A boolean indicating if the app uses Push Notifications Broadcast option for Push Notifications capability. If true, EAS CLI will use the value during capability syncing. If EAS CLI is not used, this configuration will not have any effect unless another tool is used to operate on it, so enable the capability manually on the Apple Developer Portal in that case. #### `accessesContactNotes` Type: `boolean` • Path: `ios.accessesContactNotes` A Boolean value that indicates whether the app may access the notes stored in contacts. You must [receive permission from Apple](https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_contacts_notes) before you can submit your app for review with this capability. #### `splash` Type: `object` • Path: `ios.splash` Configuration for loading and splash screen for standalone iOS apps. ##### `backgroundColor` Type: `string` • Path: `ios.splash.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` ##### `resizeMode` Type: `enum` • Path: `ios.splash.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover` or `contain`, defaults to `contain`. ##### `image` Type: `string` • Path: `ios.splash.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ##### `tabletImage` Type: `string` • Path: `ios.splash.tabletImage` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ##### `dark` Type: `object` • Path: `ios.splash.dark` Configuration for loading and splash screen for standalone iOS apps in dark mode. ##### `backgroundColor` Type: `string` • Path: `ios.splash.dark.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` ##### `resizeMode` Type: `enum` • Path: `ios.splash.dark.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover` or `contain`, defaults to `contain`. ##### `image` Type: `string` • Path: `ios.splash.dark.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ##### `tabletImage` Type: `string` • Path: `ios.splash.dark.tabletImage` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. #### `jsEngine` Type: `enum` • Path: `ios.jsEngine` @deprecated This field will be removed in a future release. When it is removed, you can continue using JavaScriptCore instead of Hermes by following the instructions in [@react-native-community/javascriptcore](https://github.com/react-native-community/javascriptcore). Specifies the JavaScript engine for iOS apps. Not supported in Expo Go. Defaults to `hermes`. Valid values: `hermes`, `jsc`. Existing React Native app? To change the JavaScript engine, update the `expo.jsEngine` value in `ios/Podfile.properties.json` #### `newArchEnabled` Type: `boolean` • Path: `ios.newArchEnabled` A Boolean value that indicates whether the iOS app should use the new architecture. #### `runtimeVersion` One of types: - `string` matching the following pattern: `^[a-zA-Z\d][a-zA-Z\d._+()-]{0,254}$` - `string` matching the following pattern: `^exposdk:((\d+\.\d+\.\d+)|(UNVERSIONED))$` - An `object` with the following properties: ##### `policy` Type: `enum` • Path: `ios.runtimeVersion.policy` Valid values: `nativeVersion`, `sdkVersion`, `appVersion`, `fingerprint`. Property indicating compatibility between an iOS build's native code and an OTA update for the iOS platform. If provided, this will override the value of the top level `runtimeVersion` key on iOS. #### `version` Type: `string` • Path: `ios.version` Your iOS app version. Takes precedence over the root `version` field. In addition to this field, you'll also use `ios.buildNumber` — read more about how to version your app [here](https://docs.expo.dev/distribution/app-stores/#versioning-your-app). This corresponds to `CFBundleShortVersionString`. The required format can be found [here](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring). Existing React Native app? To change your app version, edit the 'Version' field in Xcode\` ### `android` Type: `object` Configuration that is specific to the Android platform. #### `publishManifestPath` Type: `string` • Path: `android.publishManifestPath` The manifest for the Android version of your app will be written to this path during publish. #### `publishBundlePath` Type: `string` • Path: `android.publishBundlePath` The bundle for the Android version of your app will be written to this path during publish. #### `package` Type: `string` • Path: `android.package` The package name for your Android standalone app. You make it up, but it needs to be unique on the Play Store. See [this StackOverflow question](http://stackoverflow.com/questions/6273892/android-package-name-convention). Reverse DNS notation unique name for your app. Valid Android Application ID. For example, `com.example.app`, where `com.example` is our domain and `app` is our app. The name may only contain lowercase and uppercase letters (a-z, A-Z), numbers (0-9) and underscores (_), separated by periods (.). Each component of the name should start with a lowercase letter. Existing React Native app? This is set in `android/app/build.gradle` as `applicationId` as well as in your `AndroidManifest.xml` file (multiple places). #### `versionCode` Type: `integer` • Path: `android.versionCode` Version number required by Google Play. Increment by one for each release. Must be a positive integer. [Learn more](https://developer.android.com/studio/publish/versioning.html) Existing React Native app? This is set in `android/app/build.gradle` as `versionCode` #### `backgroundColor` Type: `string` • Path: `android.backgroundColor` The background color for your Android app, behind any of your React views. Overrides the top-level `backgroundColor` key if it is present. 6 character long hex color string, for example, `'#000000'` Existing React Native app? This is set in `android/app/src/main/AndroidManifest.xml` under `android:windowBackground` #### `userInterfaceStyle` Type: `enum` • Path: `android.userInterfaceStyle` Configuration to force the app to always use the light or dark user-interface appearance, such as "dark mode", or make it automatically adapt to the system preferences. If not provided, defaults to `light`. Requires `expo-system-ui` be installed in your project to work on Android. #### `scheme` One of types: - `string` matching the following pattern: `^[a-z][a-z0-9+.-]*$` `{ "type": "array", "items": { "type": "string", "pattern": "^[a-z][a-z0-9+.-]*$" } }` URL scheme(s) to link into your Android app. Schemes added to this field will be merged with the schemes in the `scheme` key at the top level of the config. String beginning with a **lowercase** letter followed by any combination of **lowercase** letters, digits, "+", "." or "-" Existing React Native app? To change your app's scheme, replace all occurrences of the old scheme in `Info.plist` and `AndroidManifest.xml` #### `icon` Type: `string` • Path: `android.icon` Local path or remote URL to an image to use for your app's icon on Android. If specified, this overrides the top-level `icon` key. We recommend that you use a 1024x1024 png file (transparency is recommended for the Google Play Store). This icon will appear on the home screen and within the Expo Go app. #### `adaptiveIcon` Type: `object` • Path: `android.adaptiveIcon` Settings for an Adaptive Launcher Icon on Android. [Learn more](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive) ##### `foregroundImage` Type: `string` • Path: `android.adaptiveIcon.foregroundImage` Local path or remote URL to an image to use for your app's icon on Android. If specified, this overrides the top-level `icon` and the `android.icon` keys. Should follow the [specified guidelines](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive). This icon will appear on the home screen. ##### `monochromeImage` Type: `string` • Path: `android.adaptiveIcon.monochromeImage` Local path or remote URL to an image representing the Android 13+ monochromatic icon. Should follow the [specified guidelines](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive). This icon will appear on the home screen when the user enables 'Themed icons' in system settings on a device running Android 13+. ##### `backgroundImage` Type: `string` • Path: `android.adaptiveIcon.backgroundImage` Local path or remote URL to a background image for your app's Adaptive Icon on Android. If specified, this overrides the `backgroundColor` key. Must have the same dimensions as `foregroundImage`, and has no effect if `foregroundImage` is not specified. Should follow the [specified guidelines](https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive). ##### `backgroundColor` Type: `string` • Path: `android.adaptiveIcon.backgroundColor` Color to use as the background for your app's Adaptive Icon on Android. Defaults to white, `#FFFFFF`. Has no effect if `foregroundImage` is not specified. 6 character long hex color string, for example, `'#000000'` #### `playStoreUrl` Type: `string` • Path: `android.playStoreUrl` URL to your app on the Google Play Store, if you have deployed it there. This is used to link to your store page from your Expo project page if your app is public. Example `"https://play.google.com/store/apps/details?id=host.exp.exponent"` #### `permissions` Type: `array` • Path: `android.permissions` A list of permissions to add to the app `AndroidManifest.xml` during prebuild. For example: `['android.permission.SCHEDULE_EXACT_ALARM']` Existing React Native app? To change the permissions your app requests, edit `AndroidManifest.xml` directly. To prevent your app from requesting specific permissions (which may automatically be added through an installed native package), add those permissions to `AndroidManifest.xml` along with a `tools:node="remove"` tag. #### `blockedPermissions` Type: `array` • Path: `android.blockedPermissions` List of permissions to block in the final `AndroidManifest.xml`. This is useful for removing permissions that are added by native package `AndroidManifest.xml` files which are merged into the final manifest. Internally this feature uses the `tools:node="remove"` XML attribute to remove permissions. Not available in Expo Go. #### `googleServicesFile` Type: `string` • Path: `android.googleServicesFile` [Firebase Configuration File](https://support.google.com/firebase/answer/7015592) Location of the `google-services.json` file for configuring Firebase. Including this key automatically enables FCM in your standalone app. Existing React Native app? Add or edit the file directly at `android/app/google-services.json` #### `config` Type: `object` • Path: `android.config` Note: This property key is not included in the production manifest and will evaluate to `undefined`. It is used internally only in the build process, because it contains API keys that some may want to keep private. ##### `branch` Type: `object` • Path: `android.config.branch` [Branch](https://branch.io/) key to hook up Branch linking services. ##### `apiKey` Type: `string` • Path: `android.config.branch.apiKey` Your Branch API key ##### `googleMaps` Type: `object` • Path: `android.config.googleMaps` [Google Maps Android SDK](https://developers.google.com/maps/documentation/android-api/signup) configuration for your standalone app. ##### `apiKey` Type: `string` • Path: `android.config.googleMaps.apiKey` Your Google Maps Android SDK API key ##### `googleMobileAdsAppId` Type: `string` • Path: `android.config.googleMobileAdsAppId` [Google Mobile Ads App ID](https://support.google.com/admob/answer/6232340) Google AdMob App ID. ##### `googleMobileAdsAutoInit` Type: `boolean` • Path: `android.config.googleMobileAdsAutoInit` A boolean indicating whether to initialize Google App Measurement and begin sending user-level event data to Google immediately when the app starts. The default in Expo (Client and in standalone apps) is `false`. [Sets the opposite of the given value to the following key in `Info.plist`](https://developers.google.com/admob/ios/eu-consent#delay_app_measurement_optional) #### `splash` Type: `object` • Path: `android.splash` Configuration for loading and splash screen for managed and standalone Android apps. ##### `backgroundColor` Type: `string` • Path: `android.splash.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` ##### `resizeMode` Type: `enum` • Path: `android.splash.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover`, `contain` or `native`, defaults to `contain`. ##### `image` Type: `string` • Path: `android.splash.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ##### `mdpi` Type: `string` • Path: `android.splash.mdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Natural sized image (baseline)` ##### `hdpi` Type: `string` • Path: `android.splash.hdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 1.5x` ##### `xhdpi` Type: `string` • Path: `android.splash.xhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 2x` ##### `xxhdpi` Type: `string` • Path: `android.splash.xxhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 3x` ##### `xxxhdpi` Type: `string` • Path: `android.splash.xxxhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 4x` ##### `dark` Type: `object` • Path: `android.splash.dark` Configuration for loading and splash screen for managed and standalone Android apps in dark mode. ##### `backgroundColor` Type: `string` • Path: `android.splash.dark.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` ##### `resizeMode` Type: `enum` • Path: `android.splash.dark.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover`, `contain` or `native`, defaults to `contain`. ##### `image` Type: `string` • Path: `android.splash.dark.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. ##### `mdpi` Type: `string` • Path: `android.splash.dark.mdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Natural sized image (baseline)` ##### `hdpi` Type: `string` • Path: `android.splash.dark.hdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 1.5x` ##### `xhdpi` Type: `string` • Path: `android.splash.dark.xhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 2x` ##### `xxhdpi` Type: `string` • Path: `android.splash.dark.xxhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 3x` ##### `xxxhdpi` Type: `string` • Path: `android.splash.dark.xxxhdpi` Local path or remote URL to an image to fill the background of the loading screen in "native" mode. Image size and aspect ratio are up to you. [Learn more](https://developer.android.com/training/multiscreen/screendensities) `Scale 4x` #### `intentFilters` Type: `array` • Path: `android.intentFilters` Configuration for setting an array of custom intent filters in Android manifest. [Learn more](https://developer.android.com/guide/components/intents-filters) Existing React Native app? This is set in `AndroidManifest.xml` directly. [Learn more.](https://developer.android.com/guide/components/intents-filters) Example `[ { "autoVerify": true, "action": "VIEW", "data": { "scheme": "https", "host": "*.example.com" }, "category": [ "BROWSABLE", "DEFAULT" ] } ]` ##### `autoVerify` Type: `boolean` • Path: `android.intentFilters.autoVerify` You may also use an intent filter to set your app as the default handler for links (without showing the user a dialog with options). To do so use `true` and then configure your server to serve a JSON file verifying that you own the domain. [Learn more](https://developer.android.com/training/app-links) ##### `action` Type: `string` • Path: `android.intentFilters.action` ##### `data` Type: `undefined` • Path: `android.intentFilters.data` ##### `category` Type: `undefined` • Path: `android.intentFilters.category` #### `allowBackup` Type: `boolean` • Path: `android.allowBackup` Allows your user's app data to be automatically backed up to their Google Drive. If this is set to false, no backup or restore of the application will ever be performed (this is useful if your app deals with sensitive information). Defaults to the Android default, which is `true`. #### `softwareKeyboardLayoutMode` Type: `enum` • Path: `android.softwareKeyboardLayoutMode` Determines how the software keyboard will impact the layout of your application. This maps to the `android:windowSoftInputMode` property. Defaults to `resize`. Valid values: `resize`, `pan`. #### `jsEngine` Type: `enum` • Path: `android.jsEngine` @deprecated This field will be removed in a future release. When it is removed, you can continue using JavaScriptCore instead of Hermes by following the instructions in [@react-native-community/javascriptcore](https://github.com/react-native-community/javascriptcore). Specifies the JavaScript engine for Android apps. Defaults to `hermes`. Valid values: `hermes`, `jsc`. Existing React Native app? To change the JavaScript engine, update the `expo.jsEngine` value in `android/gradle.properties` #### `newArchEnabled` Type: `boolean` • Path: `android.newArchEnabled` A Boolean value that indicates whether the Android app should use the new architecture. #### `runtimeVersion` One of types: - `string` matching the following pattern: `^[a-zA-Z\d][a-zA-Z\d._+()-]{0,254}$` - `string` matching the following pattern: `^exposdk:((\d+\.\d+\.\d+)|(UNVERSIONED))$` - An `object` with the following properties: ##### `policy` Type: `enum` • Path: `android.runtimeVersion.policy` Valid values: `nativeVersion`, `sdkVersion`, `appVersion`, `fingerprint`. Property indicating compatibility between a Android build's native code and an OTA update for the Android platform. If provided, this will override the value of top level `runtimeVersion` key on Android. #### `version` Type: `string` • Path: `android.version` Your android app version. Takes precedence over the root `version` field. In addition to this field, you'll also use `android.versionCode` — read more about how to version your app [here](https://docs.expo.dev/distribution/app-stores/#versioning-your-app). This corresponds to `versionName`. The required format can be found [here](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring). Existing React Native app? To change your app version, edit the `versionName` string in `android/app/build.gradle` #### `edgeToEdgeEnabled` Type: `boolean` • Path: `android.edgeToEdgeEnabled` Enable your app to run in [edge-to-edge](https://developer.android.com/develop/ui/views/layout/edge-to-edge) mode. Default to false. Existing React Native app? To change the setting, update the `expo.edgeToEdgeEnabled` value in `android/gradle.properties` and update the `AppTheme`'s `parent` attribute to one of the [Theme.EdgeToEdge values](https://github.com/zoontek/react-native-edge-to-edge#pick-a-parent-theme) in `styles.xml` #### `predictiveBackGestureEnabled` Type: `boolean` • Path: `android.predictiveBackGestureEnabled` Enable your app to use the [predictive back gesture](https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture) on Android 13 (API level 33) and later. Default to false. Existing React Native app? To change the setting, update the `android:enableOnBackInvokedCallback` value in `AndroidManifest.xml`. ### `web` Type: `object` Configuration that is specific to the web platform. #### `output` Type: `enum` • Path: `web.output` Sets the export method for the web app for both `expo start` and `expo export`. `static` statically renders HTML files for every route in the `app/` directory, which is available only in Expo Router apps. `single` outputs a Single Page Application (SPA), with a single `index.html` in the output folder, and has no statically indexable HTML. `server` outputs static HTML, and API Routes for hosting with a custom Node.js server. Defaults to `single`. #### `favicon` Type: `string` • Path: `web.favicon` Relative path of an image to use for your app's favicon. #### `name` Type: `string` • Path: `web.name` Defines the title of the document, defaults to the outer level name #### `shortName` Type: `string` • Path: `web.shortName` A short version of the app's name, 12 characters or fewer. Used in app launcher and new tab pages. Maps to `short_name` in the PWA manifest.json. Defaults to the `name` property. Maximum 12 characters long #### `lang` Type: `string` • Path: `web.lang` Specifies the primary language for the values in the name and short_name members. This value is a string containing a single language tag. #### `scope` Type: `string` • Path: `web.scope` Defines the navigation scope of this website's context. This restricts what web pages can be viewed while the manifest is applied. If the user navigates outside the scope, it returns to a normal web page inside a browser tab/window. If the scope is a relative URL, the base URL will be the URL of the manifest. #### `themeColor` Type: `string` • Path: `web.themeColor` Defines the color of the Android tool bar, and may be reflected in the app's preview in task switchers. 6 character long hex color string, for example, `'#000000'` #### `description` Type: `string` • Path: `web.description` Provides a general description of what the pinned website does. #### `dir` Type: `enum` • Path: `web.dir` Specifies the primary text direction for the name, short_name, and description members. Together with the lang member, it helps the correct display of right-to-left languages. #### `display` Type: `enum` • Path: `web.display` Defines the developers’ preferred display mode for the website. #### `startUrl` Type: `string` • Path: `web.startUrl` The URL that loads when a user launches the application (e.g., when added to home screen), typically the index. Note: This has to be a relative URL, relative to the manifest URL. #### `orientation` Type: `enum` • Path: `web.orientation` Defines the default orientation for all the website's top level browsing contexts. #### `backgroundColor` Type: `string` • Path: `web.backgroundColor` Defines the expected “background color” for the website. This value repeats what is already available in the site’s CSS, but can be used by browsers to draw the background color of a shortcut when the manifest is available before the stylesheet has loaded. This creates a smooth transition between launching the web application and loading the site's content. 6 character long hex color string, for example, `'#000000'` #### `barStyle` Type: `enum` • Path: `web.barStyle` If content is set to default, the status bar appears normal. If set to black, the status bar has a black background. If set to black-translucent, the status bar is black and translucent. If set to default or black, the web content is displayed below the status bar. If set to black-translucent, the web content is displayed on the entire screen, partially obscured by the status bar. #### `preferRelatedApplications` Type: `boolean` • Path: `web.preferRelatedApplications` Hints for the user agent to indicate to the user that the specified native applications (defined in expo.ios and expo.android) are recommended over the website. #### `dangerous` Type: `object` • Path: `web.dangerous` Experimental features. These will break without deprecation notice. #### `splash` Type: `object` • Path: `web.splash` Configuration for PWA splash screens. Existing React Native app? Use [expo-splash-screen](https://github.com/expo/expo/tree/main/packages/expo-splash-screen#expo-splash-screen) ##### `backgroundColor` Type: `string` • Path: `web.splash.backgroundColor` Color to fill the loading screen background 6 character long hex color string, for example, `'#000000'` ##### `resizeMode` Type: `enum` • Path: `web.splash.resizeMode` Determines how the `image` will be displayed in the splash loading screen. Must be one of `cover` or `contain`, defaults to `contain`. ##### `image` Type: `string` • Path: `web.splash.image` Local path or remote URL to an image to fill the background of the loading screen. Image size and aspect ratio are up to you. Must be a .png. #### `config` Type: `object` • Path: `web.config` Firebase web configuration. Used by the expo-firebase packages on both web and native. [Learn more](https://firebase.google.com/docs/reference/js/firebase.html#initializeapp) ##### `firebase` Type: `object` • Path: `web.config.firebase` ##### `apiKey` Type: `string` • Path: `web.config.firebase.apiKey` ##### `authDomain` Type: `string` • Path: `web.config.firebase.authDomain` ##### `databaseURL` Type: `string` • Path: `web.config.firebase.databaseURL` ##### `projectId` Type: `string` • Path: `web.config.firebase.projectId` ##### `storageBucket` Type: `string` • Path: `web.config.firebase.storageBucket` ##### `messagingSenderId` Type: `string` • Path: `web.config.firebase.messagingSenderId` ##### `appId` Type: `string` • Path: `web.config.firebase.appId` ##### `measurementId` Type: `string` • Path: `web.config.firebase.measurementId` #### `bundler` Type: `enum` • Path: `web.bundler` Sets the bundler to use for the web platform. Only supported in the local CLI `npx expo`. Defaults to `webpack` if the `@expo/webpack-config` package is installed, if not, it defaults to `metro`. ### `experiments` Type: `object` Enable experimental features that may be unstable, unsupported, or removed without deprecation notices. #### `autolinkingModuleResolution` Type: `boolean` • Path: `experiments.autolinkingModuleResolution` Apply Expo Autolinking's search results to Metro's module resolution. This forces your project's dependencies on `react`, `react-dom`, and `react-native`, and the autolinked versions of any Expo and React Native modules to be resolved when bundling your app. This prevents version misalignment and is useful for monorepos and to prevent conflicts. #### `baseUrl` Type: `string` • Path: `experiments.baseUrl` Export a website relative to a subpath of a domain. The path will be prepended as-is to links to all bundled resources. Prefix the path with a `/` (recommended) to load all resources relative to the server root. If the path **does not** start with a `/` then resources will be loaded relative to the code that requests them, this could lead to unexpected behavior. Example '/subpath'. Defaults to '' (empty string). #### `buildCacheProvider` Type: `undefined` • Path: `experiments.buildCacheProvider` @deprecated This field is not longer marked as experimental and will be removed in a future release, use the `buildCacheProvider` field instead. #### `supportsTVOnly` Type: `boolean` • Path: `experiments.supportsTVOnly` If true, indicates that this project does not support tablets or handsets, and only supports Apple TV and Android TV #### `tsconfigPaths` Type: `boolean` • Path: `experiments.tsconfigPaths` Enable tsconfig/jsconfig `compilerOptions.paths` and `compilerOptions.baseUrl` support for import aliases in Metro. #### `typedRoutes` Type: `boolean` • Path: `experiments.typedRoutes` Enable support for statically typed links in Expo Router. This feature requires TypeScript be set up in your Expo Router v2 project. #### `turboModules` Type: `boolean` • Path: `experiments.turboModules` Enables Turbo Modules, which are a type of native modules that use a different way of communicating between JS and platform code. When installing a Turbo Module you will need to enable this experimental option (the library still needs to be a part of Expo SDK already, like react-native-reanimated v2). Turbo Modules do not support remote debugging and enabling this option will disable remote debugging. #### `reactCanary` Type: `boolean` • Path: `experiments.reactCanary` Experimentally use a vendored canary build of React for testing upcoming features. #### `reactCompiler` Type: `boolean` • Path: `experiments.reactCompiler` Experimentally enable React Compiler. #### `reactServerComponentRoutes` Type: `boolean` • Path: `experiments.reactServerComponentRoutes` Experimentally enable React Server Components by default in Expo Router and concurrent routing for transitions. #### `reactServerFunctions` Type: `boolean` • Path: `experiments.reactServerFunctions` Experimentally enable React Server Functions support in Expo CLI and Expo Router. ### `_internal` Type: `object` Internal properties for developer tools #### `pluginHistory` Type: `object` • Path: `_internal.pluginHistory` List of plugins already run on the config --- --- title: babel.config.js description: A reference for Babel configuration file. --- # babel.config.js A reference for Babel configuration file. Babel is used as the JavaScript compiler to transform modern JavaScript (ES6+) into a version compatible with the JavaScript engine on mobile devices. Each new Expo project created using `npx create-expo-app` configures Babel automatically and uses [`babel-preset-expo`](https://github.com/expo/expo/tree/main/packages/babel-preset-expo) as the default preset. There is no need to create a **babel.config.js** file unless you need to customize the Babel configuration. ## Create babel.config.js If your project requires a custom Babel configuration, you need to create the **babel.config.js** file in your project by following the steps below: 1. Navigate to the root of your project and run the following command inside a terminal. This will generate a **babel.config.js** file in the root of your project. ```sh npx expo customize babel.config.js ``` 2. The **babel.config.js** file contains the following default configuration: ```js module.exports = function (api) { api.cache(true); return { presets: ['babel-preset-expo'], }; }; ``` 3. If you make a change to the **babel.config.js** file, you need to restart the Metro bundler to apply the changes and use `--clear` option from Expo CLI to clear the Metro bundler cache: ```sh npx expo start --clear ``` ## babel-preset-expo [`babel-preset-expo`](https://github.com/expo/expo/tree/main/packages/babel-preset-expo) is the default preset used in Expo projects. It extends the default React Native preset (`@react-native/babel-preset`) and adds support for decorators, tree-shaking web libraries, and loading font icons. --- --- title: metro.config.js description: A reference of available configurations in Metro. --- # metro.config.js A reference of available configurations in Metro. See more information about **metro.config.js** in the [customizing Metro guide](/guides/customizing-metro). ## Environment variables Expo CLI can load environment variables from **.env** files. Learn more about how to use environment variables in Expo CLI in the [environment variables guide](/guides/environment-variables). EAS CLI uses a different mechanism for environment variables, except when it invokes Expo CLI for compiling and bundling. Learn more about [environment variables in EAS](/build-reference/variables). If you are migrating an older project, then you should ignore local env files by adding the following to your **.gitignore**: ```sh # local env files .env*.local ``` ### Disabling dotenv files Dotenv file loading can be fully disabled in Expo CLI by enabling the `EXPO_NO_DOTENV` environment variable, before invoking any Expo CLI command. ```sh npx cross-env EXPO_NO_DOTENV=1 expo start EXPO_NO_DOTENV=1 npx expo start ``` ### Disabling `EXPO_PUBLIC_`-prefixed client environment variables Environment variables prefixed with `EXPO_PUBLIC_` will be exposed to the app at build-time. For example, `EXPO_PUBLIC_API_KEY` will be available as `process.env.EXPO_PUBLIC_API_KEY`. Client environment variable inlining can be disabled with the environment variable `EXPO_NO_CLIENT_ENV_VARS=1`, this must be defined before any bundling is performed. ```sh npx cross-env EXPO_NO_CLIENT_ENV_VARS=1 expo start EXPO_NO_CLIENT_ENV_VARS=1 npx expo start ``` ## CSS > CSS support is under development and currently only works on web. Expo supports CSS in your project. You can import CSS files from any component. CSS Modules are also supported. CSS support is enabled by default. You can disable the feature by setting `isCSSEnabled` in the Metro config. ```js /** @type {import('expo/metro-config').MetroConfig} */ const config = getDefaultConfig(__dirname, { // Disable CSS support. isCSSEnabled: false, }); ``` ### Global CSS > Global styles are web-only, usage will cause your application to diverge visually on native. You can import a CSS file from any component. The CSS will be applied to the entire page. Here, we'll define a global style for the class name `.container`: ```css .container { background-color: red; } ``` We can then use the class name in our component by importing the stylesheet and using `.container`: ```jsx import './styles.css'; import { View } from 'react-native'; export default function App() { return ( <> {/* Use `className` to assign the style with React DOM components. */}
Hello World
{/* Use `style` with the following syntax to append class names in React Native for web. */} Hello World ); } ``` You can also import stylesheets that are vendored in libraries, just like you would any node module: ```js // Applies the styles app-wide. import 'emoji-mart/css/emoji-mart.css'; ``` - On native, all global stylesheets are automatically ignored. - Hot reloading is supported for global stylesheets, simply save the file and the changes will be applied. ### CSS Modules > CSS Modules for native are under development and currently only work on web. CSS Modules are a way to scope CSS to a specific component. This is useful for avoiding naming collisions and for ensuring that styles are only applied to the intended component. In Expo, CSS Modules are defined by creating a file with the `.module.css` extension. The file can be imported from any component. The exported value is an object with the class names as keys and the web-only scoped names as the values. The import `unstable_styles` can be used to access `react-native-web`-safe styles. CSS Modules support platform extensions to allow you to define different styles for different platforms. For example, you can define a `module.ios.css` and `module.android.css` file to define styles for Android and iOS respectively. You'll need to import without the extension, for example: Flipping the extension, for example, `App.ios.module.css` will not work and result in a universal module named `App.ios.module`. > You cannot pass styles to the `className` prop of a React Native or React Native for web component. Instead, you must use the `style` prop. ```jsx import styles, { unstable_styles } from './App.module.css'; export default function Page() { return ( <> Hello World Hello World {/* Web-only usage: */}

Hello World

); } ``` ```css .text { color: red; } ``` - On web, all CSS values are available. CSS is not processed or auto-prefixed like it is with the React Native Web `StyleSheet` API. You can use `postcss.config.js` to autoprefix your CSS. - CSS Modules use [lightningcss](https://github.com/parcel-bundler/lightningcss) under the hood, check [the issues](https://github.com/parcel-bundler/lightningcss/issues) for unsupported features. ### PostCSS [PostCSS](https://github.com/postcss/postcss) can be customized by adding a `postcss.config.json` file to the root of your project. This file should export a function that returns a PostCSS configuration object. For example: ```json { "plugins": { "tailwindcss": {} } } ``` Both `postcss.config.json` and `postcss.config.js` are supported, but `postcss.config.json` enables better caching. Expo CLI automatically handles CSS vendor prefixes with built-in support for [browserslist](https://browsersl.ist/). Avoid adding `autoprefixer` as this duplicates the functionality and slows down bundling. #### Resetting cache after updates Changing the Post CSS or `browserslist` config will require you to clear the Metro cache: ```sh npx expo start --clear npx expo export --clear ``` ### browserslist Expo has automatic [browserslist](https://browsersl.ist/) support via the Rust-based CSS parser. You can customize the CSS vendor prefixes and browser support by adding a **browserslist** field to your **package.json** file. For example: ```json { "browserslist": [">0.2%", "not dead", "not op_mini all"] } ``` ### SASS Expo Metro has _partial_ support for SCSS/SASS. To setup, install the `sass` package in your project: ```sh yarn add -D sass ``` Then, ensure [CSS is setup](/versions/latest/config/metro#css) in the **metro.config.js** file. - When `sass` is installed, then modules without extensions will be resolved in the following order: `scss`, `sass`, `css`. - Only use the intended syntax with `sass` files. - Importing other files from inside a scss/sass file is not currently supported. ### Tailwind > Standard Tailwind CSS supports only web platform. For universal support, use a library such as [NativeWind](https://www.nativewind.dev/), which allows creating styled React Native components with Tailwind CSS. [Tailwind CSS](/guides/tailwind) — Learn how to configure and use Tailwind CSS in your Expo project. ## Extending the Babel transformer Expo's Metro config uses a custom `transformer.babelTransformerPath` value to ensure `expo-babel-preset` is always used and web/Node.js environments are supported. If you want to extend the Babel transformer, import the upstream transformer from `@expo/metro-config/babel-transformer` instead of `metro-react-native-babel-transformer`. For example: ```js const upstreamTransformer = require('@expo/metro-config/babel-transformer'); module.exports.transform = async ({ src, filename, options }) => { // Do something custom for SVG files... if (filename.endsWith('.svg')) { src = '...'; } // Pass the source through the upstream Expo transformer. return upstreamTransformer.transform({ src, filename, options }); }; ``` ## Custom resolving Expo CLI extends the default Metro resolver to add features like Web, Server, and tsconfig aliases support. You can similarly customize the default resolution behavior of Metro by chaining the `config.resolver.resolveRequest` function. ```tsx const { getDefaultConfig } = require('expo/metro-config'); /** @type {import('expo/metro-config').MetroConfig} */ const config = getDefaultConfig(__dirname); config.resolver.resolveRequest = (context, moduleName, platform) => { if (moduleName.startsWith('my-custom-resolver:')) { // Logic to resolve the module name to a file path... // NOTE: Throw an error if there is no resolution. return { filePath: 'path/to/file', type: 'sourceFile', }; } // Ensure you call the default resolver. return context.resolveRequest(context, moduleName, platform); }; module.exports = config; ``` Unlike traditional bundlers, Metro shared the same resolver function across all platforms. As a result, you can mutate the resolution settings dynamically on each request with the `context` object. ### Mocking modules If you want a module to be empty for a given platform, you can return a `type: 'empty'` object from the resolver. The following example will cause `lodash` to be empty on web: ```ts const { getDefaultConfig } = require('expo/metro-config'); /** @type {import('expo/metro-config').MetroConfig} */ const config = getDefaultConfig(__dirname); config.resolver.resolveRequest = (context, moduleName, platform) => { if (platform === 'web' && moduleName === 'lodash') { return { type: 'empty', }; } // Ensure you call the default resolver. return context.resolveRequest(context, moduleName, platform); }; module.exports = config; ``` This technique is equivalent to using empty externals in Webpack or Vite, but with the added benefit of being able to target specific platforms. ### Virtual modules Metro doesn't support virtual modules at the moment. One technique you can use to obtain similar behavior is to create a module in the `node_modules/.cache/...` directory and redirect the resolution to that file. The following example will create a module at `node_modules/.cache/virtual/virtual-module.js` and redirect the resolution of `virtual:my-module` to that file: ```ts const path = require('path'); const fs = require('fs'); const { getDefaultConfig } = require('expo/metro-config'); /** @type {import('expo/metro-config').MetroConfig} */ const config = getDefaultConfig(__dirname); const virtualPath = path.resolve(__dirname, 'node_modules/.cache/virtual/virtual-module.js'); // Create the virtual module in a generated directory... fs.mkdirSync(path.dirname(virtualPath), { recursive: true }); fs.writeFileSync(virtualPath, 'export default "Hello World";'); config.resolver.resolveRequest = (context, moduleName, platform) => { if (moduleName === 'virtual:my-module') { return { filePath: virtualPath, type: 'sourceFile', }; } // Ensure you call the default resolver. return context.resolveRequest(context, moduleName, platform); }; module.exports = config; ``` This can be used to emulate `externals` with custom imports. For example, if you want to redirect `require('expo')` to something custom like `SystemJS.require('expo')`, you can create a virtual module that exports `SystemJS.require('expo')` and redirect the resolution of `expo` to that file. ## Custom transforming > Transformations are heavily cached in Metro. If you update something, use the `--clear` flag to see updates. For example, `npx expo start --clear`. Metro doesn't have a very expressive plugin system for transforming files, instead opt to use the [**babel.config.js**](/versions/latest/config/babel) and caller object to customize the transformation. ```js module.exports = function (api) { // Get the platform that Expo CLI is transforming for. const platform = api.caller(caller => (caller ? caller.platform : 'ios')); // Detect if the bundling operation is for Hermes engine or not, e.g. `'hermes'` | `undefined`. const engine = api.caller(caller => (caller ? caller.engine : null)); // Is bundling for a server environment, e.g. API Routes. const isServer = api.caller(caller => (caller ? caller.isServer : false)); // Is bundling for development or production. const isDev = api.caller(caller => caller ? caller.isDev : process.env.BABEL_ENV === 'development' || process.env.NODE_ENV === 'development' ); // Ensure the config is not cached otherwise the platform will not be updated. api.cache(false); // You can alternatively provide a more robust CONFIG cache invalidation: // api.cache.invalidate(() => platform); return { presets: ['babel-preset-expo'], plugins: [ // Add a plugin based on the platform... platform === 'web' && 'my-plugin', // Ensure you filter out falsy values. ].filter(Boolean), }; }; ``` If the caller doesn't have `engine`, `platform`, `bundler`, and so on, then ensure you are using `@expo/metro-config/babel-transformer` for the transformer. If you're using a custom transformer then it may need to extend the Expo transformer. Always try to implement custom logic in the resolver if possible, caching is much simpler and easier to reason about. For example, if you need to remap an import, it's simpler and faster to resolve to a static file with the resolver than to parse all possible import methods and remap them with the transformer. Always use `babel-preset-expo` as the default Babel preset, this ensures the transformation is always compatible with Expo runtimes. `babel-preset-expo` uses all of the caller inputs internally to optimize for a given platform, engine, and environment. ## Node.js built-ins When bundling for a server environment, Expo's Metro config automatically supports externalizing Node.js built-in modules (`fs`, `path`, `node:crypto`, and more) based on the current Node.js version. If the CLI is bundling for a browser environment, then built-ins will first check if the module is installed locally, then fallback on an empty shim. For example, if you install `path` for use in the browser, this can be used, otherwise, the module will automatically be skipped. ## Environment settings > These environment variables will not be defined in test environments. Expo's Metro config injects build settings that can be used in the client bundle via environment variables. All variables will be inlined and cannot be used dynamically. For example, `process.env["EXPO_BASE_URL"]` won't work. - `process.env.EXPO_BASE_URL` exposes the base URL defined in `experiments.baseUrl`. This is used in Expo Router to respect the production base URL for deployment. ## Bundle splitting Expo CLI automatically splits web bundles into multiple chunks based on async imports in production. This feature requires `@expo/metro-runtime` to be installed and imported somewhere in the entry bundle (available by default in Expo Router). Shared dependencies of async bundles are merged into a single chunk to reduce the number of requests. For example, if you have two async bundles that import `lodash`, then the library is merged into a single initial chunk. The chunk splitting heuristic cannot be customized. For example: `math.js` `index.js` ```js export function add(a, b) { return a + b; } ``` ```js import '@expo/metro-runtime'; // This will be split into a separate chunk. import('./math').then(math => { console.log(math.add(1, 2)); }); ``` When you run `npx expo export -p web`, the bundles are split into multiple files, and the entry bundle is added to the main HTML file. `@expo/metro-runtime` adds the runtime code that loads and evaluates the async bundles. ## Source map debug ID If a bundle is exported with an external source map, a [**Debug ID**](https://sentry.engineering/blog/the-case-for-debug-ids) annotation will be added to the end of the file, along with a matching `debugId` in the source map for corresponding the files together. If no source maps are exported, or inline source maps are used then this annotation will not be added. ```js // //# debugId= ``` The associated `*.js.map` or `*.hbc.map` source map will be a JSON file containing an equivalent `debugId` property. The `debugId` will be injected before hermes bytecode generation to ensure matching in all cases. The `debugId` is a deterministic hash of the bundle's contents without the external bundle splitting references. This is the same value used to create a chunks filename but formatted as a UUID. For example, `431b98e2-c997-4975-a3d9-2987710abd44`. `@expo/metro-config` injects `debugId` during `npx expo export` and `npx expo export:embed`. Any additional optimization steps in `npx expo export:embed` like Hermes bytecode generation will need to have the `debugId` injected manually. ## Metro require runtime You can optionally enable a custom Metro `require` implementation with the environment variable `EXPO_USE_METRO_REQUIRE=1`. This runtime has the following features: - String module IDs that are human-readable and make missing module errors easier to follow. - Deterministic IDs that are the same between runs and across modules (required for React Server Components in development). - Removed support for legacy RAM bundles. ## Magic import comments > Available from SDK 52 on all platforms. Server environments such as Workers, and Node.js support import arbitrary files at runtime, so you may want to keep `import` syntax in-tact instead of using Metro's require system. You can opt-out dynamic imports with the `/* @metro-ignore */` comment in `import()` statements. ```js // Manually ensure `./my-module.js` is included in the correct spot relative to the module. const myModule = await import(/* @metro-ignore */ './my-module.js'); ``` Expo CLI will skip the `./my-module.js` dependency and assume that the developer has manually added it to the output bundle. Internally, this is used for exporting custom server code that dynamically switches between files based on the request. Avoid using this syntax for native bundles since `import()` is generally not available in React Native with Hermes enabled. Many React libraries shipped the Webpack `/* webpackIgnore: true */` comment to achieve similar behavior. To bridge the gap, we've also added support for Webpack's comment but recommend using the Metro equivalent in your app. ## ES Module resolution > This sections applies from SDK 53 on all platforms. Metro resolves ES Module `import` and CommonJS `require` with separate resolution strategies. Previously, Metro applied the classic Node.js module resolution strategy (which matches Node.js versions before v12), with some additions to support ES Modules. In this resolution strategy, Metro resolves modules from `node_modules`, JS files, optionally while omitting extensions, such as `.js`, and uses `package.json` fields such as `main`, `module`, and `react-native`. Now, with the modern ES Modules resolution strategy, Metro instead resolves modules from `node_modules`, then matches different `package.json` fields, such as `exports`, [a nested map of sub-paths a package exposes](https://nodejs.org/api/packages.html#conditional-exports), and `main`. Depending on how a package is imported, one of these two resolution strategies will be used. Typically, a file that is imported with `import` from a Node module (rather than `require`), will use the ES Modules resolution strategy, and fall back on regular classic Node.js resolution. A file that wasn't resolved with ES Modules resolution or has been imported with CommonJS `require` will use the classic resolution strategy. ### `package.json:exports` When performing ES Modules resolution, Metro will look at the `package.json:exports` conditions map. This is a mapping of import subpaths and conditions to files in the Node module package. For example, a package that always exposes an **index.js** file, and matches Metro's classic CommonJS module resolution, may specify a map with the `default` condition. ```json { "exports": { "default": "./index.js" } } ``` However, a package providing both a CommonJS and ES Modules entrypoint may provide a mapping with the `import` and `require` conditions. ```json { "exports": { "import": "./index.mjs", "require": "./index.cjs" } } ``` By default, Metro will match different conditions depending on the platform and whether the resolution has started from a CommonJS `require` call, or an ES Modules `import` statement and will change the condition accordingly. For native platforms, the condition `react-native` is added, for web exports, the `browser` condition is added, and for server exports (such as API routes or React Server functions), the `node`, `react-server`, and `workerd` conditions are added. These conditions aren't matched in the order they're defined in. Instead, they're matched against the order of properties in the `package.json:exports` map. TypeScript performs ES Module resolution separately from Metro and will also respect `package.json:exports` maps, when its `compilerOptions.moduleResolution` configuration option has either been set to `"bundler"` (which matches Metro's behavior more closely) or to `"node16"` / `"nodenext"`. TypeScript will however also match the `types` condition. As such, types may not resolve properly when a package doesn't put the `types` condition first in its exports map. Since an exports map may contain subpaths, a package import may not have to match a file in the package's modules folder any longer, but may be a "redirected" import. Importing `'package/submodule'` may match a different file than **node_modules/package/submodule.js** if it's specified in `package.json:exports`. ```json { "exports": { ".": "./index.js", "./submodule": "./submodule/submodule.js" } } ``` If you're encountering packages that are incompatible or unprepared for the new ES Modules resolution strategy, you may be able to resolve problems by patching its `package.json` file and add or correct its `package.json:exports` conditions map. However, it's also possible to prevent Metro from using `package.json:exports` maps in its resolution by disabling the `unstable_enablePackageExports` option. ```js const { getDefaultConfig } = require('expo/metro-config'); /** @type {import('expo/metro-config').MetroConfig} */ const config = getDefaultConfig(__dirname); config.resolver.unstable_enablePackageExports = false; module.exports = config; ``` ## Asset imports When assets are imported, a virtual module is created to represent the data required for importing the asset. On native platforms, an asset will be a numeric ID: `1`, `2`, `3`, and so on, which can be looked up using `require("@react-native/assets-registry/registry").getAssetByID()`. On web and server platforms, the asset will change depending on the file type. If the file is an image, then the asset will be `{ uri: string, width?: number, height?: number }`, otherwise the asset will be a `string` representing the remote URL for the asset. The assets can be used as follows: ```jsx import { Image } from 'react-native'; import asset from './img.png'; function Demo() { return ; } ``` In API routes, you can always assume the type of the asset will not be a number: ```js import asset from './img.png'; export async function GET(req: Request) { const ImageData = await fetch( new URL( // Access the asset URI. asset.uri, // Append to the current request URL origin. req.url ) ).then(res => res.arrayBuffer()); return new Response(ImageData, { headers: { 'Content-Type': 'image/png', }, }); } ``` ## Web workers > This feature is in alpha and subject to breaking changes. ```ts new Worker(new URL('./worker', window.location.href)); ``` Expo Metro has experimental web worker support. This feature is currently web-only and does not work on native, usage on native will trigger an error "Property 'Worker' doesn't exist". Web workers can be used to offload work to a separate thread on web, allowing the main thread to remain responsive. This is useful for computationally expensive tasks, such as image processing, cryptography, or other tasks that would otherwise block the main thread. Workers can be generated inline using `Blob`, but sometimes you may want to leverage modern features like TypeScript or importing other modules. Web workers depend on Expo bundle splitting support, which means you need to either use Expo Router or install and import `@expo/metro-runtime`. You also cannot use the environment `EXPO_NO_METRO_LAZY=1` with web workers. Consider the following example of a worker that doubles a number: ```ts self.onmessage = ({ data }) => { const result = data * 2; // Example: double the number self.postMessage(result); }; ``` This worker file can be imported as a `Worker` in the main app: ```ts // worker is of type `Worker` const worker = new Worker(new URL('./worker', window.location.href)); worker.onmessage = ({ data }) => { console.log(`Worker responded: ${data}`); }; worker.postMessage(5); ``` Behind the scenes, Expo CLI is generating code like this: ```ts const worker = new Worker( new URL('/worker.bundle?platform=web&dev=true&etc', window.location.href) ); ``` The generated bundle URL changes based on development/production to ensure the worker is loaded and bundled correctly. Unlike traditional bundle splitting, a worker file needs to contain its own copy of all modules and cannot depend on common modules in the main bundle. The native API `Worker` is traditionally unavailable in React Native and not provided by the Expo SDK, so even though this bundling feature technically works for all platforms, it's only useful on web. You could theoretically write a native Expo module that polyfills the `Worker` API if you want to support native platforms too. Alternatively, you can use the "worklet" API in React Native Reanimated to offload work to a separate thread on native. Alternatively, you can import Workers using the public path by first putting a transformed JS file in the **public** directory, then referencing it in the worker import with a variable: ```ts // Will avoid the transform and use the public path directly. const worker = new Worker('/worker.js'); // The variable breaks the transform causing the literal path to be used instead of the transformed path. const path = '/worker.js'; const anotherWorker = new Worker(new URL(path, window.location.href)); ``` Using a variable in the `Worker` constructor is not supported for bundling. To inspect the internal URL, you may use the internal syntax `require.unstable_resolveWorker('./path/to/worker.js')` to get the URL fragment. ## Bare workflow setup > This guide is versioned and will need to be revisited when upgrading/downgrading Expo. Alternatively, use [Expo Prebuild](/workflow/prebuild) for fully automated setup. Projects that don't use [Expo Prebuild](/workflow/prebuild) must configure native files to ensure the Expo Metro config is always used to bundle the project. These modifications are meant to replace `npx react-native bundle` and `npx react-native start` with `npx expo export:embed` and `npx expo start` respectively. ### metro.config.js Ensure the **metro.config.js** extends `expo/metro-config`: ```js const { getDefaultConfig } = require('expo/metro-config'); const config = getDefaultConfig(__dirname); module.exports = config; ``` ### `android/app/build.gradle` The Android **app/build.gradle** must be configured to use Expo CLI for production bundling. Modify the `react` config object: ### `ios/.xcodeproj/project.pbxproj` In your **ios/.xcodeproj/project.pbxproj** file, replace the following scripts: #### "Start Packager" script Remove the **"Start Packager"** script. The dev server must be started with `npx expo` before/after running the app. #### "Bundle React Native code and images" script Alternatively, in the Xcode project, select the **"Bundle React Native code and images"** build phase and add the following modifications: > You can set `CLI_PATH`, `BUNDLE_COMMAND`, and `ENTRY_FILE` environment variables to overwrite these defaults. ### Custom entry file By default, React Native only supports using a root `index.js` file as the entry file (or platform-specific variation like `index.ios.js`). Expo projects allow using any entry file, but this requires addition bare setup. #### Development Development mode entry files can be enabled by using the [`expo-dev-client`](/versions/latest/sdk/dev-client) package. Alternatively you can add the following configuration: #### Production In your **ios/.xcodeproj/project.pbxproj** file, replace the **"Bundle React Native code and images"** script to set `$ENTRY_FILE` according using Metro: The Android **app/build.gradle** must be configured to use Metro module resolution to find the root entry file. Modify the `react` config object: --- --- title: package.json description: A reference for Expo-specific properties that can be used in the package.json file. --- # package.json A reference for Expo-specific properties that can be used in the package.json file. **package.json** is a JSON file that contains the metadata for a JavaScript project. This is a reference to Expo-specific properties that can be used in the **package.json** file. ## `install.exclude` The following commands perform a version check for the libraries installed in a project and give a warning when a library's version is different from the version recommended by Expo: - `npx expo start` and `npx expo-doctor` - `npx expo install` (when installing a new version of that library or using `--check` or `--fix` options) By specifying the library under the `install.exclude` array in the **package.json** file, you can exclude it from the version checks: ```json { "expo": { "install": { "exclude": ["expo-updates", "expo-splash-screen"] } } } ``` ## `autolinking` Allows configuring module resolution behavior by using `autolinking` property in **package.json**. For complete reference, see [Autolinking configuration](/modules/autolinking#configuration). ## `doctor` Allows configuring the behavior of the [`npx expo-doctor`](/develop/tools#expo-doctor) command. ### `reactNativeDirectoryCheck` By default, Expo Doctor validates your project's packages against the [React Native directory](https://reactnative.directory/). This check throws a warning with a list of packages that are not included in the React Native Directory. You can customize this check by adding the following configuration in your project's **package.json** file: ```json { "expo": { "doctor": { "reactNativeDirectoryCheck": { "enabled": true, "exclude": ["/foo/", "bar"], "listUnknownPackages": true } } } } ``` By default, the check is enabled and unknown packages are listed. ### `appConfigFieldsNotSyncedCheck` Expo Doctor checks if your project includes native project directories such as **android** or **ios**. If these directories exist but are not listed in your **.gitignore** or [**.easignore**](/build-reference/easignore) files, Expo Doctor verifies the presence of an app config file. If this file exists, it means your project is configured to use [Prebuild](/workflow/prebuild). When the **android** or **ios** directories are present, EAS Build does not sync app config properties to the native projects. Expo Doctor throws a warning if these conditions are true. You can disable or enable this check by adding the following configuration to your project's **package.json** file: ```json { "expo": { "doctor": { "appConfigFieldsNotSyncedCheck": { "enabled": false } } } } ``` --- --- title: Reference --- # Reference The Expo SDK provides access to device and system functionality such as contacts, camera, gyroscope, GPS location, and so on, in the form of packages. You can install any Expo SDK package using the `npx expo install` command. For example, three different packages are installed using the following command: ```sh npx expo install expo-camera expo-contacts expo-sensors ``` After installing one or more packages, you can import them into your JavaScript code: ```js import { CameraView } from 'expo-camera'; import * as Contacts from 'expo-contacts'; import { Gyroscope } from 'expo-sensors'; ``` This allows you to write [`Contacts.getContactsAsync()`](/versions/latest/sdk/contacts#contactsgetcontactsasynccontactquery) and read the contacts from the device, read the gyroscope sensor to detect device movement, or start the phone's camera and take photos. ## All Expo SDK packages work in any React Native app Expo apps are React Native apps, so all Expo SDK packages work in any React Native app with the `expo` package installed and configured. The easiest way to create a React Native app with support for Expo SDK packages is to use `create-expo-app`. However, you can also add Expo SDK support to an existing React Native app with the `npx install-expo-modules` command. ```sh npx create-expo-app my-app --template bare-minimum ``` [Install Expo SDK packages in existing React Native apps](/bare/installing-expo-modules) — Learn more about configuring projects created with npx @react-native-community/cli@latest init to Expo SDK packages. — npx @react-native-community/cli@latest init [Use libraries](/workflow/using-libraries) — Learn how to install Expo SDK packages in your project. ## Using pre-release versions New Expo SDK versions are released three times each year. Between these releases, we publish pre-release versions of the `expo` package and all of the Expo SDK packages. Pre-releases are not considered stable and should only be used if you are comfortable with the risk of encountering bugs or other issues. ### Canary releases Canary releases represent a snapshot of the state of the `main` branch at the time they are published. Canary package versions include `-canary` in the name, along with the date and commit hash, such as `54.0.0-canary-20240418-8d74597`. To install the latest canary release: ```sh npm install expo@canary && npx expo install --fix ``` You can often use pre-release versions of individual packages with stable releases of the Expo SDK. There may occasionally be incompatibilities or other issues that arise in canary-quality releases. You may want to [silence dependency validation warnings](/more/expo-cli#configuring-dependency-validation) if you opt in to the canary package and once you have verified that it works well for your use cases. ### Beta releases Before each Expo SDK release, we publish beta versions of the `expo` package and all of the Expo SDK packages. Beta releases are considered much more stable than canary releases, and we encourage developers to try them out on their apps and share their feedback. Beta releases use the `beta` tag on npm and follow the instructions in the related [changelog](https://expo.dev/changelog) post. ## Each Expo SDK version depends on a React Native version | Expo SDK version | React Native version | React version | React Native Web version | React Native TV version | Minimum Node.js version | | --- | --- | --- | --- | --- | --- | | 54.0.0 | 0.81 | 19.1.0 | 0.21.0 | 0.81-stable | 20.19.x | | 53.0.0 | 0.79 | 19.0.0 | 0.20.0 | 0.79-stable | 20.18.x | | 52.0.0 | 0.76 | 18.3.1 | 0.19.13 | 0.77-stable | 20.18.x | ### Additional information Expo SDK policy for tracking React Native releases - Expo SDK versions are released three times each year, and each Expo SDK release targets a single React Native version. This is typically the latest stable version at the time of the release. - The release cadence of React Native has varied over its history and it is currently on pace for six releases in 2025. While on this cadence, you can expect that there will be an Expo SDK version for every second React Native release. - Pre-release versions of the upcoming Expo SDK will include support for the latest version of React Native quickly, usually the same day it is released. A member of the Expo SDK team works on the React Native releases team for each release, and is responsible for continuously updating the React Native version in the Expo repository, verifying compatibility, and reporting regressions back to the team at Meta. Why not release a new Expo SDK version immediately for every React Native release? At Expo, we have found that releasing three major version provides a good balance of stability and innovation for developers depending on our open source tools. Expo and Meta work closely together on releases, and we will keep improving our processes to get the latest Expo and React Native features to you as quickly as possible. What if I need a change from the latest React Native version and it's not yet in an Expo SDK release? We work closely with the team at Meta to ensure that any urgent fixes are included in the React Native version used by the latest Expo SDK. If your issue won't be cherrypicked into an existing release because it is more niche, or it involves a breaking change, then you have two options: 1. Use [`patch-package`](https://github.com/ds300/patch-package) to pull in the fix. 2. Use a [pre-release version of the Expo SDK](/versions/latest#using-pre-release-versions). An ([example](https://expo.dev/changelog/react-native-78)). Can I use an older version of React Native with the latest Expo SDK? Packages in the Expo SDK are intended to support the target React Native version for that SDK. Typically, they will not support older versions of React Native, but they may. When a new version of React Native is released, the latest versions of the Expo SDK packages are typically updated to support it. However, this may take weeks or more, depending on the extent of the changes in the release. ## Support for Android and iOS versions Each version of Expo SDK supports a minimum OS version of Android and iOS. For Android, the `compileSdkVersion` is defined which tells the [Gradle](https://developer.android.com/studio/build) which Android SDK version to use to compile the app. This also means that you can use the Android API features included in that SDK version and from the previous versions. For iOS, the [Xcode](https://developer.apple.com/news/upcoming-requirements/) tells the minimum Xcode SDK version to use to compile the app. | Expo SDK version | Android version | `compileSdkVersion` | `targetSdkVersion` | iOS version | Xcode version | | --- | --- | --- | --- | --- | --- | | 54.0.0 | 7+ | 36 | 36 | 15.1+ | 16.1+ | | 53.0.0 | 7+ | 35 | 35 | 15.1+ | 16.0+ | | 52.0.0 | 7+ | 35 | 34 | 15.1+ | 16.0+ | When deciding whether to upgrade your Expo SDK version, consider both Expo's SDK version and app store submission requirements, as described in the above table. Google Play Store and Apple App Store periodically increase their minimum required OS versions and API levels, which are required for new app submissions. Expo has no control over the app store requirements, and you should check [Google](https://developer.android.com/studio/build) and [Apple](https://developer.apple.com/news/upcoming-requirements/) for the current store submission requirements. --- --- title: Accelerometer description: A library that provides access to the device's accelerometer sensor. sourceCodeUrl: 'https://github.com/expo/expo/tree/sdk-54/packages/expo-sensors' packageName: 'expo-sensors' iconUrl: '/static/images/packages/expo-sensors.png' platforms: ['android', 'ios*', 'web', 'expo-go'] --- # Expo Accelerometer A library that provides access to the device's accelerometer sensor. Android, iOS (device only), Web, Included in Expo Go `Accelerometer` from `expo-sensors` provides access to the device accelerometer sensor(s) and associated listeners to respond to changes in acceleration in three-dimensional space, meaning any movement or vibration. ## Installation ```sh npx expo install expo-sensors ``` If you are installing this in an [existing React Native app](/bare/overview), make sure to [install `expo`](/bare/installing-expo-modules) in your project. ## Usage ```jsx import { useState, useEffect } from 'react'; import { StyleSheet, Text, TouchableOpacity, View } from 'react-native'; import { Accelerometer } from 'expo-sensors'; export default function App() { const [{ x, y, z }, setData] = useState({ x: 0, y: 0, z: 0, }); const [subscription, setSubscription] = useState(null); const _slow = () => Accelerometer.setUpdateInterval(1000); const _fast = () => Accelerometer.setUpdateInterval(16); const _subscribe = () => { setSubscription(Accelerometer.addListener(setData)); }; const _unsubscribe = () => { subscription && subscription.remove(); setSubscription(null); }; useEffect(() => { _subscribe(); return () => _unsubscribe(); }, []); return ( Accelerometer: (in gs where 1g = 9.81 m/s^2) x: {x} y: {y} z: {z} {subscription ? 'On' : 'Off'} Slow Fast ); } const styles = StyleSheet.create({ container: { flex: 1, justifyContent: 'center', paddingHorizontal: 20, }, text: { textAlign: 'center', }, buttonContainer: { flexDirection: 'row', alignItems: 'stretch', marginTop: 15, }, button: { flex: 1, justifyContent: 'center', alignItems: 'center', backgroundColor: '#eee', padding: 10, }, middleButton: { borderLeftWidth: 1, borderRightWidth: 1, borderColor: '#ccc', }, }); ``` ## API ```js import { Accelerometer } from 'expo-sensors'; ``` ## Classes ### `Accelerometer` Supported platforms: Android, iOS, Web. Type: Class extends [DeviceSensor](/versions/latest/sdk/sensors)<[AccelerometerMeasurement](#accelerometermeasurement)\> A base class for subscribable sensors. The events emitted by this class are measurements specified by the parameter type `Measurement`. Accelerometer Methods ### `addListener(listener)` Supported platforms: Android, iOS, Web. | Parameter | Type | Description | | --- | --- | --- | | `listener` | Listener<[AccelerometerMeasurement](#accelerometermeasurement)\> | A callback that is invoked when an accelerometer update is available. When invoked, the listener is provided a single argument that is an `AccelerometerMeasurement` object. | Subscribe for updates to the accelerometer. Returns: `EventSubscription` A subscription that you can call `remove()` on when you would like to unsubscribe the listener. ### `getListenerCount()` Supported platforms: Android, iOS, Web. Returns the registered listeners count. Returns: `number` ### `getPermissionsAsync()` Supported platforms: Android, iOS, Web. Checks user's permissions for accessing sensor. Returns: `Promise` ### `hasListeners()` Supported platforms: Android, iOS, Web. Returns boolean which signifies if sensor has any listeners registered. Returns: `boolean` ### `isAvailableAsync()` Supported platforms: Android, iOS, Web. > You should always check the sensor availability before attempting to use it. Returns whether the accelerometer is enabled on the device. On mobile web, you must first invoke `Accelerometer.requestPermissionsAsync()` in a user interaction (i.e. touch event) before you can use this module. If the `status` is not equal to `granted` then you should inform the end user that they may have to open settings. On **web** this starts a timer and waits to see if an event is fired. This should predict if the iOS device has the **device orientation** API disabled in **Settings > Safari > Motion & Orientation Access**. Some devices will also not fire if the site isn't hosted with **HTTPS** as `DeviceMotion` is now considered a secure API. There is no formal API for detecting the status of `DeviceMotion` so this API can sometimes be unreliable on web. Returns: `Promise` A promise that resolves to a `boolean` denoting the availability of the accelerometer. ### `removeAllListeners()` Supported platforms: Android, iOS, Web. Removes all registered listeners. Returns: `void` ### `removeSubscription(subscription)` Supported platforms: Android, iOS, Web. | Parameter | Type | Description | | --- | --- | --- | | `subscription` | `EventSubscription` | A subscription to remove. | Removes the given subscription. Returns: `void` ### `requestPermissionsAsync()` Supported platforms: Android, iOS, Web. Asks the user to grant permissions for accessing sensor. Returns: `Promise` ### `setUpdateInterval(intervalMs)` Supported platforms: Android, iOS, Web. | Parameter | Type | Description | | --- | --- | --- | | `intervalMs` | `number` | Desired interval in milliseconds between sensor updates. Starting from Android 12 (API level 31), the system has a 200ms limit for each sensor updates. | Set the sensor update interval. Returns: `void` ## Interfaces ### `Subscription` Supported platforms: Android, iOS, Web. A subscription object that allows to conveniently remove an event listener from the emitter. Subscription Methods ### `remove()` Supported platforms: Android, iOS, Web. Removes an event listener for which the subscription has been created. After calling this function, the listener will no longer receive any events from the emitter. Returns: `void` ## Types ### `AccelerometerMeasurement` Supported platforms: Android, iOS, Web. Each of these keys represents the acceleration along that particular axis in g-force (measured in `g`s). A `g` is a unit of gravitational force equal to that exerted by the earth’s gravitational field (`9.81 m/s^2`). | Property | Type | Description | | --- | --- | --- | | timestamp | `number` | Timestamp of the measurement in seconds. | | x | `number` | Value of `g`s device reported in X axis. | | y | `number` | Value of `g`s device reported in Y axis. | | z | `number` | Value of `g`s device reported in Z axis. | ### `PermissionExpiration` Supported platforms: Android, iOS, Web. Literal Type: `union` Permission expiration time. Currently, all permissions are granted permanently. Acceptable values are: `'never'` | `number` ### `PermissionResponse` Supported platforms: Android, iOS, Web. An object obtained by permissions get and request functions. | Property | Type | Description | | --- | --- | --- | | canAskAgain | `boolean` | Indicates if user can be asked again for specific permission. If not, one should be directed to the Settings app in order to enable/disable the permission. | | expires | `PermissionExpiration` | Determines time when the permission expires. | | granted | `boolean` | A convenience boolean that indicates if the permission is granted. | | status | `PermissionStatus` | Determines the status of the permission. | ## Enums ### `PermissionStatus` Supported platforms: Android, iOS, Web. #### `DENIED` `PermissionStatus.DENIED = "denied"` User has denied the permission. #### `GRANTED` `PermissionStatus.GRANTED = "granted"` User has granted the permission. #### `UNDETERMINED` `PermissionStatus.UNDETERMINED = "undetermined"` User hasn't granted or denied the permission yet. --- --- title: AgeRange description: A library that provides access to age range information using Play Age Signals API on Android and Declared Age Range framework on iOS. sourceCodeUrl: 'https://github.com/expo/expo/tree/sdk-54/packages/expo-age-range' packageName: 'expo-age-range' platforms: ['android', 'ios', 'expo-go'] isAlpha: true --- # Expo AgeRange A library that provides access to age range information using Play Age Signals API on Android and Declared Age Range framework on iOS. Android, iOS, Included in Expo Go > **This library is currently in alpha and will frequently experience breaking changes.** `expo-age-range` provides access to user age range information. It uses Google's [Play Age Signals API](https://developer.android.com/google/play/age-signals/use-age-signals-api) on Android and Apple's [Declared Age Range framework](https://developer.apple.com/documentation/declaredagerange/) on iOS. This library allows you to request age range information from your app users to help you comply with age-appropriate content regulations (such as in [Texas, USA](https://developer.apple.com/news/?id=btkirlj8)) and provide age-appropriate experiences in your app. ### Limitations We strongly recommend testing the functionality on a real device, as simulator runtimes may not work as expected. On Android, the Play Age Signals API (beta) may throw an exception until January 1, 2026, as per the [official Android documentation](https://developer.android.com/google/play/age-signals/use-age-signals-api#integrate-play-age-signals). From January 1, the API will return live responses. ## Installation ```sh npx expo install expo-age-range ``` If you are installing this in an [existing React Native app](/bare/overview), make sure to [install `expo`](/bare/installing-expo-modules) in your project. ## Configuration in app config ### Setup iOS project To use the age range API on iOS, you need to build your project with Xcode 26.0 or later. The `com.apple.developer.declared-age-range` entitlement is required. Add it to your [app config](/versions/latest/sdk/config/app) file: ```json { "expo": { "ios": { "entitlements": { "com.apple.developer.declared-age-range": true } } } } ``` Are you using this library in an existing React Native app? For existing React Native projects, add the entitlement to your project's **ios/[app]/[app].entitlements** file: ```xml com.apple.developer.declared-age-range ``` ## Usage ```tsx import * as AgeRange from 'expo-age-range'; import { useState } from 'react'; import { StyleSheet, Text, View, Button } from 'react-native'; export default function App() { const [result, setResult] = useState(null); const requestAgeRange = async () => { try { const ageRange = await AgeRange.requestAgeRangeAsync({ threshold1: 10, threshold2: 13, threshold3: 18, }); setResult(ageRange); } catch (error) { setResult({ error: error.message }); } }; return (