Take a React Native app to production: architecture, offline data, secure auth, testing, performance, accessibility and store releases.

Mobile App Production

Set `version`, `ios.buildNumber` and `android.versionCode` in `app.json`, plus a final name, icon and splash screen.

Write a store listing draft in a text file: app name, a one-line subtitle, a short and a full description, and five keywords.

Take screenshots of your three most important screens on a phone or simulator; make sure they show the real app.

List every kind of data your app and its libraries collect (sign-in, analytics, crash reports, location) and draft your App Privacy / Data safety answers and a simple privacy policy.

Check the review basics: an in-app account deletion path if you have accounts, a demo login for reviewers, clear permission descriptions, no placeholder screens.

Optional, with an account: run `eas build --profile production`, then `eas submit`, and release to TestFlight or the Play internal testing track before any public release.

Write a rollout plan: staged or phased release, what you will watch (crash rate, reviews), and how you would roll back.

## Why it matters

An app is not shipped until people can install it from the App Store or Google Play. Store submission is part engineering, part paperwork: signing, version numbers, screenshots, privacy declarations and policy review. First-time submissions are often rejected for avoidable reasons, which can cost days. Knowing the process lets you plan a release instead of being surprised by it.

## Accounts and costs

- **Apple Developer Program:** $99 per year (individual or organization). Needed for TestFlight and the App Store. Organizations need a D-U-N-S number.
- **Google Play Console:** a one-off $25 registration fee. Google verifies your identity, and new personal accounts must run a closed test with a minimum number of testers for a minimum period before they can publish to production (the current rule has been 12 testers for 14 days; check Play Console Help for today's requirement).

Checked on 2026-10-23. Fees and rules change, so confirm on developer.apple.com and the Play Console Help Center before you pay or plan dates. Fee waivers exist for some non-profits, education and government organizations on Apple's program.

## What each store needs

| | App Store (App Store Connect) | Google Play (Play Console) |
|---|---|---|
| Build format | Signed `.ipa` | Signed Android App Bundle (`.aab`) |
| Testing track | TestFlight (internal and external testers) | Internal, closed and open testing tracks |
| Privacy | "App Privacy" details (nutrition label) and a privacy policy URL | Data safety form and a privacy policy URL |
| Listing | Name, subtitle, description, keywords, screenshots per device size, icon, age rating | Title, short and full description, screenshots, feature graphic, icon, content rating questionnaire |
| Review | Human and automated review against the App Review Guidelines | Automated and human review against Play policies |
| Technical rules | Built with a recent Xcode / SDK | Target a recent Android API level |

Both stores require a way to **delete an account** from inside the app if the app lets users create one, and a demo account for reviewers if features are behind a login.

## Versions and signing

Every upload needs a higher build number than the last:

```json
{
  "expo": {
    "version": "1.2.0",
    "ios": { "buildNumber": "14" },
    "android": { "versionCode": 14 }
  }
}
```

`version` is what users see; `buildNumber` / `versionCode` must increase on every upload. With EAS you can set `"autoIncrement": true` in the production profile of `eas.json` and let the build service manage it.

Signing proves the build came from you. EAS can create and store the iOS certificates and provisioning profiles and the Android upload keystore for you. **Back up the Android keystore credentials** (`eas credentials`): Google Play App Signing protects the final app signing key, but losing the upload key still means a support process to reset it.

## Worked example: from build to review with EAS

```bash
eas build --platform all --profile production      # store-ready .ipa and .aab
eas submit --platform ios                           # uploads to App Store Connect
eas submit --platform android                       # uploads to Play Console
```

Then:

1. **Test first.** On iOS the build appears in TestFlight; add yourself and a few testers. On Android, release to the internal testing track and install from the Play Store link.
2. **Fill in the listing:** description, screenshots (real app screens, no misleading images), support URL, privacy policy.
3. **Declare data use honestly:** analytics, crash reporting and sign-in all collect data. The App Privacy and Data safety answers must match what your app and its SDKs actually do.
4. **Give reviewers what they need:** a demo account, notes explaining any non-obvious features, and contact details.
5. **Submit for review.** Choose manual or automatic release after approval, and consider a **staged rollout** (Play) or **phased release** (App Store) so a problem only reaches a small share of users first.

## Common rejection reasons

- Crashes or broken features during review (test the exact build you submit).
- Missing or vague permission usage descriptions.
- Login required with no demo account provided.
- Privacy declarations that do not match the app's behaviour or its SDKs.
- Placeholder content, "beta" labels or links to unfinished features.
- Payments for digital goods outside the store's in-app purchase system where the rules require it (the rules differ by region and change; read the current guidelines).

## Quick recap

- Accounts: Apple $99/yr, Google $25 one-off (checked on 2026-10-23); confirm on the official sites.
- Increase the build number every upload; let EAS manage signing and back up credentials.
- Test through TestFlight and Play testing tracks, fill in privacy declarations honestly, give reviewers a demo account.
- Roll out in stages so problems reach few users.

## Try it

The Do tab is a release checklist you can work through for your own app, with or without paid accounts.


Prepare signing, versions, listings and privacy declarations, and get through store review.

App store submission

How to Publish Your App to the App Store (Step by Step, 2026)

How to Publish Your App to the Play Store (Step by Step, 2026)

Create a free Sentry account (or a free Firebase project for Crashlytics) and a React Native project to get a DSN.

Run `npx expo install @sentry/react-native`, add its config plugin to `app.json`, and call `Sentry.init` with your DSN and `sendDefaultPii: false`.

Add a hidden test button that throws an error, build a development or preview build (Sentry's native crash handling is not available inside Expo Go), trigger the error, and find it in the dashboard.

Check what the report contains (device, OS, release, breadcrumbs) and confirm it holds no personal data.

Optional: run `npx expo install expo-updates` and `eas update:configure`, install a preview build on your phone, change some text, and run `eas update --channel preview --message "Text fix"`. Restart the app twice to see the update.

Write down which changes you could ship by OTA and which would need a new store build.

Clean up: remove the test button, and delete any Sentry or Firebase project you will not keep using.

## Why it matters

Once real people use your app, two questions matter every day: "Is it crashing for anyone?" and "How fast can we ship a fix?" Crash reporting answers the first. A repeatable build pipeline and over-the-air (OTA) updates answer the second. Together they turn releases from stressful events into routine work.

## Build profiles

With EAS, `eas.json` defines build profiles, usually three:

```json
{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal", "channel": "preview" },
    "production": { "autoIncrement": true, "channel": "production" }
  }
}
```

- **development:** your own dev client for daily work.
- **preview:** an internal build that testers install, pointed at a staging API.
- **production:** the store build.

Use environment variables (EAS environment variables or `app.config.js`) for per-profile settings such as the API URL. Never put secrets in them if they end up in the JavaScript bundle; anything the app ships is readable.

You can trigger builds from CI (GitHub Actions or EAS Workflows) on every merge to the main branch, so every build is reproducible and nobody ships from a laptop with uncommitted changes. The free EAS plan has a limited number of builds per month; check expo.dev/pricing (checked on 2026-10-23).

## Over-the-air updates

A React Native app has two parts: **native code** (compiled into the binary) and the **JavaScript bundle plus assets**. EAS Update lets you publish a new JavaScript bundle that installed apps download on their next launch, without a store review:

```bash
npx expo install expo-updates
eas update:configure
eas update --channel production --message "Fix crash on empty cart"
```

Rules that keep OTA safe:

- **JavaScript and assets only.** Changing native code (adding a native library, changing permissions or the SDK version) needs a new store build.
- **Runtime version.** Each build has a `runtimeVersion`; an update is only delivered to builds with a matching one, so a JavaScript bundle never lands on a binary that lacks the native code it needs. The `"policy": "fingerprint"` setting derives it from your native code automatically.
- **Store policies.** Both stores allow interpreted code updates for bug fixes and small improvements, but not changes to the app's core purpose that bypass review. Use OTA for fixes, not to ship a different app.
- **Roll out gradually** (EAS Update supports percentage rollouts) and keep the ability to roll back to the previous update.

## Crash reporting

Users rarely report crashes; they just leave. A crash reporter catches errors on the device and sends them to a dashboard with the stack trace, device model, OS version, app version and the steps (breadcrumbs) leading up to the crash. Popular choices are **Sentry** (`@sentry/react-native`, with an Expo config plugin) and **Firebase Crashlytics**. Both have free tiers suitable for learning (checked on 2026-10-23).

```javascript
import * as Sentry from "@sentry/react-native";

Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,   // a DSN is not a secret, but keep it configurable
  environment: __DEV__ ? "development" : "production",
  sendDefaultPii: false,                      // do not send personal data by default
});

export default Sentry.wrap(App);
```

Two production details matter:

- **Source maps.** Production JavaScript is minified, so stack traces look like `a.b is not a function at 1:20934`. Uploading source maps for each build and update turns them back into your file names and line numbers. The Sentry Expo integration can do this during EAS builds and updates.
- **Privacy.** Do not attach tokens, emails or form contents to error reports. Declare crash data in the store privacy forms.

## Worked example: a fix in under an hour

1. 10:02: crash alerts show `TypeError: Cannot read properties of undefined (reading 'total')` in `CartSummary`, 3% of sessions, version 1.4.0, only for users with empty carts.
2. 10:10: the source-mapped stack trace points to `cart.items[0].total`. You add a guard and a unit test for the empty cart.
3. 10:25: CI passes. You publish `eas update --channel production` to 10% of users.
4. 10:45: the crash rate for the new update is zero; you roll out to 100%.
5. Later: the native build is unchanged, so no store review was needed.

## Common mistakes

- OTA updates that require native code the installed build does not have (use runtime versions).
- No source maps, so crash reports are unreadable.
- Sending personal data in crash reports or logs.
- Builds made by hand on one laptop, so nobody can reproduce them.
- No staged rollout, so a bad update reaches everyone.

## Quick recap

- Define development, preview and production build profiles; build from CI.
- EAS Update ships JavaScript and asset fixes over the air, matched by runtime version, rolled out gradually.
- Crash reporting with uploaded source maps tells you what broke, where and for whom, without collecting personal data.

## Try it

The Do tab has you add crash reporting to your app on a free tier, trigger a test error and, if you want, publish an OTA update.


Set up build profiles, crash reporting with source maps and safe over-the-air updates.

Builds, updates, and crash reporting

When to use over the air updates | Three important OTA use cases

Monitoring Critical User Experiences In React Native Mobile Apps

## Why it matters

React Native and Expo cover most of what apps need, but sooner or later a project hits something they do not: a vendor's payment terminal SDK that only ships for Swift and Kotlin, a brand-new OS feature, a performance-critical image filter. Mid-level mobile developers are expected to recognise when that point arrives and to know how JavaScript and native code meet, even if a native specialist writes the Swift or Kotlin.

## How JavaScript talks to native code

In React Native's **New Architecture** (the default since React Native 0.76):

- **JSI** (JavaScript Interface) lets JavaScript call C++ objects directly and synchronously, instead of sending serialized messages over the old asynchronous bridge.
- **Turbo Modules** are native modules (functions) exposed through JSI and loaded lazily, when first used.
- **Fabric** is the renderer that turns React's component tree into native views; custom native **components** (views) plug into it.
- **Codegen** reads a typed JavaScript/TypeScript spec of your module and generates the native glue code, so both sides agree on the types.

In Expo projects the usual tool is the **Expo Modules API**, which lets you write a module in Swift and Kotlin with a small, declarative syntax:

```swift
// ios/BatteryModule.swift
import ExpoModulesCore

public class BatteryModule: Module {
  public func definition() -> ModuleDefinition {
    Name("Battery")
    Function("level") { () -> Float in
      UIDevice.current.isBatteryMonitoringEnabled = true
      return UIDevice.current.batteryLevel
    }
  }
}
```

```kotlin
// android/.../BatteryModule.kt
class BatteryModule : Module() {
  override fun definition() = ModuleDefinition {
    Name("Battery")
    Function("level") {
      val bm = appContext.reactContext?.getSystemService(Context.BATTERY_SERVICE) as BatteryManager
      bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY) / 100f
    }
  }
}
```

```javascript
// JavaScript
import { requireNativeModule } from "expo-modules-core";
const Battery = requireNativeModule("Battery");
console.log(Battery.level());   // 0.82
```

The same name and function exist on both platforms, and JavaScript calls one API. (Expo already ships `expo-battery`; this is only to show the shape.) Because the module contains native code, it needs a **development build**; it cannot run in Expo Go. **Config plugins** let a module change native project settings (Info.plist entries, Android manifest permissions) automatically during the build.

## When to go native

Reach for native code when:

- **A required SDK is native-only** and no maintained React Native wrapper exists.
- **You need a new platform feature** (widgets, Live Activities, App Clips, watch apps, CarPlay) that has no library yet. Many of these are separate native targets anyway.
- **Measured performance** is not good enough after JavaScript-side fixes: heavy image or audio processing, real-time graphics, large on-device computation.
- **Deep OS integration**: background services, Bluetooth peripherals with strict timing, custom keyboards.

Stay in JavaScript when a well-maintained library already does it (check its downloads, recent releases and New Architecture support), or when the "slowness" has not been measured. Every native module adds two languages to maintain, two sets of platform tests and upgrade work with each React Native release.

At the far end, some teams write whole screens or the whole app natively (Swift with SwiftUI, Kotlin with Jetpack Compose). That is a product decision about team skills and long-term cost, not just a technical one. **Brownfield** apps go the other way: an existing native app adds React Native for some screens.

## Worked example: a decision

A delivery app must print receipts on a Bluetooth printer whose vendor ships only an iOS framework and an Android AAR.

1. Search for an existing React Native wrapper: one exists but has had no release in three years and does not support the New Architecture. Not a safe dependency.
2. Decide: write a small Expo module with two functions, `connect(address)` and `printReceipt(lines)`, wrapping the vendor SDKs, with a config plugin that adds the Bluetooth permission strings.
3. Keep the module thin: formatting the receipt stays in JavaScript (tested with Jest); native code only talks to the printer.
4. Plan for maintenance: a native engineer reviews the Swift and Kotlin, and the module gets its own tests on each platform.

## Common mistakes

- Going native for performance before profiling.
- Large native modules full of business logic that is hard to share and test; keep logic in JavaScript and native code thin.
- Abandoned community libraries without New Architecture support.
- Forgetting that native changes need a new store build and a new runtime version for OTA updates.
- Implementing a feature on one platform only and leaving the other to crash.

## Quick recap

- The New Architecture connects JavaScript and native code through JSI, Turbo Modules, Fabric and Codegen.
- In Expo, the Expo Modules API and config plugins are the standard way to add native code; it requires a development build.
- Go native for native-only SDKs, new platform features, measured performance needs and deep OS integration; otherwise prefer maintained libraries.

## Try it

Take the quiz in the Do tab. If you have time, list the native features your dream app would need and check whether a maintained library covers each one.


Explain how JavaScript and native code connect and decide when a native module is worth it.

When to go native

How to create a native module with the Expo modules API

The New React Native Architecture

Store submission, builds, over-the-air updates, crash reporting and when to go native.