App Store Rejection Reasons in 2026, and How to Fix Each One

It's the night before launch. The build went to review yesterday, and the reply is two sentences long: "Guideline 2.1 - Performance - App Completeness. We were unable to sign in with the demo account provided." The launch email is scheduled for 9am, and the app is stuck behind a login screen nobody at Apple can get past.

Most App Store rejection reasons look like that. They're rarely about something deep. They're about something nobody checked. I've shipped 50+ apps through App Store and Google Play review, rejections included, and this guide is the list I wish every team had before their first submission: what each guideline actually means, why React Native and Expo apps trip over it, and how to fix it. If you're already rejected, skip to what to do next.

Key takeaways

• Apple reviewed 9,100,620 submissions in 2025 and rejected 2,093,244, roughly 1 in 4.
• Guideline 2.1 (App Completeness) is the big one. Apple says over 40% of unresolved issues relate to it: crashes, placeholder content, broken links and missing demo accounts.
• Privacy is the second trap. You need a privacy policy link in two places, purpose strings that explain why, account deletion inside the app, and a privacy manifest for "required reason" APIs.
• Digital goods need in-app purchase, except in a few named cases and, since 2025, links to external checkout on the US storefront. Physical goods and real-time person-to-person services use your own payments.
• If you're rejected, reply, fix and resubmit. Appeal to the App Review Board only when you believe the reviewer misunderstood the app.
• Apple reviews 50% of submissions within 24 hours and 90% within 48, so a fixed rejection usually costs a day or two, not a week.

How often does Apple reject apps?

About one submission in four. Apple's 2025 App Store Transparency Report gives the numbers, broken down by section of the App Review Guidelines:

The section counts add up to more than the 2,093,244 total because one submission can break several rules at once. The same report counts 387,087 apps approved after an earlier rejection. A rejection is usually a delay, not a verdict.

Notice where the volume is. Performance and Legal, the sections where completeness and privacy live, outnumber everything else combined. That's where to spend your pre-submission time.

The App Store rejection reasons that come up most, and how to fix each

1. Guideline 2.1: App Completeness

Apple's wording is direct: submissions "should be final versions with all necessary metadata and fully functional URLs included," and you should "include demo account info (and turn on your back-end service!) if your app includes a login."

That bracketed line exists because so many apps fail on it. The usual causes:

• The build Apple tested isn't the build you tested. In React Native this is common: you test a development build, but Apple gets a release build with Hermes bytecode, production environment variables and no debugger. A missing variable in your EAS production profile can crash the app on launch.
• The demo account doesn't work or works but shows an empty app. A reviewer who sees an empty dashboard can't tell whether the feature exists.
• Placeholder content: lorem ipsum, "coming soon" tabs, test products.
• Dead links: a support URL that 404s or a privacy policy on a staging domain.
• In-app purchases the reviewer can't find. Guideline 2.1(b) says purchases must be "complete, up-to-date, visible to the reviewer and functional." If a product isn't reachable yet, say why in the review notes.

The fix: install the exact release build on a physical device and run the core flow on cellular data. Create a reviewer account with realistic data already in it, and keep the backend it talks to switched on until you're approved. If the app needs hardware the reviewer won't have, such as a Bluetooth device, say so in the review notes and link a short screen recording of the full flow.

2. Guideline 5.1.1: Privacy policy, purpose strings and account deletion

Guideline 5.1.1 is where most Legal rejections come from. It has three parts that catch people.

A privacy policy in two places. "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." The in-app link is the one teams forget.

Purpose strings that actually explain. Every permission prompt shows a sentence you write, and Apple asks that you "ensure your purpose strings clearly and completely describe your use of the data."

In Expo you set these through ios.infoPlist (for example NSCameraUsageDescription) or through the permission options most config plugins expose.

Account deletion inside the app. If people can create an account, they must be able to start deleting it from inside the app. Apple's account deletion page adds the details that trip teams up:

• If deletion finishes on your website, the link must go "directly to the page on your website where they can complete the process."
• Unless you're in a highly regulated industry, you can't make people phone, email or go through a support chat.
• "Only offering to temporarily deactivate or disable an account is insufficient."
• If you support Sign in with Apple, revoke the user's tokens through the Sign in with Apple REST API as part of deletion.

One more check reviewers make: your App Privacy answers in App Store Connect must match what the app actually collects. If you ship an analytics or crash-reporting SDK, "Data Not Collected" isn't true.

3. Privacy manifests: the rejection that arrives before review

Some problems never reach a reviewer. If your app or one of its SDKs calls a "required reason" API (user defaults, file timestamps, system boot time, disk space or the active keyboard) without declaring an approved reason, App Store Connect flags it when you upload, typically as ITMS-91053: Missing API declaration. Apple has required these declarations for new apps and updates since May 2024.

