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

If you've been working through a react native app store submission checklist and feeling like most of them were written for an agency shipping its tenth app, not a solo founder shipping their first, that's because they were. The landscape has shifted. More people than ever are generating or prototyping React Native and Expo apps with AI tools, vibe-coding their way to a functional codebase in days instead of months, and then hitting a wall at the submission gate. The wall isn't the code. It's the dozen or so compliance, configuration, and metadata requirements that nobody tells you about until a reviewer sends the rejection email.

This post is a practical walkthrough of the specific gotchas that trip up first-timers coming from an AI-builder or rapid-prototyping workflow. It assumes the app works. It focuses entirely on what still needs to happen before the binary lands in App Store Connect or Google Play Console.

---

Why First-Time Submissions Fail More Often Than They Should

Submitting an app should be the final stretch, but many teams run into frustrating rejections. Review teams look for more than just a functional app, they dig deep into details like app behavior, visuals, privacy policies, and the accuracy of listing content. For developers who have moved fast with AI scaffolding, the code is often solid. The problems are almost always in the surrounding layer: missing metadata, misconfigured builds, undeclared permissions, or overlooked policies that Apple and Google treat as hard blockers.

Apple is increasingly strict about privacy labels and data collection transparency. If an app uses analytics, tracks location, or accesses the clipboard, and the privacy label doesn't declare it, the submission gets rejected. One reported case involved an app being rejected because a third-party SDK (a crash reporting tool) was collecting device identifiers that hadn't been declared in the privacy label. This is the pattern: not the code you wrote, but the SDKs that came along for the ride, whether added manually or pulled in by an AI-generated scaffold.

A rejection usually comes with vague notes, which makes it hard to know what to fix. These delays can push back important launches and force rushed decisions. Going through the checklist below before first submission is what prevents that situation entirely.

The first rejection is almost never about the app's functionality. It's about the paperwork layer that surrounds it.

---

The 13 Specific Gotchas to Resolve Before Submitting

1. Missing Privacy Policy URL. A privacy policy URL is required for most store listings. Apple will block submission entirely without one in App Store Connect. The URL must resolve to a live, readable page. A GitHub Gist or a simple hosted page on Notion is fine; a 404 is not. If the app collects any user data at all, including just an email address for auth, make this a real document.

2. Wrong Screenshot Dimensions. Missing screenshots for required devices will block submission at the App Store. Apple requires screenshots at specific sizes: currently 6.9-inch (iPhone 16 Pro Max) and 6.5-inch (iPhone 14 Plus or 13 Pro Max) are required for iOS. If the submission is missing either, App Store Connect rejects it before a human reviewer ever sees the app. Use Xcode Simulator or fastlane snapshot to generate the right dimensions.

3. App Icon Alpha Channel on iOS. iOS requires that the app icon have no alpha channel (transparency). If the icon was exported from a design tool or generated with a transparent background, the build pipeline may produce a binary that Apple's automated checks reject outright. The fix: flatten the icon to a solid background before exporting. For Expo projects, the icon field in app.json should point to a 1024x1024 PNG with no transparency.

4. Sign in with Apple is Mandatory When Using Third-Party Auth. This is one of the most consistently surprising rejections for first-timers. App Store Review Guideline 4.8 states that if an app offers any third-party sign-in option (Google, Facebook, Twitter, etc.), it must also offer Sign in with Apple. The requirement applies to apps where account creation is the primary mechanism. expo-apple-authentication is the standard library for React Native/Expo. If the app was scaffolded with only Google OAuth, add Sign in with Apple before submitting to iOS.

5. In-App Purchase Bypass. If the app offers any digital goods or premium features, those must be purchased through Apple's or Google's in-app purchase system. No external payment links, web checkouts, or links to a website. Apple Guideline 3.1.1 is explicit. Sending users to a Stripe-hosted page to upgrade is a fast path to rejection. Use react-native-purchases (RevenueCat) or expo-in-app-purchases. Google Play has the same requirement under its Payments Policy.

6. Export Compliance Declaration. After uploading a build, App Store Connect shows a prompt asking whether the app uses encryption. Almost every app qualifies for the standard exemption because HTTPS counts as encryption and most apps use it. The fix is adding a single key to ios.infoPlist in app.json:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "ITSAppUsesNonExemptEncryption": false
      }
    }
  }
}

