EAS Submit CI/CD flags --non-interactive and --latest
For CI pipelines, use the --non-interactive flag to skip prompts and --latest to automatically select the most recent build. Example: eas submit --platform android --latest --non-interactive
Expo & React Native · all subjects
eas submit
42 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
EAS Submit accepts .aab and .ipa binaries
EAS Submit accepts any valid .aab (Android App Bundle) or .ipa (iOS App Archive) file. The binary must be correctly signed: for Android, this means an upload keystore; for iOS, this means a distribution certificate and provisioning profile.
EAS Submit Android upload to Google Play Console
EAS Submit uploads a .aab to Google Play Console and places it in the track you choose (internal, alpha, beta, or production). For a brand-new app, the default eas submit command creates the first release on the internal testing track, even before you complete the store listing. To upload a build without rolling it out to its track, set releaseStatus to draft in eas.json.
EAS Submit iOS upload to App Store Connect
EAS Submit uploads a .ipa to App Store Connect, where it becomes available in TestFlight after processing (usually 10-15 minutes). A TestFlight build is not automatically released to the App Store. To ship it to production, sign in to App Store Connect, complete the app metadata and screenshots, select the build, and submit it for App Review.
EAS Submit works from any OS including Windows and Linux for iOS
EAS Submit is the recommended path for submitting apps since it works from any OS (including Windows and Linux for iOS), integrates with EAS Build and EAS Workflows, and can be run from a CI/CD service.
EAS Submit with --path flag for local builds
For builds not created with EAS Build, use the --path flag to specify the binary when submitting. Example: eas submit --platform android --path ./my-app.aab or eas submit --platform ios --path ./my-app.ipa
EAS Submit does not handle store metadata or screenshots
EAS Submit uploads the binary but does not manage store listing metadata, screenshots, or release notes. For Google Play Store, configure the store listing directly in Google Play Console before submitting. For Apple App Store, you can use EAS Metadata to automate app information and localized descriptions.
View EAS Submit failure details in dashboard
To understand why a submission failed, open the submission details page in the EAS dashboard at https://expo.dev/accounts/[account]/projects/[project]/submissions. Read the logs on the submission details page to understand the error. Look for a Build Annotations bubble which highlights common failure reasons and suggested fixes directly in the logs.
EAS Submit in EAS Workflows with type: submit
EAS Submit integrates with EAS Workflows. You can add a submit job to your workflow configuration. Example: jobs with type: submit, needs: [build_id], and params including build_id from a previous build job output.
App store submission prerequisites
Before automating app store submissions with submit jobs, app store credentials must be managed with EAS CLI, and certain app store requirements must be fulfilled first. For Android, you must manually upload the first .aab file to Google Play Store. For iOS, you must complete Apple Developer Program enrollment and set up signing credentials.
Submit jobs automate app store submissions after builds
Add submit jobs with type: submit after build jobs to automate app store submissions. The submit job requires build_id: ${{ needs.build_android.outputs.build_id }} parameter from the build job output. Submit jobs run only when build jobs run (new native build created), and are skipped when only OTA updates occur.
eas.json submit.production.android track property
The track property under submit.production.android in eas.json specifies which Google Play Store track to release to. Supported values include 'internal' for internal testing and 'production' for the production track.
eas submit can create app's first release
eas submit can create an app's first release directly on Google Play Console without requiring manual app creation first.
Internal testing track configuration in eas.json
To set up internal testing release configuration, add track property under submit.production.android profile in eas.json with value set to 'internal'.
Production release track configuration in eas.json
To set up production release configuration, change the track property under submit.production.android profile in eas.json to 'production' value.
Submit Android build to Play Store
After configuring the track in eas.json, run: eas submit --platform android. This command will automatically upload the production build and release it to the specified track (internal or production) on Google Play Store.
Google Service Account key for automated release
A Google Service Account email and JSON key is required to automate the release process with EAS Submit. The JSON key must be uploaded to the EAS dashboard under project Credentials > Android > Application identifier > Service Credentials > Add a Google Service Account Key.
Prepare iOS app for App Store submission
In App Store Connect, go to the App Store tab and provide metadata details, screenshots as per Apple's guidelines, and fill in details under General. Then manually select the build. Once the app is ready, click Submit to App Review. Apple will review the app and if approved, it will be available on the App Store.
Submit iOS app binary to App Store with eas submit
To submit an iOS app binary created from an EAS Build, run: eas submit --platform ios. This command prompts you to select a build from EAS (typically the latest build ID) and log in to Apple account. When asked to 'Reuse this App Store Connect API Key?', press Y to proceed with the submission process.
Release iOS internal testing version via TestFlight
After submitting the build, log in to the Apple Developer account, go to Apps, select the app, click TestFlight in the navigation menu. Create a test group under Internal Testing to invite test users. An email will be sent to test users with a link to View in TestFlight. Test users can accept the invite and tap Install to download the app for testing. Internal testing has a limit of 100 users.
iOS app submission compliance: ITSAppUsesNonExemptEncryption
If you have skipped the iOS development build for devices chapter, you will be prompted whether the iOS app uses standard/exempt encryption. If your app does not use encryption, select Y to set ITSAppUsesNonExemptEncryption in the Info.plist file to NO, which manages the compliance check for releases to TestFlight and App Store. If your app uses encryption, select N to skip this prompt.
TestFlight external testing capacity and features
Similar to internal testing, TestFlight allows creating a group for inviting external testers. External testing allows sharing a test release version with up to 10,000 testers and provides a publicly shareable link. This differs from internal testing which has a limit of 100 users.
EAS Submit for app store uploads
EAS Submit documentation covers uploading apps to Google Play Store and Apple App Store with a single CLI command.
Automate submissions guide for EAS Build
The automate submissions guide covers enabling automatic submissions with EAS Build to app stores.
EAS Submit uploads apps to app stores
EAS Submit is referenced as part of Expo Application Services for submitting apps to app stores. A standalone app or production build can be submitted to the Google Play Store or Apple App Store.
Credential encryption at rest with KMS
Credentials stored by Expo are encrypted at rest by Google Cloud. Credentials are additionally encrypted using KMS (Google Cloud Key Management Service). Credentials are only unencrypted for as long as needed in memory in standalone app builders or push notification services. Credentials are always encrypted in databases, message queues, and other less transient parts of the system.
Android keystore and build credentials encryption
A keystore and keystore password are required to sign a build for release to the Play Store. These are encrypted with KMS and additionally at rest. For apps using App signing by Google Play (default for new apps), Google holds the app signing key and your keystore is the upload key. The keystore alone does not let you submit to Google Play; your Google account also needs access to the Google Play Console.
Android keystore recovery with App signing by Google Play
If your app uses App signing by Google Play and your keystore is lost or compromised, you can create a new keystore and ask Google to reset your upload key. After the reset, Google Play no longer accepts builds signed with the compromised key. You cannot update your app until Google completes the reset.
Google Developer credentials never requested by Expo
Expo tools never ask you to provide your Google account credentials.
Google Service Account Key encryption and storage
The Google Service Account Key is the authentication method used to submit an Android app to Google Play Store with EAS Submit. This key is stored on Expo servers and encrypted using KMS when at rest. The key remains on Expo servers for reuse in subsequent submissions and can be removed at any time by a user with requisite permissions.
Google Service Account Key compromise impact
If a malicious actor gains access to a Google Service Account Key, they can perform actions in Google Play Console on your behalf, limited to the permissions granted to that service account key. If they also have the upload keystore, they can submit a new version of an existing app, but cannot submit a new app to Google Play Store, as first submission requires web console access.
iOS APNs auth key (p8) and key ID credentials
Modern iOS push notification credentials consist of an APNs auth key (p8) and key ID (string). Each developer account has up to two auth keys, each of which can send notifications to any app on the account. Auth keys are revocable from the Apple Developer Center. Revoking them stops notifications from working. Provisioning a new auth key and uploading to Expo resumes notifications. Device tokens are not invalidated when auth keys are revoked.
iOS APNs auth key recovery
If an iOS APNs Auth Key is lost, it can be revoked through the Apple Developer console and replaced with a new key. The Apple Developer console only allows downloading an APNs Auth Key when it is first created.
iOS build credentials encryption and management
iOS build credentials refer to the production distribution certificate and password (automatically generated if Expo manages them) and provisioning profiles (which are not secret). These are all encrypted with KMS. Build credentials let you build an app to upload to App Store Connect, but you need Apple Developer account credentials to upload and submit for review.
Apple Developer account credentials not stored on Expo servers
Apple Developer account credentials are not stored on Expo servers. EAS CLI uses them locally only. Your computer provisions distribution certificates and auth keys that are sent to Expo servers, but developer credentials are not sent to Expo servers. Apple enforces two-factor authentication for all Apple Developer accounts.
Apple ID credentials in macOS Keychain
By default, Apple ID credentials are stored in the macOS Keychain. Your password is only stored locally on your computer. This feature is not available for Windows or Linux users. Disable Keychain support with the environment variable EXPO_NO_KEYCHAIN=1.
Deleting Apple ID password from Keychain
To delete the locally stored Apple ID password, open the Keychain Access app, switch to All Items, and search for 'deliver.[Your Apple ID]' (example: deliver.bacon@expo.dev). Select the item and delete it. Next time running an Expo command you will be prompted for a new password.
Apple App Store Connect (ASC) API key for submission
Apple App Store Connect (ASC) API key is an authentication method for submitting iOS apps to Apple's App Store using EAS Submit. This key is stored on Expo servers and encrypted using KMS when at rest. The key remains on Expo servers for reuse in subsequent submissions and can be removed at any time by a user with requisite permissions. ASC API key is the default and recommended authentication method for submitting apps to App Store using EAS Submit.
ASC API key compromise impact
If a malicious actor gains access to an ASC API key, they can perform actions in App Store Connect on your behalf, limited to the permissions granted to the API key. If they also have build credentials, they can submit a new version of an existing app signed with those credentials, but cannot submit any arbitrary app to the App Store.
Apple app-specific password storage and retention
Apple app-specific password is an authentication method for submitting iOS apps using EAS Submit. Unlike other credentials, it is not stored between submissions; it must be provided each time. The password is encrypted using KMS and stored only for the period required to submit the app plus 24 hours for retries. After this period, the password is deleted from Expo servers. This authentication method is not recommended; ASC API key is recommended instead.
Apple app-specific password compromise impact
If a malicious actor gains access to an app-specific password, they can access information like mail, contacts, and calendars stored in iCloud. If they also have build credentials, they can submit a new version of an existing app signed with those credentials, but cannot submit any arbitrary app to App Store.
Downloadable and removable credentials from Expo
All data related to credentials can be downloaded and removed from Expo servers if it is stored there. Some credentials may be available through other locations such as the Apple Developer Portal or Firebase console.