Skip to main content
The mobile app already includes apps/mobile/eas.json, expo-updates, a runtime version policy, and Nx wrappers for common EAS commands. Replace all starter account and store identifiers before building your app. Install and authenticate the EAS CLI, then initialize from the mobile app directory:
Confirm that apps/mobile/app.json contains your Expo owner, extra.eas.projectId, and the matching updates.url. Do not retain the starter’s project ID or owner. app.config.js applies identity suffixes from EXPO_PUBLIC_APP_ENV. Verify the evaluated config before allowing EAS to create credentials:

Included profiles

apps/mobile/eas.json maps every build profile to an EAS environment and update channel: All profiles auto-increment the remote app version. The CLI uses remote versioning. None of the current profiles enables a development client; dev is an environment name, not an Expo development-client build.
The root build:production command uses the internal production profile. Use production-store directly when you need a store-distribution artifact.

Configure EAS environments

Create client values separately for development, preview, and production:
Repeat with development and preview, setting EXPO_PUBLIC_APP_ENV to the matching value. Pull an environment for local use with eas env:pull --environment development; delete a selected value with eas env:delete. EXPO_PUBLIC_* values are embedded public client configuration, even when EAS marks them sensitive. See Environment variables for the complete list and security model.

Build

Use the root wrappers for their matching internal profiles:
Platform-specific wrappers exist for dev and preview:
Build a store profile directly from apps/mobile:
The mobile package’s eas-build-post-install script returns to the repository root and runs tools/scripts/eas-build-post-install.mjs, which is required for this monorepo layout.

Credentials and submission

Let EAS inspect or create signing credentials:
Before submission, replace every starter appleTeamId and ascAppId in eas.json. Configure the Android service account through EAS when prompted. The root submit scripts use the corresponding *-store submit profiles:
Each has :ios and :android variants. The current Android submit profiles target the internal Play track; development and preview submissions start as drafts. Review those settings before release.

Updates

Build profiles already declare dev, preview, and production channels. Publish with the EAS environment that matches the installed build:
The app uses runtimeVersion.policy: "appVersion". Native changes or an incompatible runtime require a new build rather than an update.

Inspect builds

Official documentation

Next steps