App Store Review Guidelines: Common Rejection Reasons for React Native Apps

1. Why React Native apps often fail the same guidelines

The App Store review guidelines apply equally to every app, regardless of the framework used. Even so, React Native and Expo projects keep running into the same rejection reasons, because certain patterns show up more often in cross-platform apps than in purely native ones: UI components not properly translated into native controls, third-party SDKs overlooked in privacy declarations, or an architecture that reads to a reviewer like a plain WebView.

Anyone who treats the App Store review guidelines as a checklist run through only right before submission loses valuable time to rejections that could easily have been avoided with a bit of lead time. The following sections walk through the guidelines most relevant to React Native teams in detail and show exactly which rejection reasons sit behind them and how to prevent them.

2. Guideline 2.1: App completeness, crashes and placeholders

Guideline 2.1 App Completeness is one of the most common rejection reasons in the App Store review guidelines and applies to apps that crash on the reviewer's test devices, show placeholder content like lorem ipsum text, or contain features that are visible in the current build but not usable. For React Native apps, crashes on cold start on older iOS versions are a particularly common trigger, since many development teams test mainly on the newest devices and overlook the older test hardware reviewers actually use.

A second trigger under Guideline 2.1 is login flows without a working demo account: if an app requires sign-in, a working test account must be included in the App Review notes, since reviewers cannot or should not register themselves. If this access is missing or does not work, the app gets rejected as incomplete regardless of its otherwise quality, a rejection reason that a carefully maintained demo environment eliminates entirely.

{
  "app_review_notes": "Demo account for review: demo@example.com / Demo1234! - This account has pre-populated sample data and does not require email verification.",
  "attachment": "screen-recording-of-core-flow.mp4"
}

3. Guideline 2.3.1: Accurate metadata and screenshots

Guideline 2.3.1 requires that screenshots, description, and preview video precisely reflect what the app actually does. This rejection reason often appears in React Native apps when screenshots come from an older version or show features that only become active in a future release. The App Store review guidelines make no distinction here between intent and oversight; what matters is solely whether the presentation matches the submitted build.

This rejection reason arises unintentionally especially often in apps with feature flags or server-controlled functionality: a reviewer sees a feature in the marketing screenshots that is not (yet) enabled for their own account because the feature flag is disabled server-side. For React Native teams it is worth generating screenshots directly from the submitted build and explaining in the App Review notes whenever certain features are controlled server-side.

4. Guideline 4.2: Minimum functionality and the web-wrapper suspicion

Guideline 4.2 Minimum Functionality is one of the most sensitive rejection reasons for React Native, and especially for Expo projects with heavy WebView usage. Apple rejects apps that are "essentially a website wrapped in an app shell" without native functionality beyond what a mobile website could equally provide. Since React Native apps compile down to native code, this guideline rarely applies unfairly in practice, but it does catch apps that primarily embed a WebView and barely use native features such as camera, push notifications, or offline functionality.

To avoid this rejection reason, an app should actively demonstrate genuine native platform integration: push notifications, native navigation instead of an embedded web page, access to device capabilities like camera or location, and a UI that follows native interaction patterns rather than responsive web design. In the App Review notes it can additionally help to explicitly explain which native modules and capabilities the app offers over a plain website.

5. Guideline 5.1.1: Privacy, the privacy manifest and ATT

Guideline 5.1.1 Data Collection and Storage has become one of the more technically demanding rejection reasons in recent years, since Apple made the privacy manifest (`PrivacyInfo.xcprivacy`) mandatory for certain third-party SDKs. For React Native apps this means: every bundled native library that appears on Apple's list of "commonly used third-party SDKs" must ship its own privacy manifest; if it's missing, App Store Connect rejects the build before a human reviewer even looks at it.

Guideline 5.1.1 additionally requires an App Tracking Transparency (ATT) prompt as soon as an app uses advertising IDs or user data across devices for tracking purposes. A common rejection reason arises when an analytics or ad SDK bundled in a React Native app brings tracking functionality that the team overlooks because it is not visible in their own JavaScript code. A thorough review of every native dependency for privacy manifest requirements and tracking behavior before each submission is therefore essential.

{
  "NSPrivacyTracking": true,
  "NSPrivacyTrackingDomains": ["analytics.example.com"],
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypeDeviceID",
      "NSPrivacyCollectedDataTypeLinked": true,
      "NSPrivacyCollectedDataTypeTracking": true,
      "NSPrivacyCollectedDataTypePurposes": ["NSPrivacyCollectedDataTypePurposeThirdPartyAdvertising"]
    }
  ]
}

