React Native App Store Submission Checklist: iOS and Android

Prepare the release build, store metadata, permissions, and review access before submitting a React Native app. Store requirements change, so check the current Apple and Google instructions alongside this checklist.

Before You Build the Release Binary

Code and Configuration

• Remove all console.log calls from production code, or disable them conditionally. Some reviewers flag apps that write excessively to the system log.
• Confirm __DEV__ guards are in place for any development-only tooling (Flipper, Reactotron, debug menus).
• Set the correct bundle identifier (iOS) or application ID (Android). Changing these after submission requires a new app listing entry.
• Bump the version number (version in package.json and app.json) and the build number (separate from the user-facing version). Both stores require a strictly incrementing build number on every submission.
• Test the release build locally, not the debug build. Hermes is enabled by default in release builds; verify your app runs correctly with Hermes.

Permissions

• Audit every permission your app requests. Both stores flag apps that request permissions not used by the app's stated functionality.
• Add human-readable usage descriptions for every iOS permission in Info.plist (camera, microphone, location, contacts, etc.). Apple rejects builds where the description does not clearly explain why the app needs the permission.
• On Android, confirm AndroidManifest.xml only declares permissions the app actually uses. Remove leftover permissions from removed features.
• Test the permission prompt flows on a physical device with a fresh app install.

iOS-Specific Checklist

Signing and Provisioning

• Confirm you have a valid Apple Developer Program membership (99 USD/year).
• Create a distribution certificate in the Apple Developer portal if you do not have one.
• Create an App Store distribution provisioning profile for your bundle identifier.
• If using EAS Build, run eas credentials to confirm your credentials are configured for production.
• If building locally, confirm Xcode is pointing to the correct team and provisioning profile in the Signing settings.

App Store Connect Configuration

• Create the app record in App Store Connect before you try to upload a build.
• Set the primary language, category, and age rating.
• Write the app description (up to 4000 characters), keywords (100 characters maximum), and promotional text.
• Upload screenshots for every required device size: 6.7-inch iPhone (required), 12.9-inch iPad Pro (required if you support iPad).
• Add a privacy policy URL. Required for all apps that collect any user data or use any account features.
• Complete the Data Safety / Privacy Nutrition Labels section accurately. Apple cross-checks your declared data practices against your app's behavior.

App Review Information

• If your app requires login, provide a test account with credentials in the App Review Information section.
• Add any notes explaining non-obvious functionality that reviewers might flag.

Common iOS Rejection Reasons

• 2.1 App Completeness: the app crashed or had broken functionality during review. Test on a device with a clean install.
• 5.1.1 Privacy: permission usage descriptions missing or not explaining actual use.
• 4.2 Minimum Functionality: the app is too thin in functionality. Basic web wrappers are rejected.
• 3.1.1 In-App Purchase: if you sell digital goods, you must use Apple's in-app purchase system. External payment links are not allowed for digital purchases.

Android-Specific Checklist

Signing

• Create a keystore file if you do not have one. Store it securely — you cannot change the signing key for a published app.
• If using EAS Build, run eas credentials to configure Android credentials.
• Build the release APK or AAB (Android App Bundle). Google Play requires AAB for new apps.
• Verify the release build is signed: keytool -printcert -jarfile app-release.aab

Google Play Console Configuration

• Create the app in Google Play Console.
• Complete the app content form: target audience and content, ads, content ratings questionnaire.
• Complete the Data Safety section in the Store Listing. This is the Android equivalent of Apple's privacy nutrition labels — fill it out accurately.
• Add at least two screenshots for phone, and optionally for tablet.
• Write the short description (80 characters) and full description (4000 characters).
• Add a privacy policy URL.

Common Android Rejection Reasons

• Data Safety inconsistency: declared data practices do not match the app's actual behavior as detected during review.
• Deceptive permissions: requesting permissions without a clear use case visible in the app.
• Target API level: Google requires apps to target the current or previous major Android API level. Apps targeting older versions are not accepted.
• 64-bit support: all apps must include 64-bit native libraries.

After Submission

• Set up crash monitoring (Sentry, Bugsnag, or Crashlytics) before launch, not after.
• Configure your EAS Update (or CodePush) deployment channels so you can push JS fixes without a store release.
• Monitor the first 48 hours of crash rates via your crash monitoring tool and via the Google Play Android Vitals dashboard.
• Monitor review messages and respond with the information the reviewer requests.

For help preparing a React Native release and submission workflow, talk to LinkIT.