App Store Rejection Help | Understand and Fix Apple Rejections

On this page (12 sections)

Read the message and the guideline together

Open the message in App Store Connect (Resolution Center / the review thread for the version). Note the guideline number, the quoted guideline text, the reviewer’s explanation, any attached screenshots and the device and OS version listed. Then read the guideline in the App Store Review Guidelines. Most confusion comes from reading only one of the two.

Rejected vs Developer Rejected

Rejected means App Review found an issue. Developer Rejected means someone on your team withdrew the build from review (often by uploading a new one). The second is not an Apple decision; just submit the intended build. Metadata Rejected means only the listing needs to change and the same binary can usually be resubmitted.

The guidelines you will see most

Common App Store Review Guidelines cited in rejections
Guideline	Category	Typical trigger	Guide
2.1	App Completeness / Information Needed	Crashes, bugs, unreachable backend, missing demo account, unanswered reviewer questions	Guideline 2.1
2.3	Accurate Metadata	Screenshots, description, name, keywords, age rating that do not match the app	Metadata rejection
3.1	Payments / In-App Purchase	Digital content unlocked outside IAP, subscription disclosure, StoreKit issues	IAP / payment rejection
4.2	Minimum Functionality	Repackaged website, content-only or marketing app, template builds	Guideline 4.2
4.3	Spam / Similar apps	White-label, reskinned or duplicate apps; saturated categories	Guideline 4.3
5.1	Privacy	Privacy policy, permission strings, data minimisation, tracking, account deletion, App Privacy labels	Privacy rejection

Fix, reply, resubmit or appeal?

Choosing the response to an App Store rejection
Response	When	How
Reply	The reviewer asked a question, or misunderstood something you can clarify without changing the app	Answer in the review thread in App Store Connect with specifics and screenshots
Fix and resubmit	The finding is right: a bug, a missing feature, a privacy or payment issue	Change the app, upload a new build, describe the change in the notes
Resubmit same build	Metadata Rejected, or the only change is in review notes / credentials	Update the listing or notes in App Store Connect and resubmit
Appeal	You believe the decision is wrong and can show it with evidence	Use the App Review appeal form; be concise and factual

Read the appeal guide before appealing. An appeal is for incorrect decisions, not for correct ones you disagree with.

Reviewer access

A large share of 2.1 rejections are really access problems: no demo account, expired credentials, OTP the reviewer cannot receive, social login only, or a backend that blocks the reviewer’s region. Provide a durable demo account in the App Review Information section, with notes that describe every step. The Google Play reviewer access guide applies almost verbatim to Apple.

Metadata-only rejections can reuse the build

If the status is Metadata Rejected, fix the screenshots, description, keywords, age rating or review notes in App Store Connect and resubmit; a new binary is usually not required. If the reviewer cited app behaviour, you need a new build.

What the App Store Connect status means

App Store Connect statuses developers most often misread
Status	What it means	What to do
Waiting for Review	Submitted and queued; App Review has not started	Wait. Resubmitting restarts the queue position
In Review	A reviewer is working on the build	Keep the backend and demo account available; answer any message immediately
Pending Developer Release	Approved — you chose manual release	Release it in App Store Connect
Processing for Distribution	Approved and being prepared for the store	Nothing; it clears on its own
Metadata Rejected	Only the metadata is at fault	Fix the listing and resubmit the same build
Rejected	The build was rejected under a guideline	Read the guideline number, then fix, reply or appeal
Developer Rejected	You withdrew the submission	Resubmit when ready

Reviews are usually measured in hours to a couple of days; a genuinely critical fix can be put forward with an expedited review request. An unanswered reviewer message pauses the clock entirely.

Not a rejection: upload and toolchain blocks

If App Store Connect refuses the upload because the build was not made with Xcode 26 and the iOS 26 SDK, or emails ITMS warnings about privacy manifests and required-reason APIs, App Review has not seen the app yet — the build has to change. See legacy app update and the privacy manifest entry. A build that is simply waiting too long for a critical fix is a different case again: expedited review. Moving the app to another account is covered on App Store app transfer, and signing, profile and entitlement errors on iOS code signing.

Before the first submission

App Review rejects first submissions for a short, predictable list of reasons. The App Store submission checklist works through them in the order a submission actually fails. If purchases are part of the app and the products are not appearing at all, fix that first: in-app purchases not showing.

What we can change

Crash and completeness fixes on iOS native, Flutter, React Native and Unity builds; release-build QA on real devices
Demo accounts, OTP bypass for review, Sign in with Apple and login-services compliance
StoreKit and subscription implementation, restore purchases, IAP reviewability
Privacy manifests, permission purpose strings, App Tracking Transparency, account deletion, App Privacy label alignment
Meaningful differentiation or multi-tenant restructuring for 4.2 / 4.3 cases
Metadata and review-note corrections

What to send us

The full rejection message from App Store Connect, including the guideline text and attached screenshots.
App name, bundle ID, technology stack and whether this is a first rejection or a repeat.
Any replies you already sent and Apple’s responses.

Do not include passwords, signing keys, keystores, API secrets, recovery codes, payment credentials or personal data belonging to your users. We do not need any of these to review a rejection and we will ask you to remove them if they are included.

Frequently asked questions

Apple cited a guideline number. What does it mean?

The number maps to a section of the App Store Review Guidelines. 2.1 is App Completeness (crashes, bugs, incomplete features, reviewer access), 2.3 is Accurate Metadata, 3.1 is Payments and In-App Purchase, 4.2 is Minimum Functionality, 4.3 is Spam and similar apps, and 5.1 is Privacy. The number tells you the category; the reviewer's message and any attached screenshot tell you the specific trigger. Both matter.

Do I always need to upload a new build after an App Store rejection?

Not always. Metadata Rejected issues (screenshots, description, keywords, review notes) can often be corrected in App Store Connect and resubmitted with the same binary. Rejections that involve app behaviour, crashes, missing features, privacy flows or payments need a new build. If the reviewer asked a question rather than rejecting, reply in App Store Connect first.

My app is rejected under 4.2 because it uses a WebView. Is that banned?

WebView itself is not banned. What Guideline 4.2 targets is an app that offers little beyond what a website already provides. Apps built on WebView that add genuine native value — offline behaviour, device integration, notifications that matter, a workflow that is better as an app — can pass. Repackaged websites, marketing brochures and link collections usually cannot, regardless of how they are built.

Should I appeal straight away?

Usually not. An appeal is for cases where you believe the decision was wrong, not for cases where the reviewer was right and the app needs to change. Filing a weak appeal spends goodwill and time. Diagnose first: if the issue is real, fix it and resubmit; if the reviewer misunderstood the app, reply with clarification; reserve a formal appeal for a genuinely incorrect decision backed by evidence.