Publishing to the stores

Overview

Publishing your Emergent-built mobile app to the App Store and Google Play is handled through Emergent's managed build pipeline, you do not need an Expo account, the

eas-cli

, or any local build tooling. Emergent manages EAS on your behalf. This guide explains how store builds are triggered, how signing credentials work, and what you need to provide to get your app live.

Note

All native builds (APK / AAB / IPA) require a paid Emergent plan. Builds are triggered from the Publish panel and are built from your last published code, fix issues, re-publish, then rebuild.

Before you begin

You need two things before triggering a store build:

Enroll in the Apple Developer Program

Visit developer.apple.com/programs and enroll. You cannot submit an iOS app without an active paid membership ($99/year for individuals).

Create a Google Play Console account

Register at play.google.com/console. Google charges a one-time $25 registration fee. You register your app's package name here, Emergent seeds a default package name (

com.emergent.<words>.<suffix>

) into

app.json

at setup, and you can edit it in the pre-populated first-build form.

Do NOT modify eas.json

Emergent manages your EAS configuration. Editing

eas.json

manually can break the build pipeline.

How builds work

Emergent uses its own Expo/EAS infrastructure to produce your

.ipa

(iOS) and

.aab

(Android) binaries. You never install

eas-cli

, log in to Expo, or run builds yourself.

To trigger a native build:

Fix and re-publish

Make sure your app is in a working state and re-publish it from the Publish panel. Builds always use the last published code.

Open the Publish panel

Navigate to the Publish panel inside your project on app.emergent.sh.

Trigger the build

Select your target platform (iOS or Android) and start the build. The pipeline runs in Emergent's cloud, no Mac required for iOS.

iOS vs Android publishing flow

Step	iOS (App Store Connect)	Android (Google Play Console)
Build artifact	`.ipa` (uploaded to testflight directly)	`.aab` Android App Bundle (produced by Emergent's pipeline)
Store listing	Create app record in App Store Connect; add screenshots, description, support URL, privacy policy	Create app record in Play Console; add screenshots, description, privacy policy, content rating questionnaire
Compliance	Privacy Nutrition Label (declare data collection); declare third-party SDKs	Data safety form; declare permissions; complete content rating questionnaire
Store upload	TestFlight upload is done for you as part of the build pipeline	Upload `.aab` directly in Play Console
Review timeline	Apple typically reviews iOS submissions within 1-3 days.	Google Play reviews are often completed same-day but going live requires 14 days of active testing across 12 real testers
Rejection handling	Apple provides feedback in Resolution Center; fix, re-publish, rebuild, and resubmit	Google sends email with policy violation details; fix, re-publish, rebuild, and resubmit

Privacy & compliance

Both stores require you to disclose what data your app collects:

iOS Privacy Nutrition Label: In App Store Connect, declare each data type (location, contacts, analytics identifiers, etc.) and whether it is linked to the user's identity.
Android Data safety: In Play Console, complete the data safety form with similar disclosures.

If you integrate third-party SDKs (analytics, crash reporting, authentication), review their documentation for required disclosures.

Signing credentials

Android signing

If you built your app on Emergent from the start, signing is fully handled for you: Emergent generates and holds the signing key and uses it for every build. Just click Publish, then Build, and submit the resulting

.aab

to the Play Console - there is nothing to configure.

The exception is when you already have an app listed on the Play Store with the same package name, signed with its own key. The new AAB won't match the listing's signing key, so the upload fails with a keystore mismatch. To resolve it, contact support@emergent.sh - there are two ways, and support will help you pick:

Align Emergent to your key: share your existing
```
.jks
```
file and keystore credentials, and Emergent updates the signing setup on our side.
Align Google to Emergent's key: Emergent provides SHA fingerprints and a
```
.pem
```
file that you upload in the Google Play Console as an upload-key reset. The Google side typically takes 2-3 business days to process.

Keep your own keystore safe

If you manage your own keystore, never commit the keystore file or its passwords to version control. If you lose your keystore, you cannot update your existing Play Store app - you would need to publish as a completely new app.

iOS signing

iOS signing is fully Emergent-managed. The App Store Connect API key is auto-created and managed by Emergent. If you need push notifications, ask the agent to set up Emergent-managed push notifications and share the push credentials it asks for (your APNs

.p8

push key for iOS, your Firebase service-account key for Android) before you re-publish and build - missing push credentials will cause the build to fail. The TestFlight upload step is handled for you as part of the pipeline.

App updates after publishing

When you need to release a new version:

Make your changes and re-publish

Fix or update your app, then re-publish from the Publish panel. Builds always use the last published code.

Trigger a new build

Start a new build from the Publish panel for the target platform.

Submit to the stores

For Android, upload the new

.aab

to Play Console. If the upload fails with a keystore mismatch on an app that was on the Play Store before Emergent, see Android signing above. For iOS, the pipeline handles the TestFlight upload; you then promote the build to App Store review in App Store Connect.

Every update ships through a new build

Emergent does not support over-the-air updates. All changes, including JavaScript-only changes, ship by re-publishing, generating a new build, and submitting it to the stores.