React Native App Launch Checklist: From Testing to Store Approval

1. What a real React Native app launch requires

A React Native app launch checklist is not a single click on "Submit for Review", it is a coordinated sequence from final regression testing through store approval to the first 48 hours in production, where things can still quietly go wrong. Teams that treat launch as a single event rather than a process are the ones caught off guard by a crash spike three hours after release, or by a store rejection two days before a marketing deadline. This article treats the app launch checklist as a structured process: testing scope, crash monitoring, performance profiling, store compliance, staged rollout, privacy declarations, a final pre-submission check, and the critical hours right after going live.

As the closing article in this series, one brief note: alongside this launch process, a genuinely launch-ready React Native app typically also has a consistent design system for UI consistency across screens, working in-app purchases or subscription commerce if the business model needs it, native home-screen widgets if the product benefits from OS-level presence, and an automated CI/CD pipeline with GitHub Actions and EAS that builds and signs releases repeatably. Each of these is its own discipline covered elsewhere. Here, the focus stays squarely on what happens between "feature complete" and "live in production, stable."

2. Functional and regression testing: the right device matrix

Simulators lie, at least about the details that matter. The iOS Simulator and Android Emulator run on desktop-class CPU and RAM with no thermal throttling, no real GPS signal, no real camera hardware, and no true push delivery through APNs or FCM. A React Native app launch checklist that was only ever run on simulators before submission has effectively skipped testing the exact conditions most users will actually run the app under. Concretely, that means at least two or three physical devices per platform, spread across high-end, mid-range and low-end tiers, before a submission for store approval is even on the table.

OS version coverage is the second building block of the device matrix. A sensible target is the last three major iOS versions and the Android API levels that make up roughly 95 percent of the active install base according to store analytics. It matters to test explicitly on the oldest still-supported OS, not only on the newest beta, because that is exactly where layout breakage and stale API behavior show up first, invisible on a simulator running the latest SDK.

Low-end Android performance testing is the most commonly skipped part of the device matrix, precisely because Android fragmentation is so wide. Budget devices with 2 to 3 GB of RAM and a weaker GPU reveal JS thread blocking, choppy list scrolling and slow image loading that would never show up on a flagship test device. An Android Go emulator profile or an actual budget device from the Samsung A-series or Redmi line belongs firmly in every React Native app launch checklist, not as an optional extra test.

3. Crash reporting and monitoring before launch

Setting up crash reporting only after launch means the first real crash data arrives through angry store reviews instead of a dashboard, and by then, fixing it quickly is barely possible. Crash monitoring is therefore not a post-launch nice-to-have, it is a fixed part of any serious app launch checklist that needs to be running in production mode by the last testing cycle before submission, not after store approval.

In practice that means an SDK like Sentry or Bugsnag integrated before the first production release, including source maps uploaded for every build. Without source maps, a crash report shows only minified JS code as a stack trace, which makes debugging effectively impossible. Breadcrumbs, meaning automatically recorded navigation events, API calls and user interactions leading up to the crash, turn a bare stack trace into a traceable story of what the user actually did right before things broke.

// sentry.ts — crash reporting setup before the first production release
import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'https://examplePublicKey@o0.ingest.sentry.io/0',
  release: `myapp@${process.env.APP_VERSION}+${process.env.BUILD_NUMBER}`,
  dist: process.env.BUILD_NUMBER,
  tracesSampleRate: 0.2,
  enableAutoSessionTracking: true,
  attachStacktrace: true,
});

// Manual breadcrumb: record the user's last relevant action
export function trackCheckoutStep(step: string) {
  Sentry.addBreadcrumb({
    category: 'checkout',
    message: `Checkout step reached: ${step}`,
    level: 'info',
  });
}

The release and dist tag in the init call is not a minor detail, it decides whether crash reports can later be filtered per version. Without that mapping, crashes from three different builds land unsorted in the same bucket, and an alert for a dropping crash-free rate cannot be cleanly tied to a specific store approval.

4. Performance profiling: startup time, JS thread FPS and bundle size

Startup time, measured as time to interactive, shapes the first impression of an app more than almost any other metric. Users staring at an empty or endlessly loading splash screen abandon or uninstall long before they ever see the actual product. An app launch checklist without a documented startup time measurement skips exactly the metric that most directly drives store ratings and abandonment rates.

