Shipping to the App Stores

Writing the app is most of the work, but it isn't all of it. Getting a React Native app from source code into an actual store listing a user can download involves a real sequence of steps — building a release binary, signing it, submitting it for review — each with its own real, occasionally frustrating requirements that are worth understanding before the first submission, not discovering during it.

Debug builds vs. release builds

Every React Native project can be built in (at least) two distinct modes. A debug build is what you run during development: it keeps the in-app developer menu, generally runs less optimized JS, and is built for fast iteration, not end-user performance. A release build is the opposite: the JS bundle is optimized and minified, the developer menu is stripped out entirely, and the binary is built for real-world performance rather than developer convenience. App stores only accept release builds for submission — a debug build isn't just slower, it's not a valid submission at all.

Debug build:    unoptimized JS, dev menu available, fast rebuild, for developers
Release build:  minified/optimized JS, no dev menu, slower to produce, for users

Building a real binary

A release build produces a real, platform-specific artifact: an .ipa file for iOS, and either an .apk or an .aab (Android App Bundle) for Android. These aren't abstractions — they're the actual files a store accepts for submission, and the same kind of file you'd install directly on a device for internal testing outside of a store entirely.

Code signing: real, required, and often the frustrating part

Both platforms require a binary to be signed before it can run outside of development, or be submitted anywhere. On iOS, this means a provisioning profile and a certificate, issued through Apple's developer program, tying the binary to a specific developer account (and, for non-App-Store distribution, specific devices). On Android, it means signing the binary with an app-signing key — a credential you (or a service acting for you) control, and which Google Play can also manage on your behalf through Play App Signing.

This step has a real reputation for being the most fiddly part of shipping a React Native app — expired certificates, mismatched provisioning profiles, and lost signing keys are all genuine, common failure modes, not exaggerated folklore. It's also non-negotiable: neither platform will run an unsigned release binary or accept an unsigned submission.

App store review

Once signed and uploaded, a submission goes through the relevant store's review process. Apple's App Store review is a real process that can reject a submission for policy reasons (violating a guideline) or technical reasons (a crash found during review, a broken feature) — historically described as more manual and stricter than Android's equivalent. Google Play's review process is generally faster and leans more heavily on automated checks, though it's still a real review that can reject a submission. Exact timelines and strictness for either store shift over time, so this is worth understanding at the level of "both are real gatekeepers with different postures," not memorizing a specific current turnaround time.

Expo's managed path: EAS Build and EAS Submit

For teams building on Expo, EAS Build and EAS Submit are real, current, managed services that handle much of this complexity: EAS Build produces signed release binaries in the cloud (often without needing a local Mac for iOS builds), managing certificates and provisioning behind a simpler interface, and EAS Submit can push the resulting binary directly to the App Store or Play Store's submission pipeline. This doesn't remove code signing or store review — both still happen — it removes a meaningful amount of the manual credential-wrangling and local toolchain setup around them.

Over-the-air (OTA) updates: shipping JS without a resubmission

Separately from the store submission pipeline, React Native supports over-the-air (OTA) updates: pushing a new JS bundle (and assets) directly to installed copies of the app, without going through a full store resubmission and review cycle. This is genuinely useful for fixing a JS- only bug quickly, without waiting on review turnaround. The real, long-standing constraint: an OTA update can only change JS and assets — it categorically cannot change native code, add a new native module, or alter anything that would require a new compiled binary. Both app stores also have explicit policies constraining what an OTA update is allowed to change, specifically because it's a channel that bypasses the native-binary review process, and stores don't want that channel used to smuggle in changes review would otherwise catch.

Putting the pieces together

A realistic mental model of shipping: build a release binary (.ipa / .aab), sign it with the platform's required credentials, submit it through the store's review process (directly, or via a managed service like EAS Submit), and afterward, use OTA updates for the JS-only fixes and tweaks that don't need a full new binary — reserving a real resubmission for anything touching native code.

What to remember

• A release build (optimized JS, no dev menu) is what stores accept; a debug build is for development only, never a valid submission.
• The actual submitted artifacts are real platform binaries: .ipa for iOS, .apk/.aab for Android.
• Code signing (provisioning profiles/certificates on iOS, an app-signing key on Android) is required, not optional, and a genuinely common source of friction.
• Apple's App Store review and Google Play's review are both real gatekeepers, with Apple's historically more manual and Google's more automated — exact strictness and timelines shift over time.
• Expo's EAS Build/Submit is a real, current managed service simplifying the build-and-submit pipeline; OTA updates can ship JS-only fixes fast, but never native code, and both stores constrain what an OTA update may change.