App Store Rejection Checklist: 12 Checks Before You Submit

Updated August 31, 2026 · by Sardorbek Rakhimov

In 2025, Apple reviewed 9,100,620 App Store submissions and rejected 2,093,244 of them — about 23%, per Apple's own App Store Transparency Report. Apple also says 90% of submissions are reviewed in less than 24 hours. If a submission does not pass, you may need to answer App Review, change the build or metadata, and submit again. The added time depends on the issue and the next review.

This checklist focuses on metadata, completeness, and configuration issues you can check before submission. It cannot guarantee approval, but it can help you send App Review a more complete record. The relevant App Review Guidelines are noted where they apply.

Metadata and listing

  1. 1. Field limits and truncation

    App name (30 characters), subtitle (30), promotional text (170), description (4,000), and the keyword field (100) all have hard limits — and per-locale violations are easy to miss when a translation runs long. Over-limit fields fail before review even starts; marketing claims that don't match the app violate Guideline 2.3 (Accurate Metadata).
  2. 2. Screenshots that match the current app

    Screenshots must show the app as it actually looks in this version and match the corresponding device type (Guideline 2.3.3). Check every localized screenshot set you provide, and make sure all required device assets are present.
  3. 3. Live, reachable URLs

    The support URL and privacy policy URL must resolve — App Review opens them (Guidelines 1.5 and 5.1.1). A parked domain, a 404, or a staging link that needs a VPN reads as an incomplete product.
  4. 4. Keyword hygiene

    Use only relevant terms, avoid competitor trademarks, and remove unnecessary repeats (Guideline 2.3.7). Apple limits the keyword field to 100 characters, so each repeated term leaves less room for another relevant term. See the keyword field guide.

Build and configuration

  1. 5. A processed build is actually attached

    The version you're submitting needs a build that has finished processing, with the right version string and no missing-compliance state. "I uploaded it" and "it is attached to this version" are different facts — verify the second one.
  2. 6. Export compliance declared

    The encryption/export-compliance question must be answered for the build. Undeclared compliance leaves the submission stuck before review.
  3. 7. Age rating answered honestly

    The age-rating questionnaire has to reflect what's really in the app — user-generated content, web access, gambling mechanics (Guideline 2.3.6). An inaccurate answer can lead to an inappropriate rating or a review issue.
  4. 8. In-app purchases ready for review

    Apple's current submission rules require the first consumable, non-consumable, auto-renewable subscription, and non-renewing subscription of each type to be submitted with a new app version. After the first item of a type is approved, additional items of that type can be submitted separately when the app already has an approved version. Every item still needs its required metadata and review information. An app that sells something App Review cannot access may not pass Guideline 2.1.

Completeness and account state

  1. 9. Demo account and review notes

    If any part of the app is behind a login, hardware, or region gate, App Review needs a working demo account and notes explaining how to reach the gated flows. Apple says over 40% of unresolved review issues relate to Guideline 2.1 (App Completeness), which includes incomplete review information.
  2. 10. No placeholder content

    Lorem ipsum, empty states that never fill, "coming soon" screens, dead buttons — all read as an unfinished app (Guideline 2.1). Ship the cut feature in v1.1 instead of shipping its stub.
  3. 11. Privacy labels and policy agree with each other

    Your privacy nutrition labels, your privacy policy, and what the binary actually does must tell the same story (Guidelines 5.1.1–5.1.2). A policy that admits analytics while the labels claim "no data collected" is an easy flag.
  4. 12. Agreements, banking, and tax are current

    A paid app or IAP can't go live while the Paid Apps Agreement is unsigned or expired, or banking and tax setup is incomplete. This is an account-state hold, not an App Review rejection. The full dependency chain is in our Apple Developer account setup guide.

Rule of thumb: App Review checks your app and its App Store Connect record. Many items here concern metadata, configuration, review information, or account state rather than the binary, so check both before submitting.

Automating this checklist

You can check these items by hand, but the work becomes repetitive across locales and releases. ShipZen, a native macOS client for App Store Connect, runs them as a pre-submission validator: field limits per locale, URL liveness, screenshot completeness, build and export-compliance state, age-rating and IAP readiness signals, and Paid Apps Agreement detection — before you ever hit submit. The validator itself is free; AI-assisted fixes draw on the free tier's 15 AI requests a month. Metadata changes and AI writes use ShipZen's documented confirmation flow; the security and capability page explains which direct manual actions apply immediately.

If you're publishing your first app, the account setup steps come first. See the Apple Developer account setup guide for enrollment, D-U-N-S, agreements, tax, banking, and the first app record. For what a desktop client changes about the day-to-day workflow, read what an App Store Connect desktop client does.

Sources rechecked August 31, 2026. See the editorial policy for sourcing and corrections.

Catch common submission issues early. ShipZen is in public beta on TestFlight.

Join the waitlist