Our internal pre-submission checklist. ~95% first-try approval rate on ~120 submissions. Rejections are rarely technical — they're policy.
App Store rejection is not random. After shipping roughly 120 iOS apps across a decade, our first-try approval rate sits around 95 percent. The 5 percent that bounce bounce for the same three or four reasons every time.
Here's the pre-submission checklist our senior iOS engineers actually run.
App Store Review doesn't care about your code. They care about your policy posture. Rejections aren't about crashes or bugs — they're about screens, copy, metadata, and how your app looks to a non-technical reviewer opening it for the first time with a standard iPhone account.
We've internalized this. Every checklist item below is about the reviewer's experience, not the engineering experience.
Reviewers will not sign up for your service. They will not figure out your onboarding. If your app has any auth gate at all, you must ship a demo account credential in App Store Connect's Review Notes.
We test the demo account from a freshly-wiped device, following the exact path the reviewer will follow. If the demo account hits any edge case — expired session, email verification required, phone-number OTP — that's a rejection.
This catches roughly a third of the rejections we've investigated for clients who came to us mid-submission-hell.
We regenerate screenshots from the exact build we're submitting. Always. Even if it costs a designer half a day.
As of iOS 17, every SDK and your own code must declare what it collects and why. If you declare "no analytics" and you ship Firebase, that's a rejection.
Our checklist:
PrivacyInfo.xcprivacyIf your app offers Google, Facebook, or email login, Apple requires "Sign in with Apple" as a peer option. This is a one-line Info.plist change plus a Cognito configuration change, but teams miss it constantly.
If your app sells digital content or services, it must use Apple's in-app purchase system. If it sells physical goods or services rendered outside the app, external payment is fine.
The boundary is blurry — is a subscription-to-a-web-dashboard digital or physical? Our default posture is to offer IAP as a peer option and let the user choose, which satisfies the policy without hurting conversion.
The reviewer opens your app cold. They don't know what your product does. The first screen they see needs to:
We build our onboarding screens specifically for this first-encounter test, not for the already-converted user. The reviewer is not your user.
When App Review has a question, they'll send a message. If you respond within two hours, you often get approved same-day. If you respond in two days, you're back in the queue.
We set up a dedicated Slack channel for every active client submission and monitor for Review Resolution Center messages. Most of the time it's a clarification question, not a blocking rejection.
Of the 5 percent that bounce on first try, the most common reasons (in order):
None of these are engineering problems. They're process problems, and the process is: have a senior iOS engineer run through the checklist with the actual build, on a real device, pretending to be a reviewer, one business day before submission.
That day of discipline is worth two weeks of resubmission cycles.
This checklist is part of what we hand to clients at project close. If you want it for your own team, come to a Lehi strategy session — we'll walk through your app and tell you what will bounce before Apple does.
# keep-reading
Deterministic code beats LLM calls on cost, latency, and reliability for most 'AI' use cases. Here's how we decide which 20% stays.
The specific Lambda, Cognito, and observability patterns we carry from project to project — and the ones we throw away every time.
$ ready to start
30 minutes. You leave with a scoped MVP plan, a fixed-price quote, and an AWS architecture sketch.