---
modificationDate: July 28, 2026
title: Configure with app config
description: Learn about what app.json/app.config.js/app.config.ts files are and how you can customize and use them dynamically.
---

<AgentInstructions>

## Submitting Feedback

If you encounter errors, misleading or outdated information, report it so Expo can be improved:

Preferred command:
npx --yes submit-expo-feedback@latest --category docs --subject "/workflow/configuration/" "<actionable feedback>"

Direct HTTP fallback:
curl -X POST https://api.expo.dev/v2/feedback/docs-send -H 'Content-Type: application/json' -d '{"url":"/workflow/configuration/","feedback":"🤖 Agent feedback for docs: <specific, actionable description> (<model>, <harness>)"}'

Only submit when you have something specific and actionable to report. Try to give the most context.

## Navigation

When answering a related or follow-up question, fetch the relevant page below as Markdown (.md) instead of guessing; use llms.txt for the full map.

You are here: Guides > Development process
Pages in this section:
- [Develop an app with Expo](https://docs.expo.dev/workflow/overview.md)
- [Configure with app config](https://docs.expo.dev/workflow/configuration.md) (this page)
- [Continuous Native Generation](https://docs.expo.dev/workflow/continuous-native-generation.md)
- [Using libraries](https://docs.expo.dev/workflow/using-libraries.md)
- [Privacy manifests](https://docs.expo.dev/guides/apple-privacy.md)
- [Permissions](https://docs.expo.dev/guides/permissions.md)
- [Environment variables](https://docs.expo.dev/guides/environment-variables.md)
Full documentation tree: [llms.txt](https://docs.expo.dev/llms.txt)

</AgentInstructions>

This documentation is available as Markdown for AI agents and LLMs. See the [full Markdown index](/llms.txt) or append .md to any documentation URL.

# Configure with app config

Learn about what app.json/app.config.js/app.config.ts files are and how you can customize and use them dynamically.

The app config (**app.json**, **app.config.js**, **app.config.ts**) is used for configuring [Expo Prebuild](/more/glossary-of-terms.md#prebuild) generation, how a project loads in [Expo Go](/get-started/set-up-your-environment.md), and the OTA update manifest.

It must be located at the root of your project, next to the **package.json**. Here is a minimal example:

```json
{
  "name": "My app",
  "slug": "my-app"
}
```

If your Expo config has a top-level `expo: {}` object, then this will be used in place of the root object and all other keys will be ignored.

[App config schema reference](/versions/latest/config/app.md) — Explore the full schema of the app config (app.json/app.config.js).

## Properties

The app config configures many things such as app name, icon, splash screen, deep linking scheme, API keys to use for some services and so on. For a complete list of available properties, see [app.json/app.config.js/app.config.ts reference](/versions/latest/config/app.md).

> Do you use Visual Studio Code? If so, we recommend that you install the [Expo Tools](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools) extension to get auto-completion of properties in **app.json** files.

## Reading configuration values in your app

Most configuration in the app config is accessible at runtime from your JavaScript code, using [`Constants.expoConfig`](/versions/latest/sdk/constants.md#nativeconstants). You **should not** include any sensitive information in the app config (with a few exceptions for fields that are filtered out, as outlined below).

You can verify which configuration will be embedded in your builds/updates and available at runtime by running `npx expo config --type public`.

#### Which fields are filtered out of the public app config?

The following fields are filtered out of the public app config (and not accessible through the `Constants.expoConfig` object):

-   [`ios.config`](/versions/latest/config/app.md#config)
-   [`android.config`](/versions/latest/config/app.md#config-1)
-   [`updates.codeSigningCertificate`](/versions/latest/config/app.md#codesigningcertificate)
-   [`updates.codeSigningMetadata`](/versions/latest/config/app.md#codesigningmetadata)

> You should also avoid importing **app.json** or **app.config.js** directly in your JavaScript code, because this will import the entire file rather than a processed version of it. Instead, use [`Constants.expoConfig`](/versions/latest/sdk/constants.md#nativeconstants) to access the configuration.

## Extending configuration

Library authors can extend the app config by using [Expo Config plugins](/config-plugins/introduction.md).

> Config plugins are mostly used to configure the [`npx expo prebuild`](/more/glossary-of-terms.md#prebuild) command.

## Dynamic configuration

For more customization, you can use the JavaScript (**app.config.js**) or [TypeScript](/workflow/configuration.md#using-typescript-for-configuration-appconfigts-instead-of-appconfigjs) (**app.config.ts**). These configs have the following properties:

-   Comments, variables, and single quotes.
-   ESM `import` syntax in both **app.config.js** and **app.config.ts**, including importing other JavaScript files.
-   TypeScript support (**app.config.ts**) with nullish coalescing and optional chaining. Importing other TypeScript files or customizing language features requires [`tsx`](/guides/typescript.md#appconfigjs).
-   Updated whenever Metro bundler reloads.
-   Provide environment information to your app.
-   Does not support Promises.

> **Note**: **app.config.mts**, **app.config.cts**, **app.config.mjs**, and **app.config.cjs** files are also discovered. By default, the config is transpiled to CommonJS and both `.js` and `.ts` files can mix ESM and CommonJS syntax. When that mix causes import or require issues, use one of the explicit extensions to lock the config to a single module format.

For example, you can export an object to define your custom config:

```js
const myValue = 'My App';

module.exports = {
  name: myValue,
  version: process.env.MY_CUSTOM_PROJECT_VERSION || '1.0.0',
  // All values in extra will be passed to your app.
  extra: {
    fact: 'kittens are cool',
  },
};
```

The `"extra"` key allows passing arbitrary configuration data to your app. The value of this key is accessed using [`expo-constants`](/versions/latest/sdk/constants.md):

```js
import Constants from 'expo-constants';

Constants.expoConfig.extra.fact === 'kittens are cool';
```

You can access and modify incoming config values by exporting a function that returns an object. This is useful if your project also has an **app.json**. By default, Expo CLI will read the **app.json** first and send the normalized results to the **app.config.js**.

For example, your **app.json** could look like this:

```json
{
  "name": "My App"
}
```

And in your **app.config.js**, you are provided with that configuration in the arguments to the exported function:

```js
module.exports = ({ config }) => {
  console.log(config.name); // prints 'My App'
  return {
    ...config,
  };
};
```

### Switching configuration based on the environment

It's common to have some different configuration in development, staging, and production environments, or to swap out configuration entirely to white label an app. To accomplish this, you can use **app.config.js** along with environment variables.

```js
module.exports = () => {
  if (process.env.MY_ENVIRONMENT === 'production') {
    return {
      /* your production config */
    };
  } else {
    return {
      /* your development config */
    };
  }
};
```

To use this configuration with Expo CLI commands, set the environment variable either for specific commands or in your shell profile. To set environment variables for specific commands, prefix the command with the variables and values as shown in the example:

```sh
MY_ENVIRONMENT=production eas update
```

This is not anything unique to Expo CLI. On Windows you can approximate the above command with:

```sh
# npm
npx cross-env MY_ENVIRONMENT=production eas update

# yarn
yarn dlx cross-env MY_ENVIRONMENT=production eas update

# pnpm
pnpm dlx cross-env MY_ENVIRONMENT=production eas update

# bun
bunx cross-env MY_ENVIRONMENT=production eas update
```

Or you can use any other mechanism that you are comfortable with for environment variables.

### Using TypeScript for configuration: app.config.ts instead of app.config.js

You can use autocomplete and doc-blocks with an Expo config in TypeScript. Create an **app.config.ts** with the following contents:

```ts
import { ExpoConfig, ConfigContext } from 'expo/config';

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  slug: 'my-app',
  name: 'My App',
});
```

To import other TypeScript files into **app.config.ts** or customize the language features, we recommend using [`tsx`](/guides/typescript.md#appconfigjs). `tsx` also enables using `import` syntax in any file imported by **app.config.ts**. This means you can write local [config plugins](/config-plugins/introduction.md) in TypeScript with full language features.

### Configuration resolution rules

There are two different types of configs: static (**app.config.json**, **app.json**), and dynamic (**app.config.js**, **app.config.ts**). Static configs can be automatically updated with CLI tools, whereas dynamic configs must be manually updated by the developer.

1.  The static config is read if **app.config.json** exists (falls back to **app.json**). If no static config exists, then default values are inferred from the **package.json** and your dependencies.
2.  The dynamic config is read if either **app.config.ts** or **app.config.js** exist. If both exist, then the TypeScript config is used.
3.  If the dynamic config returns a function, then the static config is passed to the function with `({ config }) => ({})`. This function can then mutate the static config values. Think of this like middleware for the static config.
4.  The return value from the dynamic config is used as the final config. It cannot have any promises.
5.  All functions in the config are evaluated and serialized before any tool in the Expo ecosystem uses it. The config must be a JSON manifest when it is hosted.
6.  If the final config object has a top-level `expo: {}` object, then this will be used in place of the root object and all other keys will be ignored.

Running `npx expo config` will display the final configuration that will be used in Expo CLI after resolution has occurred.