Free checklist
Before you hit Submit
This is the list I run before sending any app to Apple. Every item here comes from a real submission, and most of them come from a rejection I had to fix. Work top to bottom and tick as you go.
1. The build itself
- The version number in the build matches the version record in App Store Connect. If the record says 1.0.1 and the build says 1.0, the upload is rejected as an invalid binary before a human ever sees it.
- Build number is higher than every build you have ever uploaded for this app. You cannot reuse one, even from a build you deleted.
- Debug menus, test toggles and QA shortcuts are stripped from the build you submit. Keep them in your internal and TestFlight builds. Apple rejects hidden or test-only features in a review build, even ones behind a gate.
- No placeholder text, lorem ipsum or "coming soon" screens anywhere a reviewer can reach.
- Every link in the app opens something real. Dead links are a rejection.
- The app runs on the newest iOS on a real device, not just the simulator.
- Encryption question answered. If you only use standard HTTPS, set the exemption flag so the build does not sit waiting on a compliance question.
2. Privacy
- Your privacy labels match what the app actually does, in both directions. Under-declaring gets you rejected. Over-declaring scares off downloads and is just as wrong.
- Check what every third-party kit collects, not just your own code. An ads or analytics kit collects data on your behalf and must appear in your labels. An ad kit I shipped collected a device advertising identifier I had not declared, and the build was rejected for it.
- Privacy manifest included for your app and its third-party kits, listing data types and the reasons you use protected APIs.
- A real privacy policy at a public URL that matches the labels. Not a draft, not a page behind a login.
- If you track users across apps, you ask permission first, with a clear explanation, and the app works if they say no.
- If you collect anything, say how someone deletes it, and make sure that path actually works.
3. Account and sign-in
- If sign-in is not required, write "no account required" in the review notes. This alone saves days.
- If sign-in is required, give a working demo account with a username and password in the review notes, and test it the day you submit.
- If you offer third-party sign-in, you also offer a private option where Apple requires it.
- If people can create an account in your app, they can delete it from inside the app too. A support email is not enough.
4. Money
- Anything digital that your app unlocks is sold through Apple's in-app purchase. Unlocking paid content with a code, a coupon or an outside payment is a rejection. I lost a build to exactly that.
- Restore Purchases is reachable without signing in and works on a fresh install.
- You tested a real sandbox purchase and a restore on a device, not just in the simulator.
- Prices, trial length and what the purchase unlocks are stated on the screen that asks for money, and they match what the store shows.
- Paying users never see the paywall or ads again, including after a reinstall.
- Your in-app purchases are submitted too. They are reviewed separately from the app, and a new one has to go in with a build.
5. Content and safety
- If users can post anything others see, you have all four: a way to report content, a way to block people, a filter for the obvious, and a stated response time. Missing any of them is a rejection, and chat counts as user content.
- Your age rating answers are honest, including the questions about violence, gambling and alcohol.
- If the app has a chat or messaging feature, it is declared in the age rating questionnaire. I had a build rejected for a chat that the questionnaire did not mention.
- No medical, legal or financial claims you cannot back up.
6. The store listing
- Screenshots show the real app. Mock-ups of features that do not exist are a rejection.
- No prices and no "free" written on a screenshot. Prices change by country and Apple rejects them in images.
- Screenshots have no transparency. An image with an alpha channel is rejected on upload.
- Your description does not name another platform. "Also on Android" gets rejected.
- The app name and subtitle do not use words you have no right to, including other companies' trademarks.
- Keywords are comma separated with no spaces, so you do not waste characters.
- Support URL works and the email on it is one you read.
- What's New says what actually changed in this build.
7. Before you press the button
- Install the exact build you are submitting on a device that has never run the app, and go through it as a brand new user.
- Turn the network off and open the app. It should explain itself, not crash or hang.
- Review notes written: what the app does, how to reach anything hidden behind a step, the demo account if there is one, and anything a reviewer might not find on their own.
- Decide how it releases. Automatic on approval, or held so you release it yourself.
- Know that rejection is normal. You fix the thing they name, reply in Resolution Center, and resubmit. It is a conversation, not a verdict.
Get the next one first
New episode, new checklist, nothing else. Unsubscribe any time.
Want the full walkthrough?
This checklist is the last mile. Zero to Shipped covers everything before it, from picking an idea to the day your app goes live.