Surviving Apple's App Review in 2026: The React Native Rejections We Keep Seeing

Every React Native team we work with eventually hits the same wall: the build is green, TestFlight is happy, the PM has already drafted the launch tweet — and then App Review sends a polite paragraph that reads like a legal document. The rejections in 2026 are not the ones from the old blog posts. Reviewers have new checklists, and Expo-based apps hit a specific subset of them again and again.

This is the shortlist we now keep pinned in every mobile project's Notion. If your next submission is a first release or a big rewrite, read it before you hit Submit for Review.

The rejections that dominate in 2026

Apple's guidelines haven't been rewritten wholesale, but enforcement has shifted. A few patterns now account for the majority of rejections we see on React Native and Expo projects:

• Guideline 5.1.1(v) — account deletion missing, buried, or fake.
• Guideline 4.3(a) — "spam" / low-differentiation, especially for template-driven apps.
• Guideline 3.1.1 — steering users to external purchase flows.
• Guideline 5.1.2 — ATT prompt shown before consent, or tracking without it.
• Guideline 2.1 — crashes on iPad, or on the reviewer's specific iOS build.
• Guideline 2.3.10 — mentioning Android, beta, or unreleased features in metadata.

Android's review is faster and stricter about policy (data safety form, permissions declarations), but rarely the source of the multi-week saga. iOS is where release ops lives or dies.

Account deletion: still the #1 first-submission killer

Guideline 5.1.1(v) has been in force since 2022, but it keeps rejecting apps in 2026 because teams treat it as a settings-screen checkbox. Reviewers now actively test it. If the button opens a mailto, a support form, or a web page that requires re-login, expect a rejection.

What reviewers want:

1. A deletion entry point inside the app, reachable from account settings.
2. Deletion of the account itself, not just "deactivation" or "data export".
3. Confirmation that the request was received, even if final deletion is async.

A minimal React Native pattern that has passed review consistently:

async function requestAccountDeletion() {
  const confirmed = await confirm({
    title: 'Delete your account?',
    body: 'This permanently removes your profile, purchases history, and content. This cannot be undone.',
    destructiveLabel: 'Delete account',
  });
  if (!confirmed) return;

  await api.post('/account/deletion-requests');
  await auth.signOut();
  navigation.reset({ index: 0, routes: [{ name: 'DeletedConfirmation' }] });
}

