iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To launch a React Native app, build and test the signed production version, then complete the separate listing, declarations, review, and rollout steps in App Store Connect and Google Play Console. A successful build or upload alone does not publish an app. Use this checklist in order, adapting it to your app’s features and whether it uses native project folders or Expo/EAS.
1. Define the release before building
Start by recording which platforms and stores you are targeting, the app’s identifiers, and the release version. Decide whether you will build from the React Native ios and android projects or use Expo’s EAS build workflow. That choice changes the build steps, but not the need to configure signing, prepare store materials, and submit the app.
If your project uses Expo Continuous Native Generation and does not have native project folders, Expo’s local-build workflow may require generating them with prebuild. See the Expo local builds documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Inventory features that may affect store declarations or review preparation: for example, location, camera, health data, accounts, advertising, in-app purchases, user-generated content, or regulated data. The correct declarations depend on the app itself and the current store rules; there is no universal answer for an unspecified app.
#1 Best Overall
2. Prepare production settings and versioning
Before creating a release artifact, verify the production configuration. These are practical engineering checks rather than a universal store-mandated checklist:
- Confirm API endpoints, environment variables, authentication, push notifications, deep links, analytics, crash reporting, and feature flags point to the intended production environment.
- Check that permissions and entitlements match shipped functionality, and remove development-only settings and credentials from the release configuration.
- Confirm the app’s minimum OS versions and version/build identifiers. For an Android update, advance the version code so the store can distinguish it from the prior release; see the Android versioning documentation.
- Make sure the people responsible for release have access to the developer accounts and signing credentials they need.
Check current upload requirements
Store toolchain and target-API rules change. The independently maintained React Native compatibility matrix, updated October 7, 2026, reported that new Google Play apps and updates must target Android API 36 or higher effective August 31, 2026, and that App Store Connect submissions require Xcode 26 or later with the iOS 26 SDK effective April 28, 2026. These are time-sensitive platform requirements, not permanent React Native rules: confirm the current requirements with Google Play’s target API requirements and Apple’s upcoming requirements for each release. The matrix listed React Native 0.87.1 as current on October 7, 2026; check its live compatibility information rather than assuming that version or its toolchain row is still current.
Rank #2
3. Create and sign the release artifact
iOS: archive with the Release scheme
- In Xcode, choose the
Releasescheme and an iOS device destination, then archive the app. React Native’s iOS publishing guide explains that the Release scheme disables the in-app Dev Menu and bundles JavaScript locally, so the app can run without a development server. - Check that the Xcode Bundle Identifier exactly matches the identifier registered in your Apple Developer account.
- Choose automatic or manual signing deliberately and verify that the necessary distribution credentials are available to the release operator. Keep control of credentials and recovery access within the team.
Android: build a signed App Bundle
- Configure the release build to use the release signing credentials required for distribution through Google Play. Keep the keystore and passwords out of source control, and document who owns them and how the team can recover access.
- Build an Android App Bundle (AAB), the artifact used for Google Play distribution. React Native’s Android publishing guide gives this command:
npx react-native build-android --mode=release. The guide identifies the resulting bundle atandroid/app/build/outputs/bundle/release/app-release.aab. - Check that
org.gradle.configureondemand=trueis not causing the release build to skip bundling JavaScript and assets. Configure Google Play App Signing for AAB distribution as described in the React Native guide.
If you enable Android shrinking or obfuscation, test the resulting build carefully; native library configuration may be needed.
Optional route: build with Expo EAS
For an EAS production build, configure the production profile and use the platform command that matches the release: eas build --platform ios, eas build --platform android, or eas build --platform all. Confirm the intended developer accounts and signing credentials are configured. EAS can manage signing setup, but the team still needs a clear access and recovery plan. Expo lists Apple Developer Program membership and Google Play Developer membership as prerequisites for the respective store distribution workflows; check current account terms in the Expo production builds documentation.
Rank #3
4. Test the build users will install
Do not rely only on a development session. Install and exercise the signed Release build so you can catch issues that do not appear when the app runs with development tooling. React Native specifically advises thoroughly testing the Android release build before upload; its JavaScript and assets are packaged into that artifact.
For iOS, distribute the release archive through a beta route such as TestFlight and test it under realistic conditions. Apple’s TestFlight overview describes beta testing; a TestFlight build is for testing, not public App Store release.
Rank #4
Run a focused pre-release test
- Install fresh, then upgrade from the previous public version where practical.
- Test sign-in and sign-out, offline or poor-network behavior, permissions, notifications, and deep links.
- Exercise billing or purchase flows if the app has them, plus critical paths on representative device sizes.
- Verify production backend settings and crash reporting. If review requires access to gated functionality, provide suitable valid review notes or test credentials where relevant.
- Check the Android build again if shrinking or obfuscation is enabled.
This is a practical QA selection, not an exhaustive official store checklist. Which cases matter depends on the app’s features and user flows.
5. Complete the store listing and declarations
Uploading a binary does not complete a launch. Prepare the listing and declarations based on the actual product, then select the intended build for review. Review the applicable requirements for privacy disclosures, content ratings, permission explanations, encryption/export questions, payment configuration, and other declarations; their answers cannot be determined without inspecting the app.
App Store Connect
- Upload the iOS archive to App Store Connect and wait for processing.
- Complete the listing information and required screenshots. React Native’s iOS publishing guide notes that screenshots for some display sizes can cover other sizes.
- Select the processed build, save the release details, and submit it for App Review.
- After approval, use the release controls appropriate to the intended launch; an uploaded or TestFlight build is not automatically a public App Store release.
Google Play Console
- Upload the signed AAB in Play Console and complete the app listing and release setup.
- Choose the intended testing or production track. Expo’s store submission documentation describes EAS submission to internal, alpha, beta, or production tracks. A new app may start with internal testing and require additional Play Console setup before broader distribution.
- Review the selected track and rollout settings before releasing. A build upload and its eventual availability to users are separate steps.
6. Roll out and monitor
Choose whether to release manually after approval or use the store’s rollout controls and testing tracks. Match the initial rollout to the team’s ability to support users and respond to problems. Assign an owner to monitor crashes, sign-in failures, purchase flows, support contacts, and store feedback, and decide in advance when an issue calls for a hotfix or a pause in rollout.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
