With EAS Build, how do you make every production iOS build go to a TestFlight tester group automatically, and which submit profile does --auto-submit use?

middlemust knowfreq 45%

answer

one build flag hands off to Submit
submit profile named like the build profile
--auto-submit-with-profile to override
groups live in the submit profile
ascAppId for unattended runs

basics

~20 s

Run eas build --profile production --auto-submit: each finished build is handed to EAS Submit using the submit profile with the same name as the build profile. Put ascAppId and a groups array in that profile's ios block.

solid answer

~40 s

Add --auto-submit (alias --submit, short -s) to eas build. When the build finishes, EAS Build passes it to EAS Submit and the CLI prints a link to the submission's details page. The flag reads the submit profile with the same name as the build profile, so eas build --profile production --auto-submit uses submit.production; --auto-submit-with-profile <name> picks a different one. eas build has no --groups flag, so TestFlight groups go in the profile as ios.groups, next to ios.ascAppId, which an unattended run needs anyway. --what-to-test sets the TestFlight test notes and is accepted only together with an auto-submit flag. The result is a TestFlight build for that group after every production build; App Review stays manual.

Add `--auto-submit` (alias `--submit`, short `-s`) to `eas build`. When the build finishes, EAS Build passes it to EAS Submit and the CLI prints a link to the submission's details page. The flag reads the submit profile with the **same name as the build profile**, so `eas build --profile production --auto-submit` uses `submit.production`; `--auto-submit-with-profile <name>` picks a different one. `eas build` has no `--groups` flag, so TestFlight groups go in the profile as `ios.groups`, next to `ios.ascAppId`, which an unattended run needs anyway. `--what-to-test` sets the TestFlight test notes and is accepted only together with an auto-submit flag. The result is a TestFlight build for that group after every production build; App Review stays manual.

code

json · 13 lines

json

{
  "build": {
    "production": {}
  },
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890",
        "groups": ["QA"]
      }
    }
  }
}

go deeper

for a junior

Recall that --auto-submit on eas build uploads each finished build, and that on iOS it lands in TestFlight rather than on the App Store.

for a middle

Explain the same-name submit profile rule, when --auto-submit-with-profile is needed, and why groups and ascAppId belong in the submit profile.

for a senior

Show how you make it unattended: API-key authentication, ascAppId, --non-interactive, and knowing that a missing named submit profile fails the run.

for a principal

Weigh how far to automate: TestFlight on every production build is cheap, while promotion to review should remain a deliberate, owned decision.

What --auto-submit does

eas build normally ends when the binary is ready. With --auto-submit (alias --submit, short flag -s) it also registers an EAS Submit job for each build it starts. When the build completes, that job uploads the binary to App Store Connect or Google Play exactly as eas submit would, and the CLI prints a link to the submission details page, also reachable from the build's page and the project's submissions list. The point is to stop babysitting builds: nobody waits for a 20-minute build just to type a second command.

Two consequences follow from the job being registered when the build is queued:

--no-wait does not cancel it; the CLI simply stops polling and the upload still happens when the build succeeds.
A build that errors or is cancelled produces no binary, so nothing reaches the store.

How the submit profile is chosen

The flag has to pick a submit profile from the submit key of eas.json. The rule is by name:

Command	Submit profile read
`eas build -p ios --auto-submit`	`production` (the default build profile); built-in defaults if it is missing
`eas build -p ios --profile production --auto-submit`	`submit.production`; an error if it is missing
`eas build -p ios --profile beta --auto-submit`	`submit.beta`; an error if it is missing
`eas build -p ios --profile beta --auto-submit-with-profile production`	`submit.production`

--auto-submit and --auto-submit-with-profile are mutually exclusive. When the names diverge — a beta build profile that should reuse the production upload settings — either add "beta": { "extends": "production" } under submit or pass --auto-submit-with-profile.

Setting up TestFlight after every production build

A working setup for the scenario "every production build lands in TestFlight for the QA group":

Create the app record in App Store Connect once and copy its numeric Apple ID; that is the ascAppId.
Give EAS a way to authenticate to App Store Connect without a person: an App Store Connect API key, either stored with EAS through eas credentials or referenced from the profile with ascApiKeyPath, ascApiKeyId and ascApiKeyIssuerId.
Add a submit.production.ios block with ascAppId and groups.
Run the build with --auto-submit, and add --non-interactive in CI.

The groups array is how EAS chooses groups for an auto-submission: the build command passes no groups of its own, so the submission takes them from the profile. For a manual eas submit, --groups (short -g, repeatable) overrides the profile's list.

TestFlight notes and other flags

--what-to-test fills TestFlight's "What to Test" text for testers. On eas build it is rejected unless --auto-submit or --auto-submit-with-profile is present, because there is no submission to attach it to.
ascAppId matters more than it looks: in --non-interactive mode EAS Submit refuses to run on iOS without it, since finding or creating the app record interactively needs an Apple login.
The app config is evaluated with the build profile's environment, so a bundle identifier that app.config.js derives from an environment variable matches the build being submitted.

Where the build ends up

On iOS the default outcome is TestFlight, not the App Store: the build is uploaded, processed by Apple, and made available to the listed groups. Sending a build to App Review is still a manual step in App Store Connect. On Android the same flag places the build on the submit profile's track, which defaults to internal. Automatic submission therefore means "testers get every production build", which is exactly the safe default a release pipeline wants.

Because the submit profile is shared by both platforms, one eas build --platform all --profile production --auto-submit produces two builds and two submissions: the iOS one goes to the TestFlight groups in ios.groups, the Android one to the track in android.track. Each submission has its own details page, and one platform failing to upload does not undo the other's.

