Store publishing

Prepare your first store submission step by step

First create and test a native development build using Mobile builds. A store submission sends the compiled app and its listing to Google or Apple for review; it is not the same as opening an Expo Go preview. You need your own Expo and relevant store developer accounts, a tested HTTPS backend, final app name/icon, screenshots, support contact and a public privacy-policy URL.

Open apps/mobile/app.json in the editor and set the app name, slug, ios.bundleIdentifier and android.package for your own product before the first upload. Open apps/mobile/eas.json and replace the iOS submission team's app identifiers with your own where required. The shipped identifiers are examples. Read Mobile builds for the exact fields and ask your coding agent to review the two files before building.

If eas is not installed, run npm install --global eas-cli. From the repository root use the login command below, finish browser authentication, then select the build command for one platform in Build, then submit. Read the build's dashboard logs; wait for a successful .aab or .ipa before attempting submission. EAS prompts for project linking and signing credentials; these belong to your accounts, not the kit seller's.

After the binary is uploaded, open your app in Play Console or App Store Connect, complete the listing and required questionnaires, add working reviewer sign-in instructions, then submit for review there. Uploading an internal draft is not a public release. If review rejects it, open the exact policy link in the rejection and correct that issue before resubmitting.

• Prepare the native build and identifiers
• Expo's current store submission instructions
• Apple's current App Review guidelines
• Google Play release instructions

corepack pnpm --filter @supastack/mobile exec eas login

Set up the accounts once

Store submission needs three accounts: a free Expo account for EAS Build and Submit, a Google Play Console developer registration, and an Apple Developer Program membership for iOS. Install the EAS CLI and run eas login before building; both store enrollments can take days to verify, so start them early.

Rename the application identifiers before the first upload — android.package and ios.bundleIdentifier ship as com.supastack.app in apps/mobile/app.json. Google Play locks the package name at first upload, so a wrong identifier means a new app entry rather than a rename.

Let EAS manage signing

apps/mobile/eas.json defines development, preview, and production build profiles. The production profile lets EAS generate and hold the Android keystore and iOS distribution certificate on its infrastructure — inspect them later with eas credentials, and keep local keystores out of the repository.

Automated Play submission needs a Google Play service-account JSON key linked under Play Console → Setup → API access with release permission. Store it at apps/mobile/secrets/play-store-service-account.json — the path eas.json expects and a git-ignored directory. The first upload of a new app still happens manually in Play Console; eas submit takes over from the second release.

Build, then submit

Builds run on EAS infrastructure, so no Android Studio or Xcode install is needed for the binary. The production profile produces a store-ready .aab for Play and .ipa for the App Store with remote-managed version numbers. The preview profile produces an internal-distribution APK for physical-device QA.

The shipped submit profile targets the Play internal track as a draft release — nothing reaches testers until you promote it inside Play Console after review passes.

corepack pnpm --filter @supastack/mobile build:android
corepack pnpm --filter @supastack/mobile submit:android

corepack pnpm --filter @supastack/mobile build:ios
corepack pnpm --filter @supastack/mobile submit:ios

# Internal-testing APK for a physical device:
corepack pnpm --filter @supastack/mobile build:android:preview

Fill the Play Console forms

Play review gates on declared content as much as the binary: a public privacy policy URL, the Data safety form, the content-rating questionnaire, target audience, and category. Answer Data safety from the app's real behavior — the kit collects account email for authentication, stores session tokens in platform secure storage, and talks only to your configured API; add whatever your product adds on top.

For an iOS app that requires sign-in, provide App Review with a working demo account and instructions in the review notes. Review Apple's current login-services rule and its exceptions before choosing social sign-in options; the requirements depend on the app's actual login flow. The official guidelines are linked in the first-submission section above.

Gate purchases behind RevenueCat first

When your app offers mobile purchases, configure the shipped RevenueCat flow: set MOBILE_PURCHASES_PROVIDER=revenuecat and EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat, then provide the matching public iOS or Android SDK key. The native app supports purchase and restore; after either, access refreshes from the server-verified workspace entitlement. Stripe Checkout is not used in the mobile flow. Keep the paywall unavailable when purchases are off or required configuration is missing. Validate configured store products, purchase, restore, and entitlement refresh in an EAS development build with store test accounts. Check current store guidance for requirements that apply to your app and regions.

Pre-submission checklist

Before submitting, confirm every item below using your own test app and store accounts.

• android.package and ios.bundleIdentifier renamed to an identifier you own
• EXPO_PUBLIC_API_URL in the build environment points at the production API
• Privacy policy hosted at a public URL and linked in the store listing
• Data safety form matches real collection: auth email, API traffic, anything your product adds
• Working demo-account credentials in the App Store review notes
• Paywall hidden, or backed by a verified RevenueCat entitlement
• Deep-link return, session restore, and sign-out verified on a physical device
• Screenshots and listing assets prepared for each store

Recover from a rejection

Rejections arrive with a policy reference — fix the declared cause rather than guessing at the symptom. A Data safety mismatch usually means the form is wrong, not the app. A login-required rejection usually means the review notes lacked a demo account. Resubmit with release notes that name the fix plainly.

The full walkthrough — credential commands, console order of operations, and a rejection playbook — lives in docs/mobile-store-submission.md in the repository.

Setup and configuration

Shipping native needs Apple and/or Google developer accounts, app identifiers, signing credentials, and store review. The production EAS profile increments store build numbers; submit.production targets a draft release on Google Play's internal track. Bundle identifiers and the app scheme live in apps/mobile/app.config.ts.

Web deploys and store releases move at different speeds — keep the API compatible with the oldest supported build, or gate new capability behind server-driven state.

corepack pnpm --filter @supastack/mobile build
eas build --profile production --platform ios
eas build --profile production --platform android
eas submit --profile production --platform ios
eas submit --profile production --platform android

Implementation workflow

Set the RevenueCat project, store products and entitlement before enabling native purchases. Put the server secret key and webhook Authorization value only in server environment configuration; the iOS and Android SDK keys are public build values. Production must keep sandbox access disabled.

Keep store metadata — screenshots, description, privacy answers, and purchase disclosures — in release materials owned by the product. RevenueCat purchases and restores are checked against current server subscriber state before the app shows access.

Verification and troubleshooting

Test the exact artifact you submit: sign-in callback, session restore, purchase and restore, server entitlement refresh, workspace switching, deep links, and offline behavior on a physical device. A successful local export is not a store-ready build.

Record build number, store track, review status, and the API environment each release targets. A rejected review is a release event — fix metadata or capability flags rather than guessing at code.

Next surface: the Desktop tab walks the same product through the Tauri shell.