Skip to content

Guideline 2.1 Rejection

This is the concrete rejection page for Guideline 2.1.

Use it when Apple has already cited app completeness, reviewability, or verification failure in App Review.

If you are still checking whether the next build is ready before submission, use the App Store Completeness Guide first.

What This Page Covers

Use this page when you need to determine:

  • what Apple could not verify in the submitted build
  • whether the blocker was runtime, access, placeholder content, or environment setup
  • what must be fixed before resubmission
  • which related pages to open next

Distinctions

Use this taxonomy when diagnosing a 2.1 rejection. Similar symptoms produce different remediation requirements.

Condition What Reviewer Sees Typical 2.1 Interpretation Required Fix Before Resubmission
Crash or technical failure Crash on launch, hard freeze, endless spinner, or obvious runtime bug on device. Binary is incomplete or unstable for review use. Ship a corrected build, verify on physical devices, and confirm backend dependencies are reachable from review regions.
Placeholder content "Coming soon" screens, empty feed where production content is expected, temporary URLs, test copy in user-facing flow. Submission is not final; temporary materials were not scrubbed. Replace placeholders with production content or approved demo equivalents that reflect final behavior.
Non-functional flows Buttons do nothing, navigation path breaks, payment path cannot complete, deep link fails, required API returns error. Critical path is incomplete even if other areas work. Repair each broken path and provide exact reproduction steps in Review Notes for high-risk flows.
Hidden required login barrier App requires authentication but no credentials are supplied, credentials are invalid, or SSO path cannot be completed by reviewer. Reviewer cannot access core functionality; app is effectively untestable. Provide durable demo credentials, SSO test instructions, and all required account prerequisites in App Review information.
Region-restricted features without demo access Core features are geofenced, jurisdiction-gated, or entitlement-gated, and reviewer cannot reach a valid path from their test context. Feature set appears incomplete in review context. Document region constraints explicitly, provide a test path in an allowed region or demo mode, and align App Store availability settings with what can actually be reviewed.

The key distinction is between incidental defects and verification blockers. A minor cosmetic issue may survive review. A verification blocker typically triggers 2.1 because the reviewer cannot establish completeness.

Review Perspective

App Review evaluates observable behavior, not internal roadmaps. Two constraints dominate 2.1 outcomes:

  1. The reviewer cannot infer intent.
    If the app says a feature exists but execution fails, reviewers do not assume backend rollout lag, feature-flag drift, or environment mismatch. They log what they can reproduce.
  2. A failed feature path is treated as incompleteness.
    When a core route is unavailable, the reviewer does not classify it as "partially complete." They treat the submitted state as not ready for App Store distribution under 2.1 expectations.

This is why "it works in our staging environment" is low-value evidence. Reviewer context is governed by the submitted binary, App Review information, available credentials, declared availability, and live service reachability. Any mismatch between those elements is your submission defect, not reviewer ambiguity.

Escalation Pattern

Apple does not publish public scoring thresholds for escalation, but teams commonly see a predictable friction pattern when 2.1 defects repeat:

  1. Rejection.
    Initial 2.1 finding cites incompleteness in one or more paths.
  2. Same-build resubmission with limited evidence.
    If the same binary is resubmitted without materially improved access context, the reviewer often re-validates the same failing path.
  3. Friction increase.
    Clarification cycles lengthen. Review notes demand more specificity. Confidence in your internal QA signal drops.
  4. Cross-flag exposure.
    Repeated incompleteness can surface adjacent concerns, including design/functionality issues under 4.x or data/trust disclosures under 5.x, when the failure pattern overlaps those domains.

Treat repeated 2.1 outcomes as an account-level process failure. Even when the immediate citation remains 2.1, the practical risk surface expands if App Review observes recurring submission unreliability.

Boundary With 4.x and 5.x

Guideline 2.1 governs completeness at review time, but repeated defects can be recast as broader policy problems when the pattern looks systemic.

  1. Boundary with 4.2 (Minimum Functionality) If core routes are repeatedly inaccessible or non-operational, Apple may treat the app as lacking meaningful functional depth, not just failing one release cycle.
  2. Boundary with 4.3 (Spam) Portfolio risk increases when multiple similar apps show the same incomplete behavior profile. Repeated non-reviewable variants can be interpreted as low-substance replication under 4.3.
  3. Boundary with 5.1 (Data and Privacy) If data-dependent flows stay blocked behind failing gates, reviewers may be unable to validate consent, disclosure, or data handling paths. The issue then shifts from execution failure to data-governance visibility.

