← Journal· Mobile · Aug 7, 2026 · 3 min read

App store submission checklist: how to pass review the first time

The build is done, the features work, and review still sends it back. Here is the checklist we run before every submission, and the three rejections that cause most of the delay.

Almost every app store rejection we have dealt with had nothing to do with the code. The build worked. The features were done. What was missing was a demo account, a privacy answer, or a support URL that did not resolve. Teams treat submission as the last hour of the project, then lose a week to a review queue over something that would have taken ten minutes to prepare.

So we stopped treating it as paperwork. Submission is a deliverable with its own checklist, the same way a database migration is. It is not interesting work, but it is the difference between launching on the day you promised and explaining a delay to a client who does not much care whose fault it was.

The rejections that actually happen

The most common one is incomplete information. A reviewer opens the app, hits a login wall, has no working credentials, cannot see anything, and rejects it. Give them a demo account that does not expire, does not hit a rate limit, and holds realistic data. If part of the app only makes sense in a particular state, like a booking that is already confirmed, seed that state on the demo account before you submit and say so in the review notes.

The second is a mismatch between what you declare about privacy and what the app does. Data collection answers, tracking, and account deletion all get checked, and account deletion catches teams out most. If someone can create an account inside the app, they have to be able to delete it inside the app too. A support address that invites them to write in does not count.

The third is minimum functionality. A thin wrapper around a website, or an app that is really a brochure, gets turned down for not being enough of an app. This one is worth catching while you are still scoping, because the fix is product work rather than paperwork, and nobody wants to discover it the week of launch.

What we prepare before we hit submit

A demo account with realistic data, no expiry, and review notes explaining anything non obvious.
In app account deletion, tested on a real device rather than signed off from the design.
Privacy answers that match what the app actually sends, including whatever your SDKs send for you.
Support, privacy policy and marketing URLs that all resolve on the live domain before submission.
Screenshots at every required size, taken from the build you are submitting and not an older one.

The SDK line is the one that quietly breaks things. Analytics, crash reporting and ad libraries collect data on your behalf, and the privacy declarations are about what leaves the device, not about what your own code wrote. We read what each dependency collects before filling that section in, because an inaccurate privacy answer is not the kind of rejection you can argue your way out of.

Leave the queue some room as well. Review often comes back within a day, but that is a pattern and not a promise, and holidays stretch it. When a launch date is tied to an event or a campaign, we submit several days early and hold the release with scheduling instead of racing the queue. Approved and waiting is a far better position than submitted and hoping.

Submission is not a formality at the end of a build. It is a small product of its own, and it deserves a slot in the plan.

None of this is hard. It is just easy to leave until everyone is tired and the build has finally gone green. Put the checklist in the sprint before the one you intend to launch in, walk it once on a real device with fresh eyes, and the review queue stops being the thing that decides your launch date.