How to Publish a React Native App to the App Store

You typed a description of an app. An AI turned it into React Native code. The preview ran on your phone over a QR code, and it looked exactly like the thing in your head. Then you hit the wall no demo video ever shows: how do you actually get this onto the App Store?

That gap — between working code and a downloadable app — is where most first-time mobile builders stall. The good news: the path is short, well-documented, and mostly automated. This guide walks the entire route to publish a React Native app to the App Store (and Google Play), starting from a project exported out of RapidNative and ending with a live listing real users can install.

A finished mobile app is one App Store review away from real users — once you know the steps.

What It Takes to Publish a React Native App to the App Store

Publishing a React Native app to the App Store means compiling your JavaScript and native modules into a signed iOS binary (an .ipa file), uploading it to App Store Connect, and passing Apple's review. For Expo projects, two tools — EAS Build and EAS Submit — handle both steps from the command line, with no Mac or Xcode required.

It helps to see this as two distinct jobs, not one:

1. Build — turn your code into a native binary. iOS produces an .ipa; Android produces an .aab (Android App Bundle). This step compiles, links native dependencies, and signs the app with the right certificates.
2. Submit — upload that binary to Apple's App Store Connect or Google Play Console, attach your store listing (screenshots, description, icon), and send it for review.

A few years ago, the build step demanded a Mac with Xcode for iOS and a fully configured Android SDK for Google Play. Today, Expo Application Services (EAS) runs the whole build in the cloud, so a Windows or Linux user can ship an iPhone app. Here's the trade-off at a glance:

For almost everyone shipping an Expo app — and that includes every app generated by RapidNative — the EAS path is the right one. The rest of this guide follows it end to end.

Step 1: Start With a Project You Can Actually Export

Here's the part most "how to publish a React Native app" tutorials skip: they assume you ran npx create-expo-app and hand-wired everything yourself. If you built your app with an AI app builder, your starting point is different — and, done right, easier.

When you export a project from RapidNative, you don't get a loose pile of screens. You get a complete, buildable Expo project as a .zip — the same structure a senior React Native developer would scaffold by hand. Inside:

your-app/
├── app/                  # expo-router file-based routing
│   ├── (auth)/           # public screens (login, signup)
│   ├── (app)/            # authenticated screens
│   ├── _layout.tsx       # root layout
│   └── index.tsx         # home screen
├── components/           # reusable React Native components
├── assets/
│   ├── icon.png          # 1024×1024 app icon
│   ├── splash.png        # splash screen
│   └── adaptive-icon.png # Android adaptive icon
├── package.json
├── app.json              # Expo manifest
├── eas.json              # EAS build & submit profiles
├── tsconfig.json
└── .env                  # environment variables

That package.json pins a current, coherent stack — at the time of writing, Expo SDK 54, React Native 0.81, expo-router 6, React 19, and NativeWind 4 for styling. It also ships the scripts you'll need already wired up:

"scripts": {
  "start": "expo start",
  "ios": "expo start --ios",
  "android": "expo start --android",
  "build:production": "eas build -p all --profile production",
  "submit": "eas submit",
  "update": "eas update"
}

And the eas.json already defines three build profiles — development, preview, and production — so you don't have to run eas build:configure or guess the schema yourself.

This matters more than it looks. Many app builders never hand you the code at all — the app lives and dies inside their platform, and "export" means a screenshot. RapidNative generates real, production-grade React Native code you own, whether you started from a text prompt, a product requirements doc, a whiteboard sketch, or a screenshot of an app you like. (If you'd like a deeper look at how that export is assembled, see how RapidNative's export pipeline works.)

The exported project is plain React Native + Expo — no proprietary runtime, no lock-in. Photo by Chris Ried on Unsplash.

One practical note: exporting the downloadable code is a feature of RapidNative's paid plans. You can build, preview, and iterate on a project freely, but the .zip download lives behind a subscription — check the pricing page before you plan a launch timeline.

Step 2: Set Up Your Accounts and the EAS CLI

Before you can build, you need three accounts and one tool. None of this is RapidNative-specific — it's the standard cost of entry for any React Native app store submission.

1. An Expo account — free. Sign up at expo.dev. This is what EAS Build and EAS Submit authenticate against.
2. An Apple Developer Program membership — $99/year. Required for any app on the iOS App Store, including TestFlight betas. Enroll at the Apple Developer Program.
3. A Google Play Developer account — a one-time $25 fee. Required to publish on Google Play.
4. The EAS CLI — the command-line tool that drives everything. Install it globally:

npm install -g eas-cli
eas login

Budget a little lead time here. Apple's enrollment can take 24–48 hours to verify, and if you're enrolling as a company rather than an individual, you'll need a D-U-N-S number, which adds days. Start this step early — it's the most common reason a launch slips.

With the CLI installed, unzip your exported project and install dependencies:

cd your-app
npm install

Step 3: Build Your App in the Cloud With EAS Build

Now the fun part. Before your first build, open app.json and change one critical field: the bundle identifier. A fresh export ships with a placeholder like com.rapidnative.app for both ios.bundleIdentifier and android.package. Apple and Google require these to be globally unique and tied to you:

