Guideline 2.1 rejection: App Completeness, decoded

Read the message closely before touching anything: 2.1 is an umbrella, and each subtype below has a different fix. The crash subtype is the one honest limit in this whole guide — a message cannot show a crash log, so that section tells you how to reproduce and evidence the fix rather than pretending a checklist settles it.

2.1 — App Completeness — crashes and obvious technical problems

The reviewer ran your build and it crashed, froze, or broke in an obvious way on their device. Apple rejects any binary that crashes or shows obvious technical problems — this is the single largest rejection class in Apple's own data (Performance accounts for over 1.35 million rejections in the 2025 Transparency Report).

Severity: blocker · Decoder confidence for this class: B (see the honesty note below)

The fix

1. Install the exact submitted build (from TestFlight or the archived .ipa) on a physical device — not the simulator — running the iOS version named in the message.
2. Sign in with the same demo account App Review used and walk every main flow: launch, sign-in, purchase/restore, settings, and anything behind a permission prompt.
3. Check Crashes organizer in Xcode / App Store Connect for the submitted version and fix the top crash first.
4. Test on a clean device or after deleting the app — first-launch and empty-state crashes are the most common reviewer crashes.
5. Fix, archive a new build, and re-test the new build on-device before resubmitting.

Resubmission checklist

• New build installed and launched on a physical device
• All primary flows completed signed-in as the demo account
• Top crash in the Crashes organizer addressed
• Backend services live and reachable outside your office network
• Reply to App Review states what was fixed and on which devices you tested

Reply draft

Hello App Review team,

Thank you for the report. We reproduced the crash described in your message on a physical device, identified the cause, and fixed it in the new build ([VERSION] / build [BUILD]).

What was wrong: [ONE-SENTENCE CAUSE].
What we changed: [THE FIX].
We re-tested the full flow on [DEVICE MODELS] running [iOS VERSIONS], signed in with the demo account provided, and the issue no longer occurs.

The new build is submitted for review. Please let us know if you need anything else.

[NAME]

What the decoder can diagnose here: The decoder can confirm this is the crash/bug class and which flow Apple named, if the message says. What it cannot: The decoder cannot run your app and cannot see the crash. If the message does not name the exact screen or action, the specific defect has to be found by testing the submitted build on a physical device, ideally the same device/OS the message mentions.

Rule text: “We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.” — App Review Guidelines §2.1(a), retrieved 2026-10-23

2.1 — App Completeness — Information Needed

This is usually not a rejection of the app itself — it is App Review pausing the review because they cannot understand or access something: how a feature works, where content comes from, how to reach a paywalled area, or what a hardware integration does. The submission stays in this state until you answer their specific questions in the Resolution Center.

Severity: blocker · Decoder confidence for this class: C (see the honesty note below)

The fix

1. Answer every question Apple asked, in order, in the Resolution Center — do not resubmit a new build unless they asked for one.
2. Attach a screen recording (on a physical device) showing the exact flow they asked about, from launch to the feature in question.
3. If content comes from a third party or a feed, say so plainly and name the source.
4. If a feature needs hardware, a QR code, or a second device, provide it (or a video of it working) with this reply.
5. Put the same explanations in the App Review notes for the next submission so the next reviewer does not ask again.

Resubmission checklist

• Every numbered question in Apple's message answered explicitly
• Screen recording of the requested flow attached
• Demo account and any required hardware/QR assets provided
• Same explanations copied into App Review notes

Reply draft

Hello App Review team,

Thank you for your questions. Answers to each point below:

1. [QUESTION 1] — [YOUR ANSWER]
2. [QUESTION 2] — [YOUR ANSWER]
3. [QUESTION 3] — [YOUR ANSWER]

I have also attached a screen recording from a physical device showing [THE FLOW REQUESTED], and added the same explanations to the App Review notes.

Please let me know if any point needs more detail.

[NAME]

What the decoder can diagnose here: The decoder can identify the information-request class and list the questions Apple asked, if they are in the message. What it cannot: Apple's questions are specific to your app; the decoder cannot answer them for you, and guessing instead of answering the exact questions is the most common reason this state repeats.

Rule text: “Submissions to App Review should be final versions with all necessary metadata and fully functional URLs included.” — App Review Guidelines §2.1(a) and 'Before You Submit' checklist, retrieved 2026-10-23

2.1 — App Completeness — demo account or full access not provided

The reviewer could not get into your app. Either no demo account was provided, the credentials failed, the account is empty or region-locked, an SMS/2FA step blocked them, or gated features sit behind a paywall the demo account cannot pass. Apple explicitly requires full access: an active demo account or a fully-featured demo mode, plus any hardware or resources needed to review.

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. Create (or reset) a dedicated review account and test it from a fresh install of the submitted build before replying.
2. Remove or bypass 2FA/SMS verification for the review account, or pre-verify it and say so in the notes.
3. Pre-load the account with representative content and unlock every paid/gated area the reviewer needs to see.
4. Enter the username and password in the App Review Information section of App Store Connect (not only in the notes text), and repeat them in your Resolution Center reply.
5. If sign-in is impossible for legal/security reasons, ship a built-in demo mode that shows full features and note that Apple approval for demo-mode-in-lieu applies.