Two things that trip teams up: if you have active subscriptions, you must tell the user how to cancel them (link to https://apps.apple.com/account/subscriptions), and if deletion is delayed for legal reasons, say so in plain language on the confirmation screen.

The subscription edge case

If the user has a live subscription, do not silently cancel it server-side. Apple wants the user informed that store-managed subscriptions aren't cancelled by deleting the app account. Show a screen. Link out. Log the acknowledgement.

Guideline 4.3: the "you look like a template" rejection

This one has quietly become the most frustrating rejection of 2026, especially for agencies and studios shipping multiple apps on similar stacks. Reviewers flag apps that appear to be minor variants of something else on the store — same layout, same onboarding flow, same categories.

Expo apps are especially vulnerable because so many starter templates share a visual DNA (the same tab bar icons, the same Onboarding-with-three-dots screen, the same auth stack).

What has actually gotten our clients through 4.3 rejections:

• Replace the generic onboarding with something that reflects the actual product's value. If your first three screens could belong to any app, they belong to none.
• Ship at least one feature that is clearly not from a boilerplate — a custom camera flow, a domain-specific calculator, an unusual data view.
• If you operate multiple similar apps under one developer account, be ready to justify why they aren't duplicates. Different target audiences alone is not enough anymore.

We've had 4.3 rejections overturned by writing a short note in App Review's contact form explaining the differentiation, but only when the app actually had differentiation to point at.

IAP and the external-purchase trap

Guideline 3.1.1 is where a lot of React Native teams overreach after reading about the recent US and EU rulings. The rules in 2026 are still narrower than the headlines suggest:

• In the US, you can link to an external website for purchases in reader apps and some other categories, following the External Link Account Entitlement rules.
• In the EU, alternative payment options are permitted under DMA but require the specific StoreKit External Purchase entitlements.
• Everywhere else, digital goods consumed inside the app still go through StoreKit. Period.

What rejects: a button in your React Native app that says "Get 20% off on our website" and opens Safari to a Stripe checkout for the same digital subscription that's sold via IAP. Even with the entitlement, you need approved on-device disclosure sheets and specific link parameters.

If you're not sure whether your case qualifies, don't guess. The safe default is: physical goods and services consumed outside the app can use any payment method; digital content used inside the app uses IAP. RevenueCat's docs on external purchase links are a better reference than most blog posts on this. For a broader look at IAP tradeoffs on RN, see our take on in-app purchases.

ATT: the prompt-timing rejection

App Tracking Transparency rejections have shifted. In 2026 the common failure isn't forgetting the prompt — it's showing it too early or gating features behind it.

Rules that reviewers actively check:

• The ATT prompt cannot appear before the app is usable. No prompt on the splash screen.
• You cannot condition access to any feature on the user tapping Allow.
• Your pre-prompt (the custom screen explaining why you want tracking) cannot use the words Allow or Deny, and cannot mimic the system dialog styling.
• If you initialise an analytics or ad SDK that uses the IDFA before consent, you're tracking without permission — even if you "turn it off later".

On React Native, react-native-tracking-transparency and the Expo Tracking Transparency module are both fine. The rejection risk is in when you call requestTrackingPermission(), not which library you use.

useEffect(() => {
  if (!hasSeenOnboarding) return;
  if (Platform.OS !== 'ios') return;

  (async () => {
    const status = await getTrackingPermissionsAsync();
    if (status.status === 'undetermined') {
      await showPrePrompt();
      await requestTrackingPermissionsAsync();
    }
  })();
}, [hasSeenOnboarding]);

Initialise your ad/analytics SDKs after you know the status, not on app boot.

The crash-on-iPad rejection nobody plans for

If your app is iPhone-only, declare it. If it's Universal, actually test on iPad. The reviewer opens your app on an iPad Pro, rotates it, and if anything hard-crashes or renders as a broken zoomed iPhone layout, you get a 2.1 rejection.

Recurring React Native causes:

• Native modules that assume portrait orientation.
• Fixed-width layouts that overflow on 12.9" screens.
• Splash screens configured only for iPhone aspect ratios.
• Camera or photo-picker flows that crash on iPad because you didn't set the popover source view.

Expo's expo-image-picker needs a presentationStyle on iPad or it can throw. Same with any share sheet. Test it once on a real iPad or the review will do it for you.

Metadata rejections that waste a week

These are the cheap ones — cheap to avoid, expensive if they hit at the wrong moment:

• Mentioning Android anywhere in screenshots, description, or What's New. Reviewers will flag it.
• Mentioning beta, early access, or coming soon features that aren't in the build.
• Screenshots that show content the app can't actually produce ("marketing composites").
• Support URL that 404s or redirects to a login wall.
• Privacy policy URL that doesn't cover every SDK you actually ship.

On the last one: your privacy nutrition labels must match what your SDKs actually collect. If you added Sentry, PostHog, or a new attribution SDK in the last sprint, update the labels before submitting. The mismatch itself won't always reject you, but combined with any other flag it becomes a compounding problem.

Where we'd start

If you're two weeks from a first submission, do three things this week:

1. Build the account deletion flow end-to-end and test it as a reviewer would — fresh install, real account, real delete.
2. Run the app on a physical iPad for 15 minutes. Rotate. Open every modal. Try the camera.
3. Read your own App Store description and screenshots with fresh eyes and remove every mention of Android, beta, or unshipped features.

Those three checks alone would have saved most of the rejections we've cleaned up this year. Everything else — ATT timing, 4.3 differentiation, IAP routing — is worth a proper review meeting with whoever owns product and legal, not a last-minute patch on submission day. If you want a second set of eyes before you ship, that's the sort of thing our mobile team does most weeks.