{
  "expo": {
    "ios": { "bundleIdentifier": "com.yourcompany.yourapp" },
    "android": { "package": "com.yourcompany.yourapp" }
  }
}

Pick this carefully — once an app is live, the identifier can't change. While you're in app.json, set a real name, slug, and version, and confirm the icon points at your 1024×1024 PNG.

Then trigger a production build:

# iOS
eas build --platform ios --profile production

# Android
eas build --platform android --profile production

# Or both at once
eas build --platform all --profile production

The --profile production flag maps to the production block already defined in your exported eas.json. EAS uploads your project to Expo's cloud, provisions a build machine, installs native dependencies, handles code signing for you — generating iOS certificates and provisioning profiles, or an Android keystore, on first run — and compiles. You'll get a URL to watch the build live. Ten to twenty minutes later, you have a downloadable .ipa (iOS) or .aab (Android).

This is the step that genuinely used to require a Mac. It no longer does. Everything from Metro bundling to signing happens on Expo's infrastructure, and the artifact is a real native binary — the exact same kind of file a hand-coded React Native project produces.

EAS Build compiles and signs your app in the cloud — no local Xcode setup required.

Step 4: Submit to the App Store and Google Play With EAS Submit

A signed binary isn't a published app yet. It still has to reach the stores and clear review. That's EAS Submit.

For the iOS App Store:

eas submit --platform ios --latest

The --latest flag grabs your most recent build automatically. EAS will ask for an App Store Connect API key — generate one in App Store Connect under Users and Access → Integrations — and upload the binary straight to Apple. From there:

• Your build appears in TestFlight, Apple's beta channel, usually within an hour. Test it with real users before going public.
• In App Store Connect, create the store listing: screenshots for each device size, app description, keywords, privacy details, and a support URL.
• Submit for review. Apple's review typically takes 24–48 hours in 2026, though it can be faster.

For Google Play:

eas submit --platform android --latest

Google Play has one quirk: the very first upload of a new app often has to be done manually through the Google Play Console, because the app listing must exist before the API can target it. Every release after that can go through eas submit. Google's review is generally quicker than Apple's — often hours rather than days.

A solid sequencing rule: build once, test on TestFlight or Google's internal track, fix what's broken, then submit for public review. If your app was generated by AI, this testing pass is where you catch the small stuff — a label that's too long on a narrow screen, a tab that needs a clearer icon. RapidNative's editor lets you click any element and describe the change in plain English, and you can test on a real device via a QR code before you ever touch a build. For a full pre-launch sweep, the App Store submission checklist covers everything reviewers look for.

Step 5: Ship Updates Without Re-Submitting Every Time

Here's something that surprises people coming from native development: not every change needs a new build and a new review.

Because a React Native app's UI and logic live in a JavaScript bundle, over-the-air updates let you push fixes directly to installed apps. With EAS Update:

eas update --branch production --message "Fix checkout button spacing"

Users get the change the next time they open the app — no store review, no waiting. The rule of thumb:

• JavaScript-only changes (copy, styling, layout, business logic) → eas update. Instant.
• Native changes (a new native dependency, an updated Expo SDK, a changed app icon or permissions) → a fresh eas build and a new store submission.

For a team iterating on an AI-built app, this is the difference between shipping a typo fix in two minutes versus two days. It also means your first submission doesn't have to be perfect — it has to be good, and then you tighten it from there.

People Also Ask

Do I need a Mac to publish a React Native app to the App Store?

No. EAS Build compiles and signs your iOS app on Expo's cloud servers, so you can publish an iPhone app from Windows or Linux. A Mac is only needed if you choose to build locally with Xcode. The eas build and eas submit commands run from any operating system.

How long does App Store review take in 2026?

Apple's App Store review typically takes 24–48 hours, though many apps clear in under a day. Google Play review is usually faster, often a few hours. First-time submissions and apps using sensitive permissions can take longer, so build a buffer into your launch date.

Can you publish an AI-generated app to the App Store?

Yes. App stores review the app, not how it was written. As long as the output is real, standards-compliant React Native code — which is what RapidNative exports — it builds and submits exactly like a hand-coded app. The store cares about functionality, content, and privacy compliance, not the authoring tool.

What's the difference between EAS Build and EAS Submit?

EAS Build compiles your React Native code into a native binary (.ipa for iOS, .aab for Android) and handles code signing. EAS Submit takes that finished binary and uploads it to App Store Connect or the Google Play Console for review. You build first, then submit.

From Prompt to Published

The distance from "an AI wrote my app" to "it's on the App Store" is shorter than it feels — it's four real commands and a handful of accounts. Start with a project you can genuinely export, set up your Apple and Google accounts, run eas build, run eas submit, and use eas update to iterate after launch.

The piece that trips people up isn't any single step — it's starting from code that isn't actually exportable. That's the quiet advantage of building on a tool that generates real React Native and Expo projects: when you're ready to publish your React Native app to the App Store, there's nothing to untangle. The export is already a buildable project.

Ready to build the app you'll be publishing? Start building with RapidNative — describe your idea in plain English, watch it run on your phone, and export production-ready code when it's time to ship. Or browse more guides on the RapidNative blog to plan the rest of your launch.