// Request App Tracking Transparency before using any advertising
// identifier - required whenever a bundled SDK tracks across apps
import AppTrackingTransparency

func requestTrackingIfNeeded() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            print("Tracking authorized, IDFA available")
        case .denied, .restricted, .notDetermined:
            print("Tracking not authorized, fall back to contextual ads")
        @unknown default:
            break
        }
    }
}

6. Guideline 3.1.1: In-app purchase for digital goods

Guideline 3.1.1 In-App Purchase requires that digital content and features unlocked inside the app go exclusively through Apple's in-app purchase system. A common rejection reason for React Native apps with subscription models is a link to an external payment page in the browser, meant to bypass Apple's 30 percent commission; Apple actively looks for this pattern and rejects it consistently, even when the link is placed subtly.

Physical goods and services delivered outside the app are exempt from this rule, which in practice often causes confusion: a React Native app that both sells physical products and offers digital premium features must cleanly separate both payment paths. Libraries like `react-native-iap` wrap the native StoreKit integration, but they do not replace the substantive review of which features actually must go through in-app purchase to avoid this rejection reason.

// Never link external payment for digital goods in a review build,
// even behind a feature flag - reviewers actively look for this
function SubscriptionScreen() {
  const handlePurchase = async () => {
    // Correct: route through native StoreKit / Play Billing
    await requestSubscription('premium_monthly');
    // Wrong: Linking.openURL('https://example.com/checkout')
  };
  return <PurchaseButton onPress={handlePurchase} />;
}

7. Human Interface Guidelines: implementing native UI patterns correctly

Even though Human Interface Guidelines (HIG) violations less often trigger an outright rejection than the guidelines discussed above, they regularly show up as a secondary rejection reason alongside other issues. Typical patterns in React Native apps are custom, non-native navigation bars that look visually very different from standard iOS components, or gestures that override established system gestures such as the edge-swipe-back gesture.

For React Native teams it is worth using libraries that wrap native navigation components instead of rebuilding custom UI elements from scratch. This not only reduces the risk of HIG-related rejection reasons, it also improves the actual user experience, since native components automatically bring accessibility features like VoiceOver that often need to be implemented after the fact with fully custom-built UI elements.

8. Resolution Center and the appeal process

If an app gets rejected despite careful preparation, the Resolution Center in App Store Connect is the central communication channel with the reviewer. It lets you clarify whether a rejection is based on a misunderstanding, for instance if the reviewer simply did not find a feature that actually exists, or whether a genuine change is needed. The App Store review guidelines explicitly allow developers to submit additional explanations and screen recordings before a build has to be resubmitted entirely.

If a rejection seems substantively wrong, for instance because a guideline was clearly misapplied, the official App Review Board appeal process is available as well, decided independently of the original reviewer. This path should only be used for genuinely disputed cases, though; for clear-cut rejection reasons like a missing privacy manifest or a web-wrapper suspicion, directly fixing the issue is usually faster than an appeal.

#!/usr/bin/env bash
# Pre-submission checklist for App Store review, run before every upload
set -euo pipefail

echo "Checking for expired provisioning profiles..."
eas credentials --platform ios --non-interactive || true

echo "Checking PrivacyInfo.xcprivacy exists for known third-party SDKs..."
find ios -name "PrivacyInfo.xcprivacy" -print

echo "Checking for hardcoded external payment links..."
grep -R "checkout" src/ || echo "No external checkout links found"

echo "Reminder: verify demo account credentials are still valid."

9. Common rejection reasons at a glance

The following overview summarizes the App Store review guidelines covered in this article and their typical triggers, so it can be used as a checklist before every submission.

These five App Store review guidelines cover the majority of all React-Native-specific rejection reasons. Anyone who checks them systematically before every submission, rather than reacting only after a rejection, cuts the average time to a successful release considerably.

10. Summary

The App Store review guidelines punish React Native apps for mostly the same handful of structural weaknesses: incomplete builds without a working demo account, outdated screenshots, an architecture too web-heavy without genuine native integration, missing privacy manifests for third-party SDKs, and external payment paths for digital goods. Each of these rejection reasons can be reliably avoided with a systematic pre-submission check.

The decisive difference between teams that face frequent rejections and teams with smooth releases rarely comes down to technical skill; it comes down to whether the App Store review guidelines are treated as a fixed part of the release process or only get read after the first rejection. Anyone who thinks about privacy manifests, demo access, and proof of native integration from the start noticeably reduces the number of review cycles.

11. FAQ: App Store Review Guidelines for React Native Apps