For JS thread frame rate during scrolling and navigation, Flipper and the React DevTools Profiler provide the numbers that matter: if the FPS curve regularly drops below 50 during a list interaction, that is a reliable signal for expensive re-renders or blocking computation on the JS thread. Native tools like Xcode Instruments and the Android Studio Profiler round this out with the native side, such as memory usage and GPU load, which a JS-only profiler alone cannot reveal.

Bundle size is the third lever: a bloated JS bundle extends not just the download, but also the time Hermes needs to parse and execute at startup. react-native-bundle-visualizer shows, as an interactive treemap, which packages actually take up the most space in the bundle, frequently surprisingly large, barely used dependencies.

#!/usr/bin/env bash
set -euo pipefail

# Visualize what is actually bloating the production JS bundle
npx react-native-bundle-visualizer

# Generate the raw bundle and a size-only report for CI comparisons
npx react-native bundle \
  --platform android \
  --dev false \
  --entry-file index.js \
  --bundle-output /tmp/index.android.bundle \
  --sourcemap-output /tmp/index.android.bundle.map

du -h /tmp/index.android.bundle

5. App Store Review Guidelines and Play Store policies for React Native apps

Since iOS 17, Apple requires a PrivacyInfo.xcprivacy manifest for apps and for third-party SDKs that use so-called "Required Reason APIs", such as UserDefaults, disk space checks, or active keyboard detection. Many native modules used in a React Native app trigger this requirement without it being documented in the package at all, and a missing or incomplete privacy manifest declaration now leads to automatic rejections during store approval, before a human reviewer even opens the app.

{
  "NSPrivacyTracking": false,
  "NSPrivacyTrackingDomains": [],
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypeCrashData",
      "NSPrivacyCollectedDataTypeLinked": false,
      "NSPrivacyCollectedDataTypeTracking": false,
      "NSPrivacyCollectedDataTypePurposes": ["NSPrivacyCollectedDataTypePurposeAppFunctionality"]
    }
  ],
  "NSPrivacyAccessedAPITypes": [
    {
      "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
      "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
    }
  ]
}

On Android, the Play Console equivalent, the Data Safety form, demands an equally precise self-disclosure: which data types the app collects, whether they are shared, and for what purpose. An app launch checklist must reconcile this declaration against the actual code, because mismatched declarations are now actively surfaced through automated scans and user complaints, leading to suspension of existing store listings, not just rejection of new submissions.

<!-- AndroidManifest.xml — permissions must match the Data Safety form exactly -->
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

<application>
  <meta-data
    android:name="com.google.android.gms.permission.AD_ID"
    android:value="false" />
</application>

Permission usage strings such as NSCameraUsageDescription or NSLocationWhenInUseUsageDescription must concretely explain what the app actually needs the permission for. Generic wording like "This app needs access to your camera" regularly triggers review questions and delays store approval by days. Screenshots and metadata must also be produced separately per supported store locale, since auto-scaled default screenshots without localized text are increasingly flagged by reviewers, especially when the app itself is fully localized.

6. Staged rollout: limiting the blast radius of a bad release

A critical bug shipped simultaneously to 100 percent of users instantly turns a minor code error into a mass support incident. A staged rollout limits exactly that blast radius by making a new release available only to a small percentage of the user base first, before the rest follows. This strategy is the difference between "five percent of users see a bug for an hour" and "every user sees a bug until a hotfix clears the entire review process."

The Play Console offers a percentage-based rollout directly in release management, typically starting at 5 to 10 percent with stepwise increases after observation windows of a few hours. App Store Connect offers Phased Release, an automatic seven-day ramp mechanism that can be paused at any time as soon as the crash-free rate drops below the defined threshold.

#!/usr/bin/env bash
set -euo pipefail

# Bump build number and start a conservative staged rollout on Play Console
VERSION_CODE=$(date +%Y%m%d%H)
sed -i "s/versionCode .*/versionCode ${VERSION_CODE}/" android/app/build.gradle

# Upload the release and start at a low rollout percentage
bundle exec fastlane supply \
  --track production \
  --rollout 0.10 \
  --aab android/app/build/outputs/bundle/release/app-release.aab

