#How to Export an Emergent AI Mobile App and Publish It to the Google Play Store
Step 1: Export Your Emergent Codebase and Audit app.json
Open your project inside the Emergent workspace, click the GitHub export option in your project settings, and push the codebase to a private GitHub repository.
Open your computer's terminal, clone the repository locally, and install the project dependencies
app.json file in your code editor. When Emergent generates a project, it fills app.json with placeholder metadata. You must add a unique android.package identifier (using reverse-domain format) and explicitly define an initialDouble-check that your adaptiveIcon path points to a real square PNG image inside your assets folder. If that file is missing or corrupted, the cloud compiler will fail halfway through the build.
Step 2: Set Up Expo EAS CLI for Cloud Compilation
Instead of downloading gigabytes of Android SDK tools onto your laptop, you can use EAS Build to compile your .aab file on Expo's remote Linux servers.
First, create a free account at expo.dev. Next, install the EAS CLI globally on your machine and link your local project folder to your Expo account
# 1. Install the Expo Application Services CLI
npm install -g eas-cli
# 2. Authenticate with your Expo account
eas login
# 3. Generate the eas.json build configuration file
eas build:configure
When the terminal asks which platforms you want to configure, use your arrow keys to select Android and press Enter. This creates an eas.json file in the root of your project.
Open eas.json and update the production block so that it generates an Android App Bundle (.aab) and automatically increments your versionCode every time you push a new release to Google Play
{
"cli": {
"version": ">= 12.0.0",
"appVersionSource": "remote"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"android": {
"buildType": "apk"
}
},
"production": {
"autoIncrement": true,
"android": {
"buildType": "app-bundle"
}
}
}
}
Pro Tip: Notice the
"preview"profile in the configuration above. If you ever want to install your app directly onto your own Android phone to test it without going through the Google Play Store, runeas build --platform android --profile previewto get a direct-install.apkfile.
Step 3: Compile and Sign the .aab File in the Cloud
With your eas.json configured, trigger your official Play Store production build by running
eas build --platform android --profile production
During your very first build, the CLI will pause and ask: "Generate a new Android Keystore?"
Press Y (Yes). EAS will automatically create a cryptographic RSA signing key, sign your .aab bundle with it, and store the keystore inside your encrypted Expo cloud account. You never have to worry about losing a local .jks file on your hard drive, and every future update you build will automatically use the exact same signature.
Once the build finishes in the cloud (usually within 10 to 15 minutes), the terminal will provide a direct download link for your signed .aab file.
Step 4: Fixing 3 Common Emergent & Expo Production Bugs
Many developers celebrate when their .aab build succeeds, only to discover that the app crashes immediately on startup or gets rejected by Google Play's automated scanner. Below are the three most common production bugs in exported Emergent apps and how to fix them.
Bug 1: App Crashes on Startup Because .env Keys Are Missing
When you build an app inside Emergent, your environment variables (such as your Firebase configuration, Supabase URL, or Gemini API keys) live inside a local .env file. However, for security reasons, EAS Build ignores local .env files listed in your .gitignore. When the cloud server compiles your .aab, those API keys evaluate to undefined, causing your app to crash the moment it launches on a real phone.
The Fix: Any public frontend variable in an Expo app must start with the EXPO_PUBLIC_ prefix (for example, EXPO_PUBLIC_FIREBASE_API_KEY). Before running eas build, push your environment variables securely to Expo's cloud servers by running:
# Push your local .env variables to the EAS Cloud environment
eas env:create --scope project --name EXPO_PUBLIC_API_URL --value "https://your-api-url.com" --type string --visibility plain
Alternatively, open your project dashboard on expo.dev, navigate to Environment Variables in the left sidebar, and paste your .env key-value pairs directly into the Production environment.
Bug 2: OAuth Logins Hang Forever in Standalone Builds (exp:// vs Custom Scheme)
During development, social sign-in flows (like Google OAuth or magic links) redirect back to your app using Expo's development proxy (exp://192.168...). Once your app is compiled into a standalone .aab binary, the exp:// protocol no longer exists on the user's phone, leaving users stuck on a browser loading screen after they sign in.
The Fix:
Ensure you defined a unique
"scheme": "yourappscheme"inside yourapp.jsonfile (as shown in Step 1).Because EAS generated your Android Keystore in the cloud, you need to fetch that remote SHA-1 fingerprint and add it to your Firebase or Google Cloud OAuth console. Run this command in your terminal:
Bug 3: Google Play Rejects the .aab for Undeclared AD_ID Permissions
When you upload your .aab to the Google Play Console, you may receive a blocking error stating that your manifest declares the com.google.android.gms.permission.AD_ID permission without a valid Advertising ID declaration. Even if you aren't showing ads yet, certain React Native analytics dependencies inject this permission automatically.
The Fix: If your app does not display mobile ads or track advertising IDs, strip the permission out of your compiled Android manifest by adding the blockedPermissions array inside the android block of your app.json file:
"android": {
"package": "com.yourbrand.appname",
"blockedPermissions": [
"com.google.android.gms.permission.AD_ID"
]
}
Step 5: Deploying to Google Play Console & Passing Closed Testing
With a clean, signed .aab downloaded to your computer, log in to your Google Play Console account. If you are using a personal developer account created after November 2023, Google enforces a mandatory quality gate: your app must remain installed on at least 12 testers' devices continuously for 14 days before you can unlock public store distribution. Here is the fastest workflow to clear the 14-day review using an Expo project:
1. Complete the Mandatory "App Content" Declarations FirstBefore uploading your binary, go to the left sidebar menu, scroll down to Policy and programs, and select App content. Complete all required questionnaires (Privacy Policy URL, Data Safety, Target Audience, and Government Apps). Google Play will not let you roll out a test release until these forms are submitted.
2. Upload Your .aab to the Closed Testing Alpha TrackNavigate to Test and release, click Testing, and select Closed testing. Click Manage track next to the Alpha track and create a new release. Upload the .aab file you downloaded from EAS Build, add your release notes, and roll out the build.
3. Onboard 18+ Testers via a Google GroupInstead of typing email addresses manually, create a free Google Group (for example, my-app-testers@googlegroups.com) and select Google Groups as your tester management method inside the Closed Testing tab. Share your Google Group link and your Play Store Web Opt-In link in developer exchange communities like r/AndroidClosedTesting. Aim for 18 to 20 active testers so that if a few users wipe their phones during the two-week window, your active install count never dips below 12.
4. Ship One Seamless Update Using autoIncrementGoogle's review team wants to see that you actually acted on tester feedback during the 14-day period. Around Day 8, make a small UI improvement or bug fix in your code and run eas build --platform android --profile production again. Because we added "autoIncrement": true in eas.json, Expo automatically bumps your versionCode from 1 to 2. Upload that second .aab to your Closed Testing track—this proves active maintenance without resetting your 14-day timer.
No comments:
Post a Comment