Pre-Submission Checklist

A reviewer installs your build on real hardware and uses it like a suspicious customer. They log in with your demo account, tap through purchase flows, hit your empty states, and compare what they see against your screenshots and description. Anything they cannot access gets rejected under guideline 2.1 (App Completeness) — one of the most cited rejection reasons — which is why the demo account deserves more care than almost any other checklist item: it must work, must not require an SMS code the reviewer can’t receive, and must contain enough data to show the app’s value.

Beyond functionality, reviewers verify consistency across surfaces: your privacy nutrition label versus observed network behavior, your age rating versus your content, your screenshots versus the running UI, your listed features versus what actually works. Inconsistency reads as either sloppiness or deception, and both get the same result. The checklist mirrors this cross-checking so you catch contradictions before Apple does.

The recurring offenders are the quiet ones: the support URL that 404s because marketing restructured the website; export compliance answers left for the last minute; sign-in-required apps missing Sign in with Apple when they offer only third-party logins; account-based apps missing the in-app account deletion Apple has required since 2022; and background modes or permissions declared in the build that the app never visibly uses, prompting “why does your app need this?” questions.

In-app purchases have their own trap: IAP products must be submitted for review with the binary that uses them, each with its own review screenshot and localized metadata. A perfect app with unsubmitted IAPs gets approved into a broken paywall — or rejected outright. If your release includes new purchases, treat their review status as a launch blocker equal to the build itself.