App Store rejection reasons fall into a small set of operational classes: incomplete or broken app behavior, inaccurate metadata, reviewer access, business-model rules, privacy, design quality, and submission configuration. Classify the rejected item before choosing a fix.
The short version
- App Store rejection reasons fall into a small set of operational classes: incomplete or broken app behavior, inaccurate metadata, reviewer access, business-model rules, privacy, design quality, and submission configuration.
- The guideline number is only the first label. The useful diagnosis combines the cited rule, the rejected item, the reviewer’s observed symptom, and the surface that must change.
- Save the complete reviewer message and every attachment.
- Do not promise approval; give App Review a testable path.
Extract the four facts in the rejection
Treat the message as a record with four fields: cited rule, rejected item, observed behaviour, and requested next step. A guideline number without the other three fields is not yet a diagnosis.
Preserve Apple’s complete message and attachments, then inspect the status of every item submitted with the version. Write a neutral failure statement such as “the reviewer could not complete sign-in after entering the supplied account”; do not guess why the reviewer acted.
Triage the rejected item
Classify in this order: binary behaviour, bundled content, editable product-page metadata, review access, remote service, then policy interpretation. This order prevents a broad rule citation from sending you straight to an unrelated code change.
- Save the complete reviewer message and every attachment.
- Name the exact rejected item, not only the app version.
- Separate runtime behavior from editable App Store Connect metadata.
- Reproduce the reviewer path before making a change.
- Choose one response channel: reply, metadata edit, new build, or appeal.
Keep one triage sheet containing the item name, version and build, message date, device details, reproduction result, and owner of the next action. That is enough evidence to route the case without copying an entire operational playbook.
Route the rejection to the right change surface
Use the changed surface as the build test. Executable behaviour and bundled resources require another binary; product-page text may not; account or service repairs need a clean verification before the existing build can be reused.
| Situation | Next action | New build? |
|---|---|---|
| Crash, freeze, broken control | Fix runtime behavior and upload a tested build | Usually yes |
| Wrong screenshot or description | Edit the affected metadata and explain the change | Usually no |
| Reviewer cannot sign in or reach a service | Repair access or availability, then provide exact steps | Depends |
| Guideline disagreement with working evidence | Clarify first; appeal only if the disagreement remains | No initial rebuild |
| Rejected related item in a submission | Correct, resubmit, or remove that item | Depends on item |
Use this routing matrix to match the observed class to the surface that must change; a broad rejection label alone does not justify a binary upload.
Read a rejection as four separate facts
Start with the cited guideline, the item status, the reviewer’s reproduction details, and the requested remedy. A broad label such as 2.1 can describe a crash, an expired account, placeholder copy, or an unavailable backend. Those are different fixes.
Apple’s status reference distinguishes rejected app bundles from rejected metadata and unresolved submissions. That distinction prevents the common reflex of uploading a new build for every message.
Class 1: app completeness and technical failure
Guideline 2.1 covers submissions that cannot be reviewed as complete products. The visible symptom matters more than the umbrella number. A crash or bundled placeholder normally requires a build. Bad review credentials or a restored backend may not.
Run the exact reviewed path from a clean installation. Use the same build, a production-like account, and the closest available device and OS. Record whether the failure exists in code, content bundled with the app, remote configuration, account state, or reviewer instructions.
Class 2: accurate metadata and product-page mismatch
Guideline 2.3 concerns information that does not accurately describe the app. Screenshots, previews, descriptions, names, subtitles, and claims should match the submitted experience. If the build is correct and the listing is wrong, fix the listing rather than rebuilding.
A mismatch can also expose a product problem. If a screenshot advertises a feature that is absent from the binary, removing the claim is a metadata fix. Adding the feature changes the binary and needs a build.
Class 3: reviewer access and external dependencies
Reviewers need a stable route through login, subscriptions, seeded data, permissions, and remote services. Test that route outside your development environment. A valid account that requires a one-time code the reviewer cannot receive is not useful review access.
External availability failures need two checks: restore the service, then make the app fail safely if it becomes unreachable again. A backend recovery may permit the same build only when the existing binary already handles the failure appropriately.
Class 4: business model, privacy, safety, and design
Some rejection families are policy decisions rather than software defects. Payments, subscriptions, account deletion, data collection, user-generated content, minimum functionality, spam, and regulated claims each have their own rule text. Read the cited section before borrowing a fix from a nearby case.
These topics can require changes across code and App Store Connect. Privacy and regulated-app questions also deserve professional advice where legal, medical, or financial obligations apply.
Class 5: submission items and unresolved issues
An app submission can contain more than the app version. Apple’s current workflow can include subscriptions, in-app purchases, events, and product-page items. One rejected item can keep the submission unresolved even when another item was accepted.
Open the submission, identify every rejected item, and either correct and resubmit it or remove it when appropriate. Do not interpret one accepted item as approval of the whole submission.
Use the smallest complete correction
A small fix is useful only when it is complete across the product, submission, and reply. Changing code without attaching the new build leaves the old behavior under review. Editing a screenshot without saving every localization can leave the mismatch in place.
Avoid unrelated changes during a rejection cycle. They enlarge the test surface and make your reply harder to verify.
Where the broad next-step guide fits
This page maps rejection families. If you already know the symptom and need the full action sequence, use the guide to decide what to do after an App Store rejection. Keep the two jobs separate: taxonomy here, decision workflow there.
Use the matching rejection guide
Once you identify the failure class, move to the narrow guide that matches the symptom:
- Fix Guideline 2.1 App Completeness Rejections
- App Crashes During Review: Clean-Install Debugging
- Placeholder Content Rejection: Finish the Product
- Backend Unavailable During App Review: Recover Safely
- App Store Metadata Rejected: Fix It Without a Build
- App Store Screenshot Mismatch: Fix Guideline 2.3
- How to Reply to App Review With Evidence
- Appeal or Resubmit After an App Store Rejection?
- Break an App Store Rejection Loop
Separate status from cause
A status tells you where an item sits in App Store Connect; it does not explain why the reviewer stopped. Read the status together with the message. “Metadata Rejected” points you toward an editable listing surface, while an unresolved submission can include several related items with different outcomes. Do not convert either label into an automatic rebuild.
Map every submitted item separately. The app version, in-app purchase, subscription, event, and product-page item can each have its own state. This prevents an accepted related item from being mistaken for acceptance of the whole submission.
Diagnostic map by observable symptom
Use the first reviewer-visible failure to choose the narrow guide. A launch termination belongs to the crash investigation. An app that opens but shows temporary UI belongs to the placeholder audit. A request that never yields usable content belongs to the backend availability workflow.
When the app works but the listing overstates it, use the metadata correction guide; when the mismatch is visual, use the screenshot recapture guide. These distinctions matter because only some paths modify the executable.
Access failures are their own branch
A reviewer who cannot sign in, receive a one-time code, reach seeded content, or find a hidden feature has not necessarily found a code defect. Test the supplied account from a clean device and a public network. Check expiry, role, region, required consent, and whether the route depends on a channel unavailable to Apple.
Correct credentials and Review Notes when access information is wrong. Change the app when the route itself is brittle or blocks review behind an avoidable dependency. A recovered account should be tested through the entire feature path, not just the login screen.
Policy disagreements need a narrower record
Payments, privacy, safety, design, spam, and minimum-functionality cases cannot be solved by borrowing a completeness template. Open the cited rule, identify the exact product behaviour at issue, and separate what Apple observed from what you believe the rule permits. Regulated health, finance, gambling, and children’s-app questions may need qualified professional advice.
If the submission already behaves as documented and your evidence supports a different reading, send a factual clarification and then use the appeal-or-resubmit decision guide. If you can reproduce a defect, fix it instead of framing it as interpretation.
A complete correction crosses three surfaces
Check product, App Store Connect, and communication before resubmitting. A code fix is ineffective if the old build remains selected. A new screenshot is ineffective if one localisation retains the old claim. A repaired account is ineffective if Review Notes still contain expired credentials.
Finish by following the reply framework and, if rounds are accumulating, the rejection-loop ledger. The goal is not a long dossier; it is a compact chain from Apple’s observation to the exact correction and repeatable verification.
Build a one-page triage record
Before anyone edits the app, reduce the rejection to a record another teammate can verify without reading the whole Resolution Center thread. This prevents the broad guideline number from becoming the team’s diagnosis and keeps code, metadata, access, and communication changes from being mixed together.
| Field | What to record | Why it matters |
|---|---|---|
| Reviewed artifact | App version, build number, rejected item, and relevant locale | Proves which artifact Apple actually evaluated |
| Observed symptom | Apple’s exact sentence, screenshot, attachment, and first failed step | Separates evidence from your interpretation |
| Change surface | Binary, metadata, account, backend, purchase item, or reply only | Determines whether a new build is required |
| Verification | Device, OS, account state, storefront, route, timestamp, and result | Makes the correction reproducible |
| Next action | Clarify, edit metadata, repair access, upload a build, resubmit, or appeal | Stops several incompatible actions from running in parallel |
Give one person ownership of that record for the current round. If a developer changes the binary, the record must name the replacement build. If someone edits App Store Connect, it must name the field and localisation. If access or backend state changes, it must carry a fresh external test. The record is complete only when Apple’s original path can be repeated against the exact submission you intend to send next.
This is also the fastest cannibalisation check between guides in this cluster: the symptom chooses the specialist page, while this pillar keeps only the classification and routing decision. Do not paste every specialist checklist into the record. Link to the matching diagnosis, capture the result, and keep the evidence short enough that the reviewer can follow it.
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: App Review Guidelines, App Review Guidelines, 2.1 App Completeness, App Review Guidelines, 2.3 Accurate Metadata. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026.
FAQ about App Store rejection reasons
Is every App Store rejection a code problem?
No. Metadata, access details, App Store Connect configuration, and policy disagreements may be resolved without changing the binary.
Does a rejected submission always need a new build?
No. Upload a new build when executable behavior or bundled assets change. Metadata-only corrections can often keep the current build.
What should I do with a vague rejection message?
Reply with one or two precise questions about the screen, account state, device, or action that produced the issue.
Can I appeal immediately?
You can use Apple’s appeal path, but first confirm the guideline, reproduce the behavior, and supply evidence. An unfixed defect is not a strong appeal.
Why is my submission unresolved when one item was accepted?
Items submitted together can receive different outcomes. The overall submission remains unresolved until rejected items are corrected, resubmitted, or removed.
Conclusion
Name the rejected item, observable failure, and change surface first. Then use the narrow spoke above and send App Review one repeatable verification path.
Sources and references
- App Review Guidelines (accessed 2026-08-04)
- App Review Guidelines, 2.1 App Completeness (accessed 2026-08-04)
- App Review Guidelines, 2.3 Accurate Metadata (accessed 2026-08-04)
- Reply to App Review messages (accessed 2026-08-04)
- Manage a submission with unresolved issues (accessed 2026-08-04)
- App and submission statuses (accessed 2026-08-04)
- Submit an app (accessed 2026-08-04)
- App Store support, appeals and review support (accessed 2026-08-04)