We wrote earlier about what actually slows indie apps down on their way to the App Store — mostly everything around the code, not the code itself. This is the more concrete follow-up: the actual checklist that runs on every app between "the features work" and "we hit submit." None of it is exotic. All of it is easy to skip under deadline pressure, which is exactly when it matters most.
Device and OS coverage
"It works on my phone" covers exactly one screen size and one iOS version. Before submission, we run through the smallest supported screen (layouts break first at the edges), the current iOS version, and at least one version back — Apple's adoption curve means a meaningful slice of users aren't on the latest release the week you launch.
Dark mode and dynamic type
Every screen gets checked in both light and dark mode — not just for obvious contrast bugs, but for icons and images that were designed against one background and quietly disappear against the other. Same for Dynamic Type: bumping text size up a few steps is one of the fastest ways to find a layout that only ever got tested at the default size.
VoiceOver, at least once
We don't ship every app with a full accessibility audit, but every app gets at least one pass with VoiceOver turned on, navigating the core flow. It catches two different classes of problems at once: genuine accessibility gaps, and — just as often — missing or wrong labels that reveal a control isn't quite doing what the visual design implies.
The edges of the network
Airplane mode, a mid-request connection drop, a slow connection that times out instead of failing fast — these are the states real users hit constantly and demo environments almost never do. An app that only has a happy path for "the network always works" will surface that gap in production reviews, not in testing, if it isn't checked deliberately first.
First-run permission prompts
The first time an app asks for notifications, location, or camera access sets the tone for whether a user grants it at all — and once denied, most users never revisit Settings to change their mind. We check that every permission prompt fires with context (after showing why it's needed, not cold on launch) and that the app still functions sensibly if the permission is declined.
In-app purchase, in sandbox, start to finish
If the app has a subscription or one-time purchase, the full flow gets tested in StoreKit's sandbox — purchase, restore, and cancellation — before submission, not discovered as a rejection reason. This is one of the guideline areas we flagged in the launch-lessons post as a common source of avoidable review delays.
An external TestFlight round, not just the team
A build that's only ever been used by the people who built it has a blind spot built in. Every app gets at least one round of TestFlight with people outside the project before submission — different devices, different habits, different assumptions about what a button does.
The metadata, read back cold
Screenshots sized for every required device class, a privacy nutrition label that actually matches what the app collects, a support URL that loads — all checked as if seeing the listing for the first time, because Review does exactly that.
None of this replaces good engineering — it's what happens after the engineering is already solid, to make sure the version of the app a reviewer (and then a user) actually sees is the one you meant to ship.