# React Native App Store Submission Checklist: iOS and Android > Complete checklist for submitting a React Native app to the Apple App Store and Google Play — signing, metadata, permissions, and common rejections. - **Published:** 2025-05-05 - **Author:** Clixo - **Reading time:** 5 min read - **Tags:** react-native, app-store, google-play, deployment, mobile - **Canonical URL:** https://clixo.sh/blog/react-native-app-store-submission-checklist First-time app store submissions almost always hit at least one avoidable rejection. The review queues are not fast — Apple's typical review time is 24-48 hours, and a rejected build means starting that wait over. Getting the submission right the first time is worth the upfront preparation time. This checklist covers both the Apple App Store and Google Play. Work through it before you submit. ```mermaid flowchart LR A["Prepare release binary"] --> B["iOS signing and credentials"] A --> C["Android keystore and AAB"] B --> D["App Store Connect listing"] C --> E["Google Play Console listing"] D --> F["Submit to Apple review"] E --> G["Submit to Google review"] F --> H["Monitor crash rates post-launch"] G --> H ``` ## 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. - Respond to any reviewer questions within 24 hours to avoid your review being deprioritized. App store submission is a well-defined process once you have done it a few times. If you are shipping your first React Native app and want experienced engineers to handle the build pipeline, signing setup, and submission process alongside your team, [talk to Clixo](https://clixo.sh/#contact). --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)