Shipzen
App Store Rejection Checklist: 12 Checks Before You Submit
Updated July 8, 2026 · by the Shipzen team
In 2024, Apple reviewed 7,771,599 App Store submissions and rejected 1,931,400 of them — about one in four, per Apple's own App Store Transparency Report. Apple also says 90% of submissions are reviewed within 24 hours — which cuts both ways: a clean submission ships fast, but every rejection restarts the clock, and a back-and-forth over a missing screenshot can stretch a same-day release into a week.
The frustrating part is that a large share of rejections are preventable: they come from metadata, completeness, and configuration problems that a careful pass over your App Store Connect record would have caught. That pass is this checklist. It is organized the way App Review actually evaluates your submission, with the relevant App Review Guidelines noted where they apply.
Metadata and listing
-
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. Screenshots that match the current app
Screenshots must show the app as it actually looks in this version, on the required device sizes, in every locale you ship (Guideline 2.3.3). Placeholder frames, outdated UI, or a missing iPad set on a universal app are classic silent blockers. -
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. Keyword hygiene
No competitor trademarks, no duplicated terms already covered by your name and subtitle, no irrelevant stuffing (Guideline 2.3.7). Duplicates don't just risk review friction — they waste the 100 characters that drive search ranking.
Build and configuration
-
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. -
6. Export compliance declared
The encryption/export-compliance question must be answered for the build. Undeclared compliance leaves the submission stuck before review. -
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). Understating it is a rejection; overstating it shrinks your audience. -
8. In-app purchases submitted with the build
New IAPs and subscriptions must be attached to the submission and be in a reviewable state, with their own display names, descriptions, and screenshots. An app that sells something App Review can't see fails Guideline 2.1.
Completeness and account state
-
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. Guideline 2.1 (App Completeness) is the single most common rejection Apple cites in its common-rejections guidance. -
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. -
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. -
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 one isn't even a review rejection — it's a silent hold that looks like one.
Rule of thumb: App Review checks your app and your App Store Connect record. Half of this list never touches your binary — it's metadata, configuration, and account state. That's exactly the half you can verify in minutes before submitting instead of losing a day to a rejection.
Automating this checklist
Everything above is mechanical enough to check by hand — once, for one app, in one locale. Across locales and releases it stops being practical, which is why Shipzen, a native macOS client for App Store Connect, runs these checks 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 locale and keyword scanner is free, and every AI-assisted fix shows a diff before anything is written to Apple.
If you're publishing your first app, the setup steps (D-U-N-S number, Developer Program, banking, Bundle IDs) come before any of this — see the first-time submitter guide on the homepage. For what a desktop client changes about the day-to-day workflow, read what an App Store Connect desktop client does.
Catch rejections before Apple does. Shipzen is in final development for the Mac App Store.
Join the waitlist