This tells App Store Connect the app only uses standard OS-level HTTPS/TLS, which is exempt from export compliance documentation. Set this once and the prompt never appears again on future builds.

7. Privacy Manifest Missing or Incomplete (iOS 17+). Mandatory since May 2024, Apple requires a PrivacyInfo.xcprivacy file for apps that access certain protected APIs: UserDefaults, file timestamps, system boot time, disk space, and the active keyboard. Expo SDK 50+ includes this automatically for the Expo runtime itself, but third-party native modules (crash reporters, analytics SDKs, ad networks) may each require their own entries. A known 2025 issue: Apple doesn't always correctly parse privacy manifests from static CocoaPods dependencies, so entries from third-party SDKs may need to be duplicated into the app-level manifest to avoid silent parsing failures during review.

8. Missing Usage Description Strings. Every permission the app requests on iOS requires a corresponding usage description string in Info.plist: NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, NSMicrophoneUsageDescription, NSPhotoLibraryUsageDescription, and so on. Apple's error code ITMS-90683 fires before a human reviewer sees the app if any string is missing or generic. A string like "Required for app functionality" will get rejected. The description must explain the specific benefit to the user: "Used to capture training check-ins during workouts" passes; "Camera access required" does not. Third-party SDKs can trigger this too, even when the app code doesn't directly call the API.

9. Google Play Data Safety Section Incomplete. Google Play requires all apps to complete the Data Safety section in the Play Console, declaring what data the app collects, how it's used, and whether it's shared with third parties. This is separate from the privacy policy and must be filled in manually. Firebase Analytics, Crashlytics, AdMob, and similar SDKs all have data collection implications that must appear in this form. Google blocked over 255,000 apps in 2025 for inaccurate data safety declarations, and repeated violations have resulted in account terminations, not just submission rejections.

10. Content Rating Questionnaire Not Completed. Both stores require a content rating questionnaire before the listing can go live. For Google Play, this is the IARC questionnaire in the Play Console. For Apple, it's in the App Information section of App Store Connect. Apple overhauled the rating system in late 2025, adding 13+ and 16+ tiers. Apps with user-generated content, in-app chat, or social features almost always get a higher rating than expected. Set the content rating to reflect the potential for that content, not just the default content the app ships with at launch.

11. Metadata and Screenshots Don't Match the App. App store reviewers compare the description and screenshots against the actual binary under Apple Guideline 2.3. A description mentioning features not present in the submitted build, or screenshots showing a different UI than what's in the binary, results in a metadata accuracy rejection. This is common when marketing copy evolves independently of the codebase during a fast development sprint. Review screenshots and the app description against the production build immediately before submitting.

12. Build Version Not Incremented. Both platforms reject a build with the same version identifier as a previously submitted build. On iOS, ios.buildNumber in app.json must increment on every submission, including TestFlight builds. On Android, android.versionCode must also increment. EAS Build can manage this automatically: add "autoIncrement": true to the production build profile in eas.json, and set "appVersionSource": "remote" in the cli section so EAS tracks versions server-side. Forgetting to increment this on a last-minute resubmission is a reliable way to lose an hour at the worst possible time.

13. No Test Account in Review Notes. If the app requires login to access any core features, App Store Connect's review notes must include working credentials for a test account. A submission without credentials gets an "Unable to review" rejection because the reviewer cannot access the app. The account must work on a fresh install, with pre-verified credentials (no email confirmation step), and must have access to all features being reviewed including any in-app purchase tiers. Include email and password directly in the App Review Information section of App Store Connect, and verify the credentials work before hitting submit.

---

Wrapping Up

Most app store rejections are avoidable, and most happen in the compliance layer rather than the code itself. Three points to keep in mind:

• Items 1 through 7 are binary blockers. Privacy policy URL, screenshot dimensions, icon transparency, Sign in with Apple, IAP routing, export compliance, and privacy manifest. Miss one and the reviewer never gets to see the app work. Resolve these before cutting the production build.
• Items 8 through 13 are accuracy and completeness checks. Permissions, data safety, content rating, metadata match, version increments, and test accounts. Each is straightforward but easy to skip during a fast sprint toward launch.
• The review process is predictable. Both Apple and Google publish their full guidelines, and every rejection references a specific guideline number. Fix the cited issue and resubmit. Most apps get through in one or two rounds.