A Guideline 2.1 rejection means App Review could not evaluate a complete, working submission. Find the observed failure before changing anything: crash, blocked access, unfinished content, unavailable service, or missing information.
The short version
- A Guideline 2.
- Treat 2.1 as a family, not a diagnosis. The reviewer message, device details, screenshot, and failed step identify the branch.
- Copy the exact symptom from Apple’s message.
- Do not promise approval; give App Review a testable path.
Turn Guideline 2.1 into an observable failure
Guideline 2.1 is an umbrella for an app App Review could not evaluate as complete. Convert Apple’s wording into one failed action: launch, sign-in, content load, purchase display, navigation, or access to a documented feature.
Capture the submitted build number, Apple’s device and OS, the supplied review account, and the first step where expected and observed results diverge. If the message omits that step, ask for it instead of selecting a familiar 2.1 fix.
Reproduce the incomplete path from a clean state
Reinstall the reviewed build and follow the Review Notes literally. Then repeat with no cached session, no seeded data, denied permissions, and a failed network request. Stop when one branch reproduces the reviewer-visible symptom.
- Copy the exact symptom from Apple’s message.
- Reproduce it on the submitted build from a clean state.
- Check login, network, empty data, permissions, and purchases.
- Decide whether the fix changes code, remote state, or review information.
- Reply with the shortest path that proves the fix.
For this case, evidence means the clean-install steps, account state, service state, and a pass/fail result for each branch. A generic screen recording is less useful than a short trace that begins before the failed action.
Choose the 2.1 correction surface
Change the binary for crashes, broken controls, unsafe loading states, or bundled placeholders. Correct App Review Information for access or navigation instructions. Reuse a build after a remote recovery only after proving its existing failure state remains usable.
| Situation | Next action | New build? |
|---|---|---|
| Crash or freeze | Fix the binary and retest | Yes |
| Expired demo account | Repair credentials and review notes | Usually no |
| Backend outage | Restore service; rebuild only if failure handling is broken | Depends |
| Placeholder inside the app | Remove or finish it | Yes |
| Missing explanation for a hidden path | Add exact review instructions | Usually no |
Use the 2.1 matrix only after reproducing the named action; an access-note correction and a runtime correction do not travel through the same submission path.
Translate the message into a symptom
The phrase after the guideline number is the useful part. Record the exact screen, action, device, OS, and account state. If Apple supplied only a broad statement, ask which step prevented review.
Do not assume that every 2.1 case needs the same template. A login credential and a launch crash share a guideline but require different evidence.
Run a clean-state reproduction
Install the submitted build without cached data. Use the review account exactly as entered in App Store Connect. Test first launch, empty states, weak network, permissions, login, purchase loading, and any non-obvious feature named in Review Notes.
The objective is to reproduce the reviewer’s path, not prove that your normal development account works.
Choose the fix surface
If behavior or bundled content changes, upload a new build. If only credentials, reviewer instructions, or a recovered remote service change, the existing build may be reusable. Retest before choosing.
A recovered backend is safe with the same build only when the app already handles future failures without crashing or hanging indefinitely.
Write a verifiable 2.1 reply
State what failed, what changed, whether a new build is attached, and the exact steps to verify. Include working credentials in the App Review Information fields and in the reply when appropriate.
Avoid a generic claim that the issue is fixed. Name the screen and expected result.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the fix guideline 2 1 symptom from unrelated issues.
After classifying this fix guideline 2 1 case, use the post-rejection workflow to sequence the App Store Connect actions.
Branch the diagnosis by first failed action
A launch failure belongs to crash analysis. A successful launch followed by an empty or temporary screen points toward bundled or remote content. A login failure starts with credentials, account state, and authentication dependencies. A feature Apple cannot locate starts with Review Notes and navigation before code.
Do not test every possibility at once. Hold the submitted build and account constant, reproduce the named action, then vary one condition. This gives you a cause you can defend rather than a generic completeness checklist.
Test the boundary between app and service
Record loading, success, empty, authentication failure, timeout, and server-error states for the rejected path. The app should remain understandable and navigable when a service fails. Restoring an endpoint resolves only the incident; it does not prove that the client handles the next incident.
If content is remote, test what a newly created account receives in the production environment. Founder accounts often hide missing onboarding, migrations, or seed data. If content is bundled, inspect the release archive rather than a debug resource set.
Before writing the note, repeat the full route once with the exact account and selected release artifact. Confirm that no feature flag, employee entitlement, cached session, or local service makes your successful run different from the path available to App Review. Record the final expected state in plain product language.
Prepare a 2.1 verification note
State the failed action, what changed, the build under review, and numbered steps from launch to the corrected state. Name visible labels and the expected result. Put stable credentials and special configuration in the appropriate App Review Information fields.
Use the reply framework for wording. If Apple’s message contains several symptoms, return to the rejection-reason map and split them into separate fixes.
Run the final route with a person who did not implement the fix. Give them only the credentials and notes intended for App Review, then watch where they hesitate. A path that works only with developer knowledge is still incomplete for review. Record the first failed or ambiguous step and correct that boundary before uploading another build or claiming the issue is resolved.
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, 2.1 App Completeness, Reply to App Review messages. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026. Recheck the current wording of 2.1 before classifying a completeness symptom.
FAQ about Guideline 2.1 App Completeness
What does Guideline 2.1 cover?
Apple describes app completeness in terms that include crashes, placeholder content, incomplete information, and inaccessible review paths.
Can I reply without uploading a build?
Yes, when the binary is unchanged and the issue was access, instructions, or another external condition that is now corrected.
Should I test only the screen Apple named?
Start there, then retest the full path needed to reach it from a clean installation.
What if I cannot reproduce the issue?
Ask for the complete crash log, screenshot, device details, or exact step. Do not invent a cause.
Conclusion
Turn 2.1 into one failed action, reproduce it on the selected build, correct the responsible surface, and give Apple steps that end at the repaired state.
Sources and references
- App Review Guidelines, 2.1 App Completeness (accessed 2026-08-04)
- Reply to App Review messages (accessed 2026-08-04)