Profile Definitions

## What eas.json and a build profile are **EAS Build** is Expo's hosted service that compiles an iOS or Android binary from a project. Its configuration lives in **`eas.json`** at the project root, next to `package.json`, created the first time `eas build:configure` runs. Everything about builds sits under the `build` key, as a set of **build profiles**: named groups of settings that each describe one kind of binary. `eas build:configure` generates three profiles: ```json { "build": { "development": { "developmentClient": true, "distribution": "internal" }, "preview": { "distribution": "internal" }, "production": {} } } ``` The names carry no meaning to EAS; they could be `foo`, `bar` and `baz`. What matters is the keys inside. ## Selecting a profile - `eas build --profile preview --platform android` builds the `preview` profile for Android. - `-e` is the short form of `--profile`. - Without the flag, EAS CLI uses the profile named **`production`**; a project without one must name a profile explicitly. - The chosen profile name is exposed to the build as `EAS_BUILD_PROFILE`. ## The three conventional builds | Build | Typical keys | What testers get | |---|---|---| | Development | `developmentClient: true`, `distribution: "internal"` | A build containing expo-dev-client's developer tools, loading JS from a dev server | | Preview | `distribution: "internal"` | A production-like build installed directly by the team, not through a store | | Production | nothing, so the defaults apply | A store-ready binary, signed for App Store or Google Play | ## The keys that make the binaries differ | Key | Effect | |---|---| | `developmentClient` | `true` builds a development build that depends on `expo-dev-client` | | `distribution` | `"store"` (the default) signs for store submission; `"internal"` makes a build installable from a URL: an APK by default on Android, ad hoc or enterprise provisioning on iOS | | `ios.simulator` | `true` produces a Simulator build, which needs no Apple signing credentials | | `android.buildType` | `"apk"` or `"app-bundle"` to override the artifact type | | `env` | Plain variables set when the app config is evaluated and on the build worker | | `environment` | Which EAS environment's stored variables to load | | `channel` | The EAS Update channel baked into the build at build time | | `withoutCredentials` | Builds without signing credentials, for example an Android debug build | ## How a profile turns into a build 1. EAS CLI **resolves** the profile: it follows `extends`, merges the `android` or `ios` object over the root, and fills schema defaults such as `distribution: "store"`. 2. It **evaluates the app config** with the profile's `env` and the variables of its EAS `environment`, which is how a profile can change the app's name, identifiers or API host. 3. It works out whether **signing credentials** are needed; a Simulator build or a `withoutCredentials` build skips them. 4. It sends the project and the resolved settings to an **EAS Build worker**, which generates native folders if the project has none, installs dependencies and runs the native build for the requested artifact. Every difference between the three binaries enters through one of these steps. ## Root keys, platform keys and sharing Common keys may sit at the profile root or inside its `android` or `ios` object; the platform object wins when both set a key. That lets one profile say "internal distribution everywhere, but a Simulator build on iOS". To avoid repeating settings, a profile can declare `"extends": "<other profile>"` and inherit everything it does not override. ## A worked example: a fitness app A fitness app wants a dev client for engineers, a preview build for the coaching team, and a store build: - `development` sets `developmentClient`, internal distribution and `environment: "development"`. - `development-simulator` extends it and adds `ios.simulator: true` for engineers without a registered device. - `preview` uses internal distribution, the `preview` environment and its own `channel`. - `production` sets the `production` environment and channel and keeps store distribution. Each command, `eas build -e development`, `eas build -e preview` or `eas build -e production`, produces a different binary from the same commit. ## Common mistakes - Assuming the profile **name** does anything: a profile called `preview` with no `distribution` key is a store build. - Forgetting that `distribution` defaults to `"store"`, so a development profile without `"internal"` cannot be installed directly on a device. - Expecting a Simulator build to run on a physical iPhone; it cannot, and it is never signed. - Changing `channel` or `developmentClient` in `eas.json` and expecting existing installs to change; both are written into the binary when it is built, so only a new build picks up the edit.