Resubmission checklist

• Review account tested from a fresh install
• No 2FA/SMS wall on the review account
• Account has content and full feature access
• Credentials present in App Review Information AND in the reply
• Backend account still active (not expired or rate-limited)

Reply draft

Hello App Review team,

Apologies for the access problem. A dedicated review account is ready and tested from a fresh install of the submitted build:

Username: [USERNAME]
Password: [PASSWORD]

The account has [CONTENT/FEATURES UNLOCKED] and no two-factor step. The same credentials are in the App Review Information section. Please let me know if you hit anything else.

[NAME]

What the decoder can diagnose here: The decoder can confirm the access class from the message wording. What it cannot: The decoder cannot test your credentials; only you can verify the account works from a fresh install, on a US-region device, with no prior session.

Rule text: “Provide App Review with full access to your app. If your app includes account-based features, provide either an active demo account or fully-featured demo mode, plus any other hardware or resources that might be needed to review your app.” — App Review Guidelines, 'Before You Submit' checklist, retrieved 2026-10-23

2.1 — App Completeness — placeholder or unfinished content

The build or its metadata still contains stand-in content: placeholder text, 'coming soon' screens, lorem ipsum, empty web pages, or dead links. Apple requires final versions with all temporary content scrubbed before submission.

Severity: blocker · Decoder confidence for this class: B (see the honesty note below)

The fix

1. Search the project for 'lorem', 'placeholder', 'TODO', 'coming soon' and remove or complete every hit.
2. Open every external URL in your metadata (support, privacy, marketing) and confirm each loads real content.
3. Remove or finish any feature that dead-ends at an empty state in the submitted build.
4. Resubmit a new build if the placeholder content is in the binary; metadata-only placeholders can be fixed in App Store Connect without a new build — say which you did in your reply.

Resubmission checklist

• No placeholder/lorem/coming-soon text anywhere in the build
• All metadata URLs load finished pages
• Empty states either filled or the feature removed
• Reply states whether a new build was submitted

Reply draft

Hello App Review team,

Thank you for flagging this. The placeholder content you found at [LOCATION] has been [removed / completed] in [the new build / updated metadata]. We audited the full app and all linked pages for any other temporary content and found none remaining.

[NAME]

What the decoder can diagnose here: The decoder can identify the class; Apple's message usually names the screen or URL. What it cannot: The decoder cannot crawl your app or website; you must audit every screen and every linked page (support URL, privacy URL, marketing URL) yourself.

Rule text: “Placeholder text, empty websites, and other temporary content should be scrubbed before submission.” — App Review Guidelines §2.1(a), retrieved 2026-10-23

2.1 — App Completeness — in-app purchases not found or not reviewable

You configured in-app purchase products, but the reviewer could not find or test them inside the app — the paywall is hidden, the products are not attached to the submission, they are still in a draft/missing-metadata state, or the purchase flow errors in the sandbox environment.

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. In App Store Connect, confirm every IAP product is in 'Ready to Submit' state and is attached to this app version.
2. Confirm each product has complete metadata: display name, description, price, and a review screenshot.
3. Make the purchase entry point reachable without special gestures or accounts — the reviewer must be able to find the paywall from normal use.
4. Test the full purchase and restore flow in sandbox with the submitted build.
5. If a product is intentionally hidden or seasonal, explain exactly why and how to reach it in the App Review notes, as §2.1(b) requires.

Resubmission checklist

• All IAP products attached to the submitted version
• Product metadata complete incl. review screenshots
• Paywall reachable in normal navigation
• Sandbox purchase + restore tested on the submitted build
• Any intentionally hidden product explained in review notes

Reply draft

Hello App Review team,

Thank you. The in-app purchases are now attached to this version and complete in App Store Connect. To reach them: [STEP-BY-STEP PATH TO THE PAYWALL]. We tested purchase and restore in sandbox on the submitted build.

[NAME]

What the decoder can diagnose here: The decoder can identify the IAP-visibility class from the message. What it cannot: The decoder cannot see your App Store Connect product states; product attachment and metadata completeness must be checked there.

Rule text: “If you offer in-app purchases in your app, make sure they are complete, up-to-date, visible to the reviewer and functional. If any configured in-app purchase items cannot be found or reviewed in your app, explain the reason in your review notes.” — App Review Guidelines §2.1(b), retrieved 2026-10-23

Related guides

• Rejection decoder — paste your message, get the fix
• App Store Pre-Flight — the full check and $29 Founding pre-sale
• Google Play Pre-Flight — deadlines and declarations
• Guideline 4.2 — Minimum Functionality

Sources

• App Review Guidelines §2.1(a), retrieved 2026-10-23
• App Review Guidelines §2.1(a) and 'Before You Submit' checklist, retrieved 2026-10-23
• App Review Guidelines, 'Before You Submit' checklist, retrieved 2026-10-23
• App Review Guidelines §2.1(b), retrieved 2026-10-23

Last updated October 23, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.