echo "[OK] Staged rollout started at 10% for versionCode ${VERSION_CODE}"

What matters is not treating rollout as a fixed schedule, but coupling it to a monitoring gate: only once the crash-free rate of the shipped cohort stays above a defined threshold does the next percentage get released. Without that coupling, a staged rollout is just a delayed full rollout, not an actual safety mechanism.

7. App Tracking Transparency and privacy nutrition labels

App Tracking Transparency is mandatory on iOS as soon as an app tracks users across other apps or websites, for example through the IDFA for attribution or ad networks. The timing and wording of the ATT prompt heavily influence the opt-in rate: a prompt shown right at first launch with no context regularly gets lower acceptance rates than one shown after a brief explanation of the benefit. It also matters that the prompt actually appears before the first tracking call, not just before SDK initialization, since many analytics SDKs collect baseline data even before explicit tracking consent.

The privacy nutrition labels in the App Store and the Data Safety form on Google must exactly mirror what the code actually does, not what was originally planned. A common mistake in a React Native app launch checklist: an analytics SDK gets integrated during development but is never carried over into the privacy declaration, because the declaration was filled out once at the first release and never updated since. Both stores now increasingly check these declarations against the app's actual network behavior in an automated way, and a mismatch endangers not just the current store approval, but the entire existing store listing.

8. The final pre-submission checklist

Right before submission, a handful of unassuming details decide whether store approval goes smoothly or stalls on an avoidable detail. Version and build number must be bumped consistently, since both stores automatically reject duplicate build numbers, which happens most often with parallel feature branches when two builds independently end up carrying the same number. A changelog or release notes should be written before submission, not afterward under time pressure, since incomplete release notes cause review questions with some review teams on their own.

Deep links and universal links need to be tested on an actual device, not just in the simulator, because domain verification through the apple-app-site-association file and the Android App Links association require real DNS and HTTPS requests that many simulator environments resolve differently than a physical device on a mobile network. Likewise, checking push notification certificates or the FCM server key belongs in every app launch checklist: an expired APNs certificate is often only noticed once the first production push campaign silently goes nowhere.

As a final gate before submission, a target crash-free session rate should be defined, roughly 99.5 percent over the last internal or TestFlight testing phase, before submitting for public store approval at all. This number is the most objective indicator of whether a release is genuinely stable enough, regardless of how good the last manual test pass felt.

9. The first 48 hours: monitoring and rollout compared

Launch does not end with store approval, it really begins there. In the first 24 to 48 hours it becomes clear whether a release is genuinely stable, or whether a rarely hit code path only breaks under real user load. A defined crash-free rate threshold, for example an alert when it drops below 99 percent, should be actively watched during this window, ideally with a fixed on-call rotation able to respond to such an alert outside office hours too.

For the case that something is actually broken, every app launch checklist needs a rollback strategy that acts faster than another store review cycle. A remote feature flag service allows a broken feature to be switched off server-side without submitting a new build at all. For purely JavaScript-side bugs, EAS Update offers an even more direct path: a hotfix bundle can be delivered to already-installed apps within minutes, entirely bypassing App Store review, as long as no native code changes are involved.

The table shows the clear trade-off: a staged rollout costs time before full distribution, but in exchange buys exactly the reaction window that decides, in a real incident, between a controlled event and an escalated support crisis. For any app with a meaningful user base, that lost time is a cheap price against the risk of an uncontrolled full-scale outage.

10. Summary

This article series has looked at React Native app development from several angles, from a custom component library, through subscription commerce and native widgets, to a CI/CD pipeline. All of it converges on the same moment in the end: the launch. A solid React Native app launch checklist is the framework that turns a technically finished app into an actually stable, store-compliant product. It starts with a realistic device matrix that includes real low-end devices, moves through crash monitoring and performance profiling before the first production release, and does not end at submission, but at a deliberate staged rollout strategy and active monitoring during the first 48 hours.

The common thread through this checklist is control over risk: every step, from the privacy manifest declaration to a rollback through a feature flag or EAS Update, reduces the chance that a single bug escalates into an uncontrolled incident. Store approval is therefore not an endpoint, it is a checkpoint in a process that is only truly complete once crash-free rates are stable in production.

11. FAQ: React Native App Launch Checklist and Store Approval