Operationally, repeated 2.1 outcomes are not isolated events; they can become signals of weak product substance (4.x) or weak privacy observability (5.x).

Evidence Submission Model

A strong 2.1 response is a compact, testable packet. It should let the reviewer complete verification without interpretation. Minimum model:

  1. Demo account Provide one or more non-expiring reviewer accounts that expose full intended feature depth for the submission scope. If role-dependent paths exist, include each role and expected result.
  2. Clear reproduction steps Give deterministic step-by-step paths from cold launch to key features, including branch conditions and expected outputs. Keep steps short and numbered.
  3. Test credentials Include username/password pairs, SSO instructions, OTP bypass setup when allowed, and any prerequisites (seed data, invitation state, tenant mapping).
  4. Server status validation Confirm the backend used for review is live, reachable, and loaded with valid test data at submission time. If maintenance windows exist, declare exact UTC windows and mitigation.

Do not bury this in generic narrative. Put it in App Review information and Review Notes in a format reviewers can execute quickly.

Backend Dependency Risk Model

Most recurring 2.1 failures are integration failures between submitted binary behavior and review-time backend conditions. Use this model before resubmission:

  1. Review environment vs production mismatch Risk: reviewer traffic is routed to a different config, seed state, identity provider, or API version than the one your team validated.
    Control: freeze the review-serving environment and re-run verification against that exact target.
  2. Feature flag drift Risk: remote flags diverge across QA, production, and reviewer cohorts, removing or mutating critical flows.
    Control: lock a review flag snapshot with owner sign-off and block submit if it cannot be reproduced.
  3. API dependency failures Risk: upstream latency, schema drift, or auth instability breaks review-critical endpoints.
    Control: enforce pre-submit health gates for hard dependencies.
  4. Region and IP restrictions Risk: geofencing, allowlists, CDN policy, or fraud controls block reviewer network origin.
    Control: pre-test from expected review regions and document deterministic fallback paths.
  5. Server uptime responsibility during review window Risk: backend downtime during active review makes an otherwise correct app appear incomplete.
    Control: treat review windows as high-availability periods with active monitoring and response.

This model frames 2.1 prevention as an operations discipline: binary correctness is necessary, but review-time service reliability determines what Apple can validate.

Resubmission Discipline

When rejected under 2.1, decide explicitly between same-build resubmission and new-build submission:

  1. Same build is only appropriate when the binary is correct and the failure was strictly review context: missing credentials, incomplete notes, disabled server, or environment misrouting.
  2. New build is required when any executable behavior is defective: crash, broken navigation, logic bug, unavailable feature path, or missing integrated content.

If you cannot prove the issue is context-only, submit a new build. Reusing the same binary after a runtime failure usually increases friction because the reviewer replays prior evidence.

Structured Resubmission Template

Use this format in Review Notes so the reviewer can execute a single deterministic path without interpretation.

Review Notes: Guideline 2.1 Resubmission

Build: [version] ([build number])
Primary Device Path:
1) Launch app on [device model, iOS version]
2) Tap: [tab/button name]
3) Navigate: [screen A] -> [screen B] -> [screen C]

Credentials:
- Username: [review account]
- Password: [review password]

Steps to Reproduce (critical flow):
1) From Home, open [feature]
2) Submit [input]
3) Confirm [action]

Expected Behavior:
- App returns [specific result]
- User sees [screen/state]

Region Constraints:
- Supported review regions: [list]
- If outside supported region, use: [demo mode / alternate test route]
- Any IP allowlist contact or note: [details]

Keep this template literal and concise. Ambiguous prose increases re-test variance and reduces review efficiency.

Pre-Submission Control Checklist

Use this gate before each App Review submission touching login, remote config, or region-dependent features:

  1. Verify all links and external URLs used in review paths are functional.
  2. Confirm no placeholder UI/copy exists in first-session or purchase-adjacent routes.
  3. Execute critical paths on physical devices with production-like network constraints.
  4. Validate login paths for all declared identity providers and demo accounts.
  5. Confirm region availability settings match where the reviewed features are usable.
  6. Ensure In-App Purchases in submission scope are discoverable and testable, or explained with precise reason and location in notes.
  7. Attach reproducible App Review steps and credentials in App Review information before pressing Submit.
  8. Recheck backend health and seed data immediately before submission.

This checklist is intentionally strict. Guideline 2.1 is mostly prevented by release discipline, not post-rejection messaging quality.

Official

Compare