The App Store Submission Checklist
An App Store submission checklist is the set of things that must be in place before Apple will approve an iOS app: an active Developer Program membership and signed agreements, a correctly signed release build with an incremented version, a complete App Store Connect listing with screenshots for every required device size, honest answers to the privacy, age rating and export compliance questionnaires, a reachable privacy policy, and a working demo account if anything sits behind a login. Roughly 22% of submissions were rejected in 2025 and over 40% of first submissions bounce — almost always on one of these items rather than on the quality of the app itself. Work top to bottom; each group is roughly the order you hit it.
By the AscAuto team — engineers who automate App Store submissions and rejection fixes daily. · Last updated: July 2026
Account and agreements
- Apple Developer Program membership is active — 99 USD/year, and an expired membership blocks submission entirely.
- Paid Applications agreement signed — required before a paid app or any in-app purchase can go live, and easy to forget on a first release.
- Tax and banking details completed — same trigger: no money can be collected without them.
- App Store Connect API key (.p8) created — needed for any automation; use the key, never your Apple ID password.
- App record created with the final bundle ID — the bundle identifier cannot be changed after the first submission.
The build
- Release configuration, not debug — no logging spam, no test menus, no staging endpoints.
- Version and build number higher than anything uploaded before — App Store Connect silently refuses duplicates.
- Valid distribution certificate and provisioning profile — and not one expiring in the next few weeks.
- No crash on launch, on a real device, on a current iOS version — the fastest route to a Guideline 2.1 rejection.
- No placeholder content, lorem ipsum or dead links — reviewers do open the links.
- Every advertised feature actually works offline of your dev environment — including anything region-locked.
Listing metadata
- App name and subtitle within Apple's character limits — and not stuffed with competitor names or keywords.
- Description matches what the app does — claims of features that do not exist are Guideline 2.3.10.
- Keywords field used properly — comma-separated, no repetition of the app name, no rival brands.
- Support URL that resolves and looks maintained — a 404 here is a rejection.
- Privacy policy URL, publicly reachable without a login — required for every app, no exceptions.
- Category and age rating chosen honestly — misfit categories get flagged.
- What's New filled in for updates — "bug fixes" alone is accepted but wastes a conversion surface.
Screenshots and previews
- Screenshots for every required device size — missing sizes block the submission form itself.
- Taken from the build you are submitting — stale screenshots are Guideline 2.3.3, one of the most common rejections.
- No UI that does not exist in the app — including concept art and mocked-up dashboards.
- Text legible at thumbnail size — not a review requirement, but it is where most installs are won or lost.
- App preview video follows Apple's format rules — if you ship one at all; it is optional.
Privacy and compliance questionnaires
- Privacy nutrition labels match every SDK you ship — analytics, ads and crash reporters collect more than most teams declare. This is Guideline 5.1.1 territory.
- ATT prompt implemented if you track across apps — declaring tracking without the prompt is an automatic rejection.
- Account deletion available in-app if accounts can be created — a hard requirement, not a nice-to-have.
- Export compliance answered — standard HTTPS usually qualifies for the exemption, but the question still has to be answered.
- Content rights declared — third-party content needs permission you can show.
- EU trader status (DSA) declared where it applies — missing this blocks EU availability.
- In-app purchases created and submitted with the version — purchases reviewed separately from the binary are a classic Guideline 3.1.1 miss.
What the reviewer needs
- Demo account with working credentials — if any part of the app requires a login. Test them the day you submit.
- Review notes explaining anything non-obvious — hardware requirements, region locks, how to reach a hidden flow.
- Contact details a reviewer can actually use — an unmonitored inbox turns a question into a rejection.
- Backend and staging accounts alive during review — reviews happen at odd hours in other time zones.
Submit — and plan for the reply
- Pricing and availability set — including whether you want a manual or automatic release after approval.
- Version moved to Waiting for Review — most reviews land within 24 to 48 hours.
- Someone is watching for Apple's response — rejections and information requests arrive by email and stall until answered.
- Plan is to fix and resubmit, not appeal — around 85% of appeals are denied; resubmission is nearly always faster.
Automating the checklist
Nearly every item above is machine-checkable, which is what AscAuto does before you submit: it reads your App Store Connect record, reports what is missing against these requirements, drafts the gaps — listing fields, questionnaire answers, screenshots — and waits for your approval on each. Submitting for review is one click, and if Apple comes back with a rejection or a question, it classifies the guideline, drafts the reviewer reply or a code fix as a pull request, and resubmits once you approve. Connect a repository and it will also build in the cloud and push to TestFlight, with no Mac needed on your side.
FAQ
What is required to submit an app to the App Store?
An active Apple Developer Program membership, a signed release build with a unique bundle ID and incremented version, a complete listing with screenshots for every required device size, answers to the privacy, age rating and export compliance questionnaires, a reachable privacy policy URL, and a working demo account if the app has a login.
What is the most common reason apps are rejected?
Guideline 2.1, App Completeness — usually because the reviewer could not use the app: a missing or broken demo account, a crash on launch, or placeholder content. Privacy (5.1.1) is second.
Do I need a demo account for App Store review?
Yes, if any part of your app is behind a login. The credentials must work at the moment of review and reach the same functionality a normal user gets.
How long does App Store review take?
Apple reports most submissions are reviewed within 24 to 48 hours. A rejection restarts that clock after you resubmit, which is why the checklist is worth the hour.
Can this checklist be automated?
Most of it. AscAuto checks your App Store Connect record against these requirements, drafts what is missing for your approval, submits with one click, and handles Apple's response if the app is rejected.