EAS Submit

Upload builds to the App Store and Play Store from CI.

adds it to an existing project · no account needed
Currentas published in v1.5.1

The rule

This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.

Credentials

  • The Play service account JSON is never committed. Store it as an EAS secret or a CI file variable, and keep the path in .gitignore.
  • Use an App Store Connect API key, not an Apple ID and password — CI cannot answer a 2FA prompt.
  • EXPO_TOKEN lives in CI secrets, masked.

Tracks

  • Submit to internal or a beta track, then promote in the store console. Submitting straight to production removes the step where someone confirms the build is the intended one.
  • Submitted is not released. The build sits in a track until a human publishes.

Build numbers

  • autoIncrement in the production build profile. Stores reject duplicates *after* the upload finishes, wasting an entire build cycle.

In CI

  • --non-interactive always.
  • Prefer an explicit build --id over --latest, so a concurrent build cannot be submitted by mistake.

Never

  • Never commit store credentials of any kind.
  • Never submit from a local machine for a release the team relies on — it is unreproducible.

6 formats, one per tool

Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.

.cursor/rules/eas-submit.mdchand-written
---
description: EAS Submit conventions
globs: ["eas.json", ".github/workflows/**", ".gitlab-ci.yml"]
alwaysApply: false
---

# EAS Submit

## Credentials

- The Play service account JSON is **never committed**. Store it as an EAS
  secret or a CI file variable, and keep the path in `.gitignore`.
- Use an App Store Connect API key, not an Apple ID and password — CI cannot
  answer a 2FA prompt.
- `EXPO_TOKEN` lives in CI secrets, masked.

## Tracks

- Submit to `internal` or a beta track, then promote in the store console.
  Submitting straight to production removes the step where someone confirms the
  build is the intended one.
- Submitted is not released. The build sits in a track until a human publishes.

## Build numbers

- `autoIncrement` in the production build profile. Stores reject duplicates
  *after* the upload finishes, wasting an entire build cycle.

## In CI

- `--non-interactive` always.
- Prefer an explicit build `--id` over `--latest`, so a concurrent build cannot
  be submitted by mistake.

## Never

- Never commit store credentials of any kind.
- Never submit from a local machine for a release the team relies on — it is
  unreproducible.

Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.

What else this module writes

The rule is one file of several. Selecting EAS Submit contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
EXPO_TOKENrequiredAuthenticates EAS in CI. Never in a local `.env` that could be committed.
GOOGLE_SERVICE_ACCOUNT_KEY_PATHoptionalPath to the Play service account JSON, provided by CI at runtime.
ASC_APP_IDoptionalApp Store Connect app id used by the submit profile.
Checklists
checklists/store-submission.md

Advisory history

Every time this rule turned out to be wrong, and what we did about it.

No corrections yet

This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.

Pro tells you the day a correction lands that affects a repo you actually have.

See what Pro adds →

Rules people add alongside this one

Put this rule in a real project

The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.