Common mistakes

Assuming --auto-submit always reads submit.production, then being surprised by a missing-profile error on a beta build.
Looking for --groups on eas build.
Expecting the auto-submitted build to be on the App Store the next morning.
Leaving ascAppId out and discovering it only when the first CI run fails.

## What --auto-submit does `eas build` normally ends when the binary is ready. With **`--auto-submit`** (alias `--submit`, short flag `-s`) it also registers an **EAS Submit** job for each build it starts. When the build completes, that job uploads the binary to App Store Connect or Google Play exactly as `eas submit` would, and the CLI prints a link to the **submission details page**, also reachable from the build's page and the project's submissions list. The point is to stop babysitting builds: nobody waits for a 20-minute build just to type a second command. Two consequences follow from the job being registered when the build is queued: - `--no-wait` does not cancel it; the CLI simply stops polling and the upload still happens when the build succeeds. - A build that errors or is cancelled produces no binary, so nothing reaches the store. ## How the submit profile is chosen The flag has to pick a **submit profile** from the `submit` key of `eas.json`. The rule is by name: | Command | Submit profile read | |---|---| | `eas build -p ios --auto-submit` | `production` (the default build profile); built-in defaults if it is missing | | `eas build -p ios --profile production --auto-submit` | `submit.production`; an error if it is missing | | `eas build -p ios --profile beta --auto-submit` | `submit.beta`; an error if it is missing | | `eas build -p ios --profile beta --auto-submit-with-profile production` | `submit.production` | `--auto-submit` and `--auto-submit-with-profile` are mutually exclusive. When the names diverge — a `beta` build profile that should reuse the production upload settings — either add `"beta": { "extends": "production" }` under `submit` or pass `--auto-submit-with-profile`. ## Setting up TestFlight after every production build A working setup for the scenario "every production build lands in TestFlight for the QA group": 1. Create the app record in App Store Connect once and copy its numeric **Apple ID**; that is the `ascAppId`. 2. Give EAS a way to authenticate to App Store Connect without a person: an **App Store Connect API key**, either stored with EAS through `eas credentials` or referenced from the profile with `ascApiKeyPath`, `ascApiKeyId` and `ascApiKeyIssuerId`. 3. Add a `submit.production.ios` block with `ascAppId` and `groups`. 4. Run the build with `--auto-submit`, and add `--non-interactive` in CI. The `groups` array is how EAS chooses groups for an auto-submission: the build command passes no groups of its own, so the submission takes them from the profile. For a manual `eas submit`, `--groups` (short `-g`, repeatable) overrides the profile's list. ## TestFlight notes and other flags - **`--what-to-test`** fills TestFlight's "What to Test" text for testers. On `eas build` it is rejected unless `--auto-submit` or `--auto-submit-with-profile` is present, because there is no submission to attach it to. - **`ascAppId`** matters more than it looks: in `--non-interactive` mode EAS Submit refuses to run on iOS without it, since finding or creating the app record interactively needs an Apple login. - The app config is evaluated with the build profile's environment, so a bundle identifier that `app.config.js` derives from an environment variable matches the build being submitted. ## Where the build ends up On iOS the default outcome is **TestFlight, not the App Store**: the build is uploaded, processed by Apple, and made available to the listed groups. Sending a build to App Review is still a manual step in App Store Connect. On Android the same flag places the build on the submit profile's `track`, which defaults to `internal`. Automatic submission therefore means "testers get every production build", which is exactly the safe default a release pipeline wants. Because the submit profile is shared by both platforms, one `eas build --platform all --profile production --auto-submit` produces two builds and two submissions: the iOS one goes to the TestFlight groups in `ios.groups`, the Android one to the track in `android.track`. Each submission has its own details page, and one platform failing to upload does not undo the other's. ## Common mistakes - Assuming `--auto-submit` always reads `submit.production`, then being surprised by a missing-profile error on a `beta` build. - Looking for `--groups` on `eas build`. - Expecting the auto-submitted build to be on the App Store the next morning. - Leaving `ascAppId` out and discovering it only when the first CI run fails.

What happens with eas build --profile preview --auto-submit when eas.json has no submit.preview?
The CLI asks for the submit profile named `preview` explicitly, so the resolver fails with a missing-profile error instead of falling back to `production`. Add a `preview` submit profile, perhaps `"extends": "production"`, or pass `--auto-submit-with-profile production`. Only a run with no `--profile` at all falls back to defaults.
Does passing --no-wait to eas build cancel the automatic submission?
No. The CLI registers the submission for each build right after queuing it, before it would start waiting. `--no-wait` only stops the terminal from polling; the upload still runs when the build finishes, and its progress is on the submission details page.
When would you choose --auto-submit-with-profile over --auto-submit?
When the build profile and the upload settings do not share a name: a `production-hotfix` build profile that should upload with the ordinary `production` submit profile, or one build profile sent to different TestFlight groups by different pipelines.

saying these in an interview costs you the question

--auto-submit always reads the production submit profile
eas build takes a --groups flag for TestFlight groups
--auto-submit sends the iOS build to App Review
--what-to-test can be passed on any eas build run
--no-wait cancels the queued automatic submission

With EAS Build, how do you make every production iOS build go to a TestFlight tester group automatically, and which submit profile does --auto-submit use?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What --auto-submit does

How the submit profile is chosen

Setting up TestFlight after every production build

TestFlight notes and other flags

Where the build ends up

Common mistakes

▾common follow-ups3 questions

▾red flags5 flags

What --auto-submit does

How the submit profile is chosen

Setting up TestFlight after every production build

TestFlight notes and other flags

Where the build ends up

Common mistakes

answer

go deeper