From MVP to Production: A React Native Checklist

#reactnative #mobile #checklist #devops

You've built the features. The app works on your machine. Now what?

The gap between "it works on my machine" and "it's live in the store and we can maintain it" is where a lot of projects get stuck—or ship anyway and pay for it later with broken builds, wrong environments, and "why is staging hitting production?" incidents. After shipping multiple React Native apps to the stores (including large-scale event apps), I've learned that a small set of habits and checks makes that transition predictable instead of painful.

This post is the checklist I use for every new app and the one I recommend when joining a project that's about to go to production. It's not exhaustive—you'll add items for your stack and compliance needs—but it's the baseline that keeps builds, environments, and releases under control. Use it as a starting point and tighten each area as the product and team grow.

Environment & Config

Getting environment and build variants right early avoids the classic mistakes: hardcoded API URLs, staging builds accidentally talking to production, and "it worked in debug but not in release." Spend a little time here and the rest of the pipeline stays sane.

[ ] Environment variables — Use react-native-config or Expo's env scheme so API URLs, feature flags, and keys live outside the codebase. Never hardcode them. Have separate configs for dev, staging, and prod so each build talks to the right backend and you can change URLs without a new app release.
[ ] Build variants — Android: product flavors. iOS: schemes + configurations. Ensure each variant points to the right API and config (see below).
[ ] Versioning — Bump versionCode (Android) and CFBundleShortVersionString / CFBundleVersion (iOS) for every release. Store submissions reject duplicate version numbers, and users (and crash reports) need to know which build they're on. Consider automating bumps in CI so you never ship the same version twice.

Product flavors (Android) and schemes (iOS) — Dev, Staging, Production

Use separate build variants so you can install dev, staging, and production on the same device and keep API/env configs isolated.

Android — Product flavors

In android/app/build.gradle, define flavors and wire them to env (e.g. react-native-config or BuildConfig):

android {
    flavorDimensions += "environment"
    productFlavors {
        dev {
            dimension = "environment"
            applicationIdSuffix = ".dev"
            versionNameSuffix = "-dev"
            resValue "string", "app_name", "MyApp Dev"
            buildConfigField "String", "API_BASE_URL", "\"https://api-dev.example.com\""
        }
        staging {
            dimension = "environment"
            applicationIdSuffix = ".staging"
            versionNameSuffix = "-staging"
            resValue "string", "app_name", "MyApp Staging"
            buildConfigField "String", "API_BASE_URL", "\"https://api-staging.example.com\""
        }
        production {
            dimension = "environment"
            resValue "string", "app_name", "MyApp"
            buildConfigField "String", "API_BASE_URL", "\"https://api.example.com\""
        }
    }
}

dev — .dev suffix so it installs alongside staging/prod. Use dev API and debug-friendly app name.
staging — .staging suffix, staging API. Use for QA and pre-release testing.
production — No suffix; this is the store build. Production API only.

Build with: npx react-native run-android --variant=devDebug (or stagingRelease, productionRelease, etc.).

iOS — Schemes and configurations

Configurations — In Xcode, duplicate Debug and Release (e.g. Debug-Dev, Release-Staging, Release-Production) or use xcconfig files that set API_BASE_URL and other env per configuration.
Schemes — Create schemes Dev, Staging, Production. In each scheme, set the Run and Archive actions to use the right configuration (e.g. Dev → Debug-Dev; Staging → Release-Staging; Production → Release).
Bundle ID suffix — In the project’s Build Settings (or per configuration), set Product Bundle Identifier so dev/staging have a suffix (e.g. com.yourapp.dev, com.yourapp.staging). That lets you install dev, staging, and production side by side.
Display name — Set Display Name per configuration (e.g. “MyApp Dev”, “MyApp Staging”) so you can tell them apart on the home screen.

Run with: Product → Scheme → Dev (or Staging/Production), then Run or Archive.

Expo

If you use EAS and app.config.js, use environment (or APP_ENV) and different extra / env in eas.json profiles (e.g. development, preview, production) so each build gets the correct API URL and app name. You can still use dev-client builds for dev/staging and production builds for the store.

