The React Native App Store Submission Checklist: 13 Gotchas That Trip Up First-Timers

Before submitting a React Native or Expo app, check its store settings, assets, privacy declarations and release build. These checks do not guarantee approval or a particular review time.

App store submission checklist

1. Privacy policy. Provide a public privacy policy URL and make the policy accessible inside the app. Describe the app’s actual data practices, including relevant third-party services. Check that the page opens without signing in.

2. Screenshots. Use the required device categories and accepted dimensions shown in App Store Connect. Apple supports scaling between some sizes; separate 6.9-inch and 6.5-inch sets are not universally required. Include iPad screenshots if the app supports iPad. Capture the app version being submitted.

3. App icon. Check the icon format required by the app’s build toolchain. For a conventional Expo PNG icon, use a square 1024 × 1024 image without transparency for iOS. Inspect the icon in the built app and store listing.

4. Login options. If third-party login authenticates the primary account, check Apple’s equivalent-login requirements and exceptions. Sign in with Apple is one option for meeting them; it is not mandatory in every app with third-party login.

5. Payments. Apple generally requires in-app purchase for digital features, subject to exceptions. US storefront apps may include external purchase links under Apple’s rules. Other storefronts have different restrictions or entitlement requirements. Google Play also has billing requirements, exceptions and regional programs. Check the app’s storefronts and what it sells before choosing a payment flow. Physical goods and services have different rules from digital purchases.

6. Encryption declaration. Answer App Store Connect’s export-compliance questions for the encryption the app and its dependencies actually use. Set ITSAppUsesNonExemptEncryption to false only when that declaration is accurate. Do not copy the setting without checking the app’s encryption use.

7. Privacy manifest. Check required-reason API use in the app and its native dependencies. Include the appropriate PrivacyInfo.xcprivacy declarations and approved reasons. Expo supports privacy manifest configuration through ios.privacyManifests. A manifest does not replace store privacy disclosures.

8. Permission messages. Add purpose strings for protected resources the app accesses, such as the camera, microphone or location. Explain why the feature needs access. Check dependencies too, and test both permission approval and denial on a phone.

9. Data Safety and App Privacy. Complete the store disclosures for the app’s actual collection, sharing and handling of data. Include relevant SDK behavior. Keep these answers consistent with the app and privacy policy; a privacy policy alone does not complete the store forms.

10. Age and content ratings. Complete each store’s questionnaire accurately, including applicable user-generated content, messaging and other features. Update the answers when the app’s content or capabilities change.

11. Listing accuracy. Check the description, screenshots and purchase information against the submitted build. Remove claims about features that are not available in that version.

12. Build identifiers. Give each new uploaded build the required build identifier. In Expo, the fields are ios.buildNumber and android.versionCode. EAS can manage them with remote versioning and autoIncrement. Resubmitting the same uploaded build is different from uploading a new binary.

13. Review access. If sign-in is required, provide working review access and clear instructions through the store’s review-information fields. Keep the backend available and explain any special setup needed to reach the features under review.

Before submitting

• Install and test the release build on the intended devices.
• Check sign-in, saved data, permissions and purchases where applicable.
• Confirm the selected build matches the store listing.
• Complete the required store forms and review-access details.

Uploading a build, submitting it for review and releasing it are separate steps. Review can identify functional, policy or metadata issues. Approval and timing remain with Apple and Google.