Publish a React Native Expo App on Google Play: Testing Step

Short answer
To publish a React Native Expo app on Google Play, build an .aab with eas build, then get it onto a closed testing track. eas submit uses internal testing by default, which doesn't count. New personal accounts need at least 12 testers opted in to the closed test for 14 days before applying for production.

To publish a React Native Expo app on Google Play from a new personal developer account, build an .aab with EAS Build, get it onto a closed testing track in Play Console, and keep at least 12 testers opted in for 14 days in a row before you apply for production. The catch for Expo developers: eas submit sends your build to the internal testing track by default, and internal testing doesn't satisfy that requirement.

Expo's documentation covers building and submitting well, but it doesn't mention the 12-tester rule at all. This guide fills that gap, step by step.

Step 1: build the AAB with eas build
Run eas build --platform android --profile production. Expo's docs say the default production profile produces an .aab, the Android App Bundle that Google Play requires for new apps. You only get an APK if you set android.buildType to apk, and an APK can't be submitted to Google Play.

Make sure android.package is set in your app config, for example com.yourcompany.yourapp. That package name is permanent once the app is on Play.

By default EAS creates and stores the Android keystore for you. That's convenient, but download a copy anyway: run eas credentials, choose Android, and use the credentials.json option to download credentials from EAS. Keep the file private and out of your repository.

Step 2: let EAS handle the versionCode
Every upload to Play Console needs a higher version code than the last one. Expo's recommended setup is the remote version source: in eas.json set cli.appVersionSource to remote and add autoIncrement: true to the production build profile. EAS then bumps android.versionCode on every build.

You'll upload more than one build during a closed test if you fix bugs, so set this up before the first build. If you already uploaded builds by hand, Expo provides eas build:version:set to tell EAS the last version code you used.

Step 3: get the build onto the closed testing track
First create the app in Play Console and add a Google Service Account key in your Expo project's credentials. Expo says eas submit needs that key to upload on your behalf.

Now the part most guides skip. Expo's docs say a first eas submit creates the release on the internal testing track, and internal is also the default value of track in eas.json. Internal testing is fine for a quick install check with your own team, but Google's requirement for new personal accounts is a closed test.

You have two ways to get there. In Play Console, open Testing, then Closed testing, and promote your internal release to the closed track, which Expo's tutorial calls Closed testing - Alpha. Or set track to alpha under submit.production.android in eas.json, so that eas submit --platform android targets the closed track directly. The track values Expo documents are internal, alpha, beta and production.

If you'd rather do the first upload by hand, that's allowed too. Expo describes the manual upload as optional, and suggests choosing the Google-generated signing key so you can recover if you lose your keystore.

Step 4: 12 testers for 14 days
Google's rule for personal accounts created after November 13, 2023: at least 12 testers must be opted in to your closed test for the last 14 days continuously before you can apply for production access. Organization accounts are exempt.

Add testers to the closed track with an email list or a Google Group, then send them the opt-in link. Each tester accepts the invitation and then installs the app from Google Play. The 14 days only run while 12 or more are opted in, so invite 15 to 20 in case a few drop out.

When you apply, Google asks how you tested and what you changed. Testers who really open the app and report problems give you something true to write.

Step 5: ship fixes during the test
Found a bug on day 5? Fix it, run eas build again, and submit to the same closed track. With autoIncrement on, the version code takes care of itself. eas build --platform android --auto-submit does both in one command.

Keep the same track and the same tester list. Creating a new track or a new app mid-test can mean asking your testers to opt in all over again.

Step 6: apply for production
After 14 days, apply for production access from the Play Console Dashboard. Once it's granted, change track to production in eas.json, or promote the release in Play Console.

If finding 12 people who stay for two weeks is the hard part, PeerPlay is a free way to swap tests with other Android developers who open your app from Google Play every day. Paid VIP packages are available if you'd rather skip the swaps.