In Expo, declare them in your app config:

{
  "expo": {
    "ios": {
      "privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
          }
        ]
      }
    }
  }
}

Expo's own guide warns that Apple doesn't correctly parse every PrivacyInfo.xcprivacy file shipped inside static CocoaPods dependencies. If Apple's email lists reasons you didn't expect, copy them from the library's manifest into your app config and upload again.

4. Guideline 2.3: Metadata that doesn't match the app

Your listing is reviewed as strictly as your code.

• Screenshots "should show the app in use, and not merely the title art, login page, or splash screen" (2.3.3).
• No hidden features. "Don't include any hidden, dormant, or undocumented features in your app" (2.3.1(a)). This one is serious: "egregious or repeated behavior is grounds for removal from the Apple Developer Program."
• The description, pricing and feature list must match the build you submitted. Writing about features planned for next month is a common mistake.

If you use feature flags, make sure everything visible in your screenshots is switched on for the reviewer's account.

5. Guideline 4.2: Minimum Functionality

"Your app should include features, content, and UI that elevate it beyond a repackaged website." In practice this hits apps that are mostly a WebView around an existing site.

React Native helps here, but only if you use it. A thin wrapper with a WebView home screen will be judged as a website. The fix is native value a website can't give: push notifications people opted into, offline access, the camera or Bluetooth, native navigation, widgets. Mention those features in the review notes so the reviewer finds them.

6. Guideline 4.3: Spam (and the white-label problem)

4.3 says "Don't create multiple Bundle IDs of the same app" and "Don't submit apps that are indistinguishable from what's already widely available."

The teams that hit this are rarely spammers. They're agencies and SaaS companies shipping one template app per client: one app per gym, per restaurant, per clinic. To Apple those are the same app many times over.

The fix is usually architectural: one app with many tenants inside it. Floey, the Kuwaiti fitness platform I built, is shaped this way. There's one consumer app where people discover gyms and book classes. Behind it, each gym is an isolated tenant in the backend with its own branded booking site on the web. If every client truly needs its own App Store listing, look at Apple's guidance on white-label and container apps before you build, not after.

7. Guideline 3.1.1: In-app purchase rules, and the exceptions people miss

The rule: "If you want to unlock features or functionality within your app ... you must use in-app purchase." That covers subscriptions, premium content and one-time upgrades.

The exceptions matter, and they're more common than people think:

• Reader apps (3.1.3(a)) can give access to content bought elsewhere: "magazines, newspapers, books, audio, music, and video."
• Multiplatform services (3.1.3(b)) can let people use what they bought on your website or another platform.
• Real-time person-to-person services (3.1.3(d)) can use other payment methods. Apple's own examples include "tutoring students, medical consultations, real estate tours, or fitness training."
• Physical goods and services used outside the app, such as a cocktail capsule subscription or a gym class, use your own payment flow (Apple Pay, cards, or regional rails like KNET), not in-app purchase.
• On the US storefront, since 2025, apps can include "buttons, external links, or other calls to action" to purchase outside the app (3.1.1(a)). Everywhere else, that's still restricted. Check which storefronts you sell in before adding a "buy on our website" button.

8. Guideline 4.8: Login services

If you offer Google, Facebook or another third-party login, you must also offer an equivalent login option that limits data collection to name and email, lets people keep their email private, and doesn't track them for advertising without consent. Sign in with Apple meets all three, which is why it's the usual choice.

9. Background modes and push (2.5.4 and 4.5.4)

• Background services may only be used "for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc." If you request background location, the feature that needs it must be obvious in the app and explained in the review notes.
• Marketing pushes need explicit opt-in "via consent language displayed in your app's UI," plus a way to opt out inside the app.

10. The iPad you didn't test on

Rejection messages name the device the reviewer used, and it isn't always an iPhone. iPhone apps run on iPad in compatibility mode, so a crash or an unusable layout there is still your problem.

In Expo, ios.supportsTablet defaults to false. Only set it to true if you've designed and tested tablet layouts. Either way, open the release build on an iPad (a simulator is fine) before you submit.

Rejected at upload vs rejected in review

Not every "rejection" comes from a person. Errors with an ITMS- code, or a build stuck as an invalid binary, come from automated processing when you upload. Common causes are missing icons, a missing privacy manifest declaration, or building with an SDK Apple no longer accepts. These arrive by email soon after the upload finishes. Fix the build, bump the build number and upload again. No reviewer has seen your app yet.

What to do when you're rejected

