Shipping React Native Without Expo: A Release Checklist for iOS and Android

Expo makes React Native releases feel easy, and for many apps it is the right choice. But some projects outgrow the managed workflow: a native SDK without a config plugin, strict control over build settings, or a team that simply wants to own the native folders. When I moved two wallet apps from Expo to the bare React Native CLI, the code changes were the easy part. The release process was where the real work was.

This is the checklist I now use for every bare React Native release.

1. Decide the version policy once

Stores care about two numbers. On Android, versionCode must increase on every upload; on iOS, CFBundleVersion (the build number) must increase within a version. The user-facing versionName / CFBundleShortVersionString follows semantic versioning.

Keep a single source of truth — for example, package.json — and a small script that writes both native files. Never bump numbers by hand in Xcode and Gradle separately; sooner or later they drift and a store upload gets rejected.

2. Treat signing material like production secrets

• Android: generate the upload keystore once, store it in a password manager or secret store, and reference it from ~/.gradle/gradle.properties or CI secrets — never from the repository. Enroll in Play App Signing so a lost upload key is recoverable.
• iOS: use automatic signing for development, but know which distribution certificate and provisioning profile your release uses. Document who owns the Apple Developer account and how to rotate certificates before they expire.

Write this down in the project's handover notes. The person who set up signing is rarely the person doing the release a year later.

3. Separate environments explicitly

Have distinct API base URLs, app names, and bundle identifiers for staging and production (com.company.app.staging), so testers can install both side by side. Inject configuration at build time and make it impossible to ship a production build pointing to staging — fail the build if a required variable is missing.

4. Check the native details that stores reject

• Permissions: declare only what you use, and write honest usage descriptions in Info.plist (camera for QR scanning, Face ID for biometric unlock). Vague strings are a common iOS rejection.
• Android target SDK: Google Play requires a recent target API level. Update it before the deadline, not on release day.
• Privacy declarations: fill in the App Store privacy details and the Play Data safety form to match what the app really collects, including third-party SDKs.
• Account deletion: if users can create an account in the app, they must be able to delete it from the app.

5. Build like production, test like a user

Debug builds hide problems. Before every release:

• Build a release variant locally (./gradlew bundleRelease, an Xcode Archive) and install it on real devices.
• Confirm Hermes is enabled and R8/ProGuard rules keep the classes your native modules need — release-only crashes often come from stripped code.
• Run smoke flows on both platforms: install, sign in, the main transaction, background and resume, offline and back online. A tool like Maestro turns these into repeatable flows.
• Test on a small, old Android phone. If it works there, it works on most of your users' devices.

6. Security for apps that touch money

Wallet and payment apps need extra care:

• Keep secrets out of the JavaScript bundle; it is readable in every release build.
• Store keys and tokens in the Keychain or Keystore, not in AsyncStorage.
• Gate sensitive actions behind a transaction PIN, and let biometrics unlock that PIN rather than replace the server-side checks.
• Disable screenshots on sensitive screens on Android, and blur the app preview when it goes to the background.

7. Prepare the store listing before the build

Screenshots for each required device size, a short and full description, a privacy policy URL, support contact, and review notes. If the app needs an account, give reviewers a test account and clear steps. For Web3 or finance apps, explain in the notes what the app does with funds; reviewers appreciate not having to guess.

8. Roll out gradually and watch

Use Play's staged rollout and App Store phased release. Start small, watch crash reports and reviews for a day or two, then widen. Without Expo's over-the-air updates, a bad release means a new store build, so the brakes matter.

9. Write the release down

After each release, update a short release note in the repository: version, build numbers, what changed, which devices were tested, and anything unusual about signing or review. The next release starts from there instead of from memory.

The short version

1. One source of truth for version and build numbers.
2. Signing keys stored safely and documented.
3. Explicit staging and production builds.
4. Permissions, privacy forms, and target SDK checked before release day.
5. Release builds tested on real devices, old Android phones included.
6. Secrets out of the bundle, sensitive data in the Keychain or Keystore.
7. Store listing and reviewer notes ready.
8. Staged rollout, then watch.
9. Release notes written for the next person.

Going bare costs a little convenience and buys full control. With a checklist like this, it also stops costing release days.