EAS builds & releases

Setup

npm i -g eas-cli
eas login
eas init                     # links the project to your Expo account
yarn env:push:development    # and staging, production

Build profiles

Profiles live in eas.json and all extend a shared base (pinned Node and Yarn, 4 GB heap for Metro):

Profile	EAS environment	Distribution	Android artifact	Notes
`debug`	`development`	internal	APK	Development client, connects to Metro
`development`	`development`	internal	APK	Standalone build, no Metro
`staging`	`preview`	internal	APK	For QA and stakeholders
`production`	`production`	store	AAB	Version auto-increments from EAS

eas build --profile staging --platform android
eas build --profile production --platform all

Workflows

Three EAS workflows in .eas/workflows/ run multi-step pipelines. All three are manual only, because every run uses paid build minutes.

Workflow	Command	What it does
`build.yml`	`yarn eas:workflow:build`	Builds Android and iOS in parallel
`build-fast.yml`	`yarn eas:workflow:build:fast`	Reuses a matching build and repacks it with new JS. Compiles only when native code changed
`release.yml`	`yarn eas:workflow:release`	Approval, then production build, then store submission

Both build workflows take profile and platform (defaults staging and all):

yarn eas:workflow:build -F profile=production
yarn eas:workflow:build -F profile=development -F platform=ios
yarn eas:workflow:build:fast -F platform=android

Check your changes to the workflow files with yarn eas:workflow:validate.

build-fast: repack in the cloud

For each platform it fingerprints the native inputs, looks for a finished build with the same fingerprint and profile, and repacks it with the new JavaScript. If none exists it compiles from scratch, and that build becomes the base for the next JS-only runs. It supports the development and staging profiles.

Production releases never use it: store builds always go through a full compile for correct signing and crash symbolication.

release: build and submit

yarn eas:workflow:release                     # both platforms, then submit
yarn eas:workflow:release -F platform=ios     # one platform
yarn eas:workflow:release -F submit=false     # build only

The approval step comes first, so nobody spends build minutes or bumps the version by accident. Submission doesn’t publish anything to users:

Android: the AAB goes to the Play internal track as a draft. You promote it in the Play Console.
iOS: the IPA lands in TestFlight after Apple’s processing. You release it in App Store Connect.

Versioning and GitHub releases

Commits follow Conventional Commits, enforced by Commitlint. In the boilerplate repo, every push to main creates a GitHub release with a changelog generated by git-cliff:

feat: bumps the minor version, fix: and perf: bump the patch, feat!: or BREAKING CHANGE: bumps the major.
Pushes with only chore:, docs: or ci: commits don’t create a release.

Generated apps include the same cliff.toml, so you can set up the same flow for your app.