1. Read the whole message, including any attached screenshots and the review device. The guideline number tells you the category. The sentences after it tell you the actual problem.
2. Reply in App Store Connect if anything is unclear. Apple's process is to "correspond with App Review to resolve the issues before resubmitting the build," in the App Review section of your app's page. An "Information Needed" message usually needs an answer, not a new build.
3. Fix and resubmit. If only the metadata was wrong (screenshots, description), edit it and resubmit without a new build. If the code changed, upload a new build.
4. Use the bug-fix option when it applies. If you submitted a bug fix and the reviewer found other issues, Apple lets you fix those in your next submission, "as long as there are no legal or safety concerns." Reply to their offer in App Store Connect.
5. Appeal only for genuine misunderstandings. The App Review Board is for when "we misunderstood your app's concept and functionality, or ... you were treated unfairly." Give specific reasons the app complies, answer any open information requests first, and remember it's one appeal per rejected submission.
6. Expedite when it's urgent. You can request an expedited review to fix "a critical bug" (include steps to reproduce it on the current version) or to release "to coincide with an event you're directly associated with."

What the App Store Connect statuses mean

• Rejected: a reviewer found a problem with the build or the app's behaviour; fix it and resubmit the same version.
• Metadata Rejected: only the listing needs changing (screenshots, description, privacy details); edit it and resubmit without a new build.
• Developer Rejected: you pulled the submission yourself, usually to swap in a new build. Nothing is wrong.
• Invalid Binary: the upload failed automated checks before review; read the email for the ITMS- error.

You can't delete a version that has been reviewed. To replace a rejected build, remove it from the version, attach a new build with a higher build number, and resubmit.

Asking for ratings without breaking the rules

Apple's guideline 5.6.1 requires the system API for rating prompts and disallows custom review prompts. In React Native, expo-store-review calls it:

import * as StoreReview from "expo-store-review";

if (await StoreReview.hasAction()) await StoreReview.requestReview();

iOS decides whether to actually show the prompt and limits how often it appears, so call it after a moment of success (a completed booking, a finished workout) rather than on launch, and never gate features behind a rating.

How long does App Review take in 2026?

Apple says it reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours." Plan for two days, and don't schedule a launch on the day you submit.

The pre-submission checklist (save this)

Run it against the release build, not your development build. I update this list as Apple's rules change.

Build

• Release build installed on a physical iPhone; the core flow works on cellular data.
• The same build opened on an iPad (simulator is fine) without crashes or broken layouts.
• No placeholder text, test products or "coming soon" screens.
• Production environment variables present in the EAS (or CI) production profile.

Access

• Demo account in the review notes, with realistic data already in it.
• Backend for that account switched on, and staying on until you're approved.
• Hardware or location-dependent features explained, with a screen recording link.

Privacy

• Privacy policy linked in App Store Connect and inside the app.
• Every purpose string says what the data is used for, in the user's terms.
• Account deletion can be started inside the app.
• App Privacy answers match every SDK you ship.
• Privacy manifest declares every required-reason API (yours and your SDKs').

Payments

• Digital goods use in-app purchase, unless a named exception applies.
• Every in-app purchase product is visible and works for the reviewer.
• External purchase links appear only where your storefront allows them.

Listing

• Screenshots show the app in use and match this build.
• Description describes only what's in this build.
• Support URL works and has current contact details.

FAQ

How soon can I resubmit after an App Store rejection?

Immediately. There's no waiting period. Fix the issue, reply in App Store Connect if the reviewer asked a question, and resubmit. With most reviews finishing within 24 to 48 hours, a straightforward fix is often approved the next day.

Does a rejection hurt my developer account?

An ordinary rejection doesn't. You fix it and move on. What puts an account at risk is deliberately misleading review. Guideline 2.3.1 says hidden or undocumented features, when "egregious or repeated," are "grounds for removal from the Apple Developer Program."

Can I appeal an App Store rejection?

Yes, to the App Review Board, if you believe the reviewer misunderstood your app or treated you unfairly. Submit one appeal per rejected submission, give specific reasons the app follows the guidelines, and answer any outstanding information requests first. If the reviewer was right, fixing and resubmitting is faster.

Why was my app rejected under 4.3 when I wrote every line of it?

Guideline 4.3 isn't about who wrote the code. It's about whether the app is distinguishable from apps already on the store, including your own. Template apps published once per client, or several near-identical apps under different bundle IDs, are the usual trigger. Combining them into one app with multiple tenants usually solves it.

Next steps

Rejections are cheap to prevent and expensive to discover the night before launch. Put the checklist above into your release process, run it against the release build, and keep your demo account and backend alive until you see "Ready for Distribution."

If you're shipping a React Native or Expo app and want a second pair of eyes on the release, that's part of what I do. Get in touch or see how I work as a React Native developer.

Sources

• App Review Guidelines, Apple
• App Review: process, review times, appeals and expedited reviews, Apple
• 2025 App Store Transparency Report, Apple
• Offering account deletion in your app, Apple
• Describing use of required reason API, Apple
• Privacy manifests, Expo
• App config reference: ios.supportsTablet, ios.infoPlist, Expo