Testing (Minimum Viable)

You don't need 100% coverage on day one—but you do need a safety net for the paths that matter. The goal here is to catch regressions before they reach users and to validate the build you're actually going to submit, not just the debug one.

[ ] Critical flows — At least one E2E or integration test for login/signup and the main user journey. Detox or Maestro can run in CI.
[ ] No obvious regressions — Manual test on at least one physical device per platform before release.
[ ] Release build — Test the exact build you’ll submit (not just debug). ProGuard/minification can hide bugs.

CI/CD

Store builds should come from a repeatable pipeline, not from someone's laptop. That means builds run in the cloud, signing is managed in one place, and submission to TestFlight or Play is a step in the pipeline—not a manual upload after "it built on my machine."

[ ] Builds in the cloud — Use EAS Build, Bitrise, GitHub Actions, or similar so every build runs in the same environment. No "it works on my machine" for store builds; if the pipeline passes, the build is reproducible and auditable.
[ ] Signing — Android: keystore stored securely (e.g. in CI secrets or a secrets manager), never in the repo. iOS: certificates and provisioning managed in Apple Developer and wired through EAS or Fastlane so the build step doesn't depend on a single Mac or keychain.
[ ] Automated submit — After a successful build, automatically submit to TestFlight and Play Internal Testing (e.g. via Fastlane or EAS Submit). Optionally, trigger production submission on a specific tag or branch so releases are traceable and consistent.

Store & Compliance

Stores and regulators care about privacy, permissions, and clear communication. Getting this right up front avoids rejections and builds trust with users.

[ ] Privacy — Provide a privacy policy URL and accurate data collection disclosure in App Store Connect and Play Console. If you use analytics, crash reporting, or third-party SDKs that collect data, say so. Vague or missing disclosures can lead to rejection or legal risk.
[ ] Permissions — Request only the permissions you actually need, and explain why in permission rationale strings (Android) and Info.plist usage descriptions (iOS). Users are more likely to grant access when they understand the reason; stores may reject apps that ask for broad permissions without justification.
[ ] Store assets — Screenshots, description, and keywords affect discoverability and conversion. Invest in clear copy and representative screenshots. If you care about install rates, consider A/B testing store assets (where the platform allows) to see what resonates.

Observability

Once the app is live, you need to know when it breaks and how it behaves. Without crash reporting and some visibility into usage, you're flying blind—and users will tell you about bugs before your metrics do.

[ ] Crash reporting — Integrate Firebase Crashlytics, Sentry, or similar so every crash generates a report with stack trace and device info. Crashes should create issues (or alerts), not go unnoticed. Triage and fix high-impact crashes before they accumulate bad reviews.
[ ] Analytics — Track key events that matter for product decisions: signup, purchase, core actions. Don’t over-instrument; focus on events you'll actually use to understand funnels and behavior. Too many events add noise and can complicate privacy compliance.
[ ] Performance — Monitor startup time and key screens (e.g. time to interactive, list scroll performance). Set a baseline and fix big regressions before they hit production. Slow apps get uninstalled; catching regressions in staging or beta keeps production healthy.

Documentation

Good docs reduce "how do I run this?" and "how do we release?" to a few minutes instead of a day of digging. They also make it possible for someone else to own the release when you're not around.

[ ] README — Document how to install dependencies, run the app locally, and build for dev/staging/prod (including which variant or scheme to use). A new team member should be able to get the app running from the README alone, without tribal knowledge.
[ ] Runbook — Document how to cut a release: which branch or tag to use, how to trigger the CI build, and how to promote from TestFlight/Internal Testing to production. Include who to contact if the build fails or if signing/credentials need to be rotated. Keep it in the repo or in a shared wiki so it's always one link away.

This list is a starting point, not a final rulebook. Add what fits your stack, compliance (e.g. HIPAA, PCI), and team. Use it as a baseline, ship your MVP, then improve each area as you go. If something on your checklist has saved you more than once, share it in the comments or in your own post—tag it so others can find it.

Saad Mehmood — Portfolio