Skip to content

App Store Completeness Guide

If your app is being rejected, at risk of rejection, or you are preparing a submission, this page helps you decide whether the problem is a completeness issue — or something else.

This is the entry point for diagnosing App Store review failures related to build readiness, reviewer access, and missing or broken flows.

Quick classification

Start here depending on your current situation:

  • Your app was rejected under Guideline 2.1 -> go to Guideline 2.1 Rejection
  • Your app crashes, fails to load, or has broken flows -> continue below (likely completeness issue)
  • Your issue is metadata, description, or listing mismatch -> go to Apple Metadata Guide
  • Your issue is policy, spam, or design enforcement -> go to Design & Spam Guide
  • Your issue is privacy or data handling -> go to Privacy & Data Guide

If you are not sure which category applies, continue below to evaluate completeness risk.

What This Guide Covers

Use this page to check:

  • whether the reviewer can actually access the critical product path
  • whether demo account, environment, and runtime dependencies are stable
  • whether placeholder, broken, or region-blocked flows are still present
  • whether the current build should proceed to review at all

Start Here If

  • you have not submitted yet
  • you are preparing a resubmission and want to prevent another 2.1
  • you need a pre-submit completeness check rather than a rejection response page

1. Technical Stability: The "Binary Quality" Gate

Apps that crash immediately, fail to load core content, or have broken primary navigation are rejected under Guideline 2.1. Apple views technical stability as a prerequisite for any further policy review.

Common Failure Points:

  • Crash On Launch: The most critical 2.1 trigger. This often happens because the app attempts to fetch data from a production server that isn't yet active or uses a hardcoded configuration that fails in the reviewer's specific environment (e.g., IPv6-only networks).
  • Broken Backend Dependencies: If your app relies on a third-party API or a CMS, ensure those services are robust and accessible to the reviewer. A "Network Error" on the main screen is an automatic 2.1 failure.
  • Incomplete Feature Implementation: Buttons that do nothing or "Coming Soon" placeholders signal that the app is not a "finished product."

2. Reviewer Access: The "Demo Account" Discipline

If your app requires a login, you MUST provide a functional, non-expiring demo account in the "App Review Information" section of App Store Connect.

Demo Account Best Practices:

  • Demo Account Invalid: Avoid accounts that require 2FA (SMS) that the reviewer cannot bypass. If 2FA is mandatory, provide a "Magic Code" or a specific test path for the reviewer.
  • Data-Rich States: The demo account should contain representative data. An empty "Profile" or "Dashboard" makes it difficult for the reviewer to assess the app's utility.
  • Social Login Hardening: If using Sign in with Apple, Google, or Facebook, ensure the reviewer has a way to bypass the real personal phone number requirement if possible, or provide clear instructions on how to proceed.

3. Metadata, Placeholders & Accurate Description

Guideline 2.1 also covers the "Listing Package"—everything the user sees before they download the app.

  • Placeholder UI: Remove all "Lorem Ipsum" text, stock photos with watermarks, or "Example Content" before submission.
  • Review Notes Precision: Use the "App Review Notes" field to describe complex workflows. If your app requires specific hardware (e.g., a Bluetooth health monitor), you should provide a video showing the app interacting with the hardware if you cannot ship the hardware to Apple.
  • Support & Privacy Links: Ensure the URLs for Support and Privacy Policy are active. A 404 on the Privacy Policy link is a common cause for 2.1 rejections.

Before you submit or resubmit, you need to decide whether this build is actually reviewable — not just functional.

This section helps you determine whether the current version should proceed to review or be held back for fixes.

4. Submission Gate

Before submission or resubmission, confirm whether the current build is reviewable without extra explanation.

Reviewability check

  1. Confirm the main user path works on a clean install.
  2. Confirm reviewer credentials and dependencies are ready before submission.
  3. Confirm no placeholder, broken, or region-blocked path is still part of the critical flow.

5. Performance Hardening Checklist

Before hitting "Submit," run through this final Guideline 2.1 audit: - [ ] App launches in under 10 seconds on older supported hardware (e.g., iPhone 11). - [ ] Demo account credentials have been verified on a clean install. - [ ] All "Placeholder" text has been replaced with production copy. - [ ] Server-side endpoints are set to "Production" or a stable "Review" environment. - [ ] IPv6 compatibility has been tested (Apple's review network is strictly IPv6).

6. Advanced Pre-Submit Checks

Some apps face extra completeness risk because reviewer access depends on region, hardware, or backend state.

Regional Availability

If your app is only available in certain regions, make sure the review path still exposes a valid, testable flow.

Hardware Dependencies

If your app depends on external hardware, confirm the review path explains and supports that dependency clearly before submission.

Backend Dependency Mapping

If functionality depends on server-side flags or seeded data, verify the reviewer path uses a stable environment with the expected state already enabled.

If You Are Still Unsure

Most App Store rejections are not isolated issues — they are misclassified problems.

Use these pages to narrow down your situation:

This page is designed to help you classify the problem before you attempt a resubmission.

Back to: Apple App Store Hub