Get your app into users’ hands — build installable binaries in the cloud with EAS, push instant JS updates over the air, and submit to the App Store and Google Play.
Why: shipping a real app means producing signed native binaries (.ipa for iOS, .aab for Android) — which normally needs a Mac and Android SDK. EAS Build does it in the cloud from any machine, handling signing for you. Configure once, then build per platform.
Install the CLI and log in
npm install -g eas-clieas loginOne-time project config, then build
eas build:configureeas build --platform ioseas build --platform androidWhy: app-store review is slow, but most fixes are just JavaScript. EAS Update ships JS/asset changes directly to installed apps — users get the fix on next launch, no review, no reinstall. Note: native code changes still require a new store build; only JS-level changes can go over the air.
JS / asset change ─ eas update ─▶ delivered on next app launch (no review)
native code change ─ eas build ─▶ new store submission (full review)Why: once you have a build, eas submit uploads it to App Store Connect and Google Play Console. From there you fill in the listing — screenshots, description, privacy details — and send it for review. Apple review takes a day or two; Google is usually faster.
Upload the latest build to each store
eas submit --platform ioseas submit --platform androidNote: both stores reject avoidable mistakes. Set a unique bundle identifier / package name, app icon, and splash screen. Provide screenshots for required device sizes. Declare what data you collect (Apple's privacy nutrition label, Google's Data Safety form) and request only permissions you actually use — unused permissions are a common rejection. Bump the version and build number on every submission.
✓ unique bundle id / package name, icon, splash screen
✓ screenshots for required device sizes
✓ privacy disclosures (Apple nutrition label / Google Data Safety)
✓ only the permissions you actually use
✓ version + build number bumped each submission