App Store 2.1 rejection: App completeness

Apple couldn’t finish reviewing your app. A 2.1 rejection can mean a crash, an incomplete screen, missing information, or a purchase the reviewer couldn’t reach. We’d match the notice to the exact build and review account before uploading another version.

2.1(a): a complete, accessible app

Test the submitted build from a fresh installation. Check its backend, working URLs, final text, and login instructions. Provide a usable demo account when sign-in is required. If legal or security obligations prevent that, Apple’s alternative is a fully representative demo mode with its prior approval; don’t quietly substitute a restricted preview.

2.1(b): purchases the reviewer can find

Check each configured in-app purchase in the review environment. It needs to be complete and functional. If a configured item can’t be found or reviewed, explain why in the review notes. Include the route through the app, account conditions, and any prerequisite needed to reach it.

Verify the correction

Use the reviewer’s device and operating-system details where available. Repeat the failing flow, including a fresh sign-in and purchase access. Explain what changed and whether it was the build, metadata, or access instructions. The detailed reproduction steps below can help narrow a problem that doesn’t occur on your own phone.

The app works on your phone. Apple’s screenshot shows a blank screen, a crash, or a flow you can’t reproduce. Your saved session may be hiding a first-use problem, so we’d start by matching the reviewer’s starting point.

Guideline 2.1 covers a complete, working submission, including access to its features and purchases. Read the message itself before treating every 2.1 notice as a crash report. Apple may be asking for information it needs to continue.

Keep a record of the failing attempt

Save the message, screenshot, device and OS details Apple supplied, version, and build number. Then fill in this worksheet from a fresh test:

Check	Record what happened
Installed build	The exact submitted build, rather than a newer development copy
Starting state	Signed out, empty storage, and permission choices
Account	The reviewer account’s role, data, and paid access
Device	The reported model and OS, where available; otherwise note the difference
Backend	Whether the submitted app reaches the intended server and receives usable responses
Last successful action	The tap before the failure and the expected next screen

Try both a fresh account and the supplied review account. A developer account with months of data isn’t a good stand-in for either.

Follow the failure to the right place

A sign-in failure belongs in the review access check. A blank purchase screen needs a check of the product identifiers, configuration, and purchase review submission.

For a blank content screen, inspect the request and response on your backend. Look for an empty response, a missing account role, a region restriction, or a server that was unavailable during review. Show a useful empty state when there’s legitimately no data.

For a crash, gather the crash report and reproduce the failing action on the reported device or the closest available test device. Check permission denial and interrupted network requests too. Record what you couldn’t reproduce instead of presenting a different device test as an exact match.

Send back the fix or the missing information

If Apple asked a question, answer it directly through App Review messages. Include steps, access details in the designated private fields, and supporting screenshots where useful.

If app code changed, test the complete flow in the replacement build. If you fixed a backend or account issue, repeat the test with the submitted build and explain the correction. Our console-or-build guide helps separate those cases.

Finally, check every unresolved submission item. A reply and a saved fix don’t necessarily put the submission back in review.