Is my iOS app ready to publish?
No tool can answer that with a yes. App Review judges a running app, its content and its metadata, and a checker sees none of those. What can be settled before you submit is narrower and more useful, and it is 12 questions long.
What ready actually means
Ready is not a score. It is the state where nothing in the project contradicts a requirement App Review enforces mechanically, and nothing App Store Connect asks for is still blank. Those are two different piles, they are checked in two different places, and almost every avoidable rejection is something that was in one pile while the developer was looking at the other.
The 12 questions below are the ones worth settling in the last hour before you submit. They are the same 12 lines ReviewAhead prints at the end of a report, with the answers left to you. Each links to the longer page for the requirement behind it, where there is one.
The checklist
In the order somebody works through them: the build first, because it is the only one that cannot be fixed after upload, then what a reviewer needs, then the product page.
Is the thing you are about to upload actually a release build?
Build settings are per configuration, so a value changed while the Debug column was selected compiles and uploads perfectly well. What ships is then unoptimised, carries testability symbols, or has every #if DEBUG branch live in the app people download. Check ENABLE_TESTABILITY, SWIFT_OPTIMIZATION_LEVEL and any DEBUG=1 definition in the Release column, and check that aps-environment reads production in the entitlements your Release configuration signs with. A project says what the build was meant to be; the signed .ipa is what it became.
Can a reviewer get into the app at all?
Anything behind a sign-in needs a demo account in App Review information that still works at the moment the reviewer tries it, which is not the moment you typed it. Two-factor authentication on that account makes it unusable: a reviewer cannot receive your SMS. Anything else standing between them and the main functionality, an invite code, a geographic restriction or a backend environment, belongs in the notes beside it.
Will your backend be up, and reachable, while the app is reviewed?
A localhost address, a LAN IP or a staging host left in the source is a screen a reviewer on an office network cannot get past. Whether your production backend is actually running when App Review opens the app is the half no scanner can see, and it is worth checking the day you submit rather than the day you built.
Do your privacy policy and support URLs load for a stranger?
A privacy policy URL is required for every app, with no exemption for apps that collect nothing. It has to be publicly reachable: not behind a login, not on a staging domain, not a path that moved in the last redesign. A support URL is not listed as required, and App Review rejects on a dead one anyway. Open both in a private window with no session.
Do your App Privacy answers match what the app actually does?
The declaration on the product page, the privacy manifest in the build and the code all have to agree. A manifest that omits a required-reason API, a tracking declaration that does not match NSPrivacyTracking, or a third-party SDK shipping without its own manifest are the three that come back. Apple publishes no endpoint for the App Privacy answers, so this line always rests on what you say rather than on anything that can be read back.
App Privacy declarationPrivacy manifestRequired Reason API declarationsCollected data declarations
Is the age rating questionnaire finished, and does it fit the app?
The questionnaire sets the rating, and capabilities already in your project can force a minimum above the one you would have picked. It is answered in App Store Connect rather than in the project, so it is easy to leave at its defaults and easy to answer in a way the app contradicts.
Is there a screenshot for every size this version needs?
The required sizes follow from the device families your target ships on, so adding iPad support adds a set of uploads nobody remembers. Which sizes actually have an upload against this version lives in App Store Connect, not in the project.
If you sell anything, is each purchase submitted with the app?
Every in-app purchase is reviewed separately from the app and needs its own name, description and App Review screenshot. A product that exists in StoreKit but was never submitted is an app whose paywall a reviewer cannot complete, and a subscription carries its own obligations on the screen that sells it: price, period, and a link to your terms and privacy policy.
App Store Connect productsIn-app purchase metadataSubscription disclosure
If the app has accounts, can somebody delete theirs from inside it?
Guideline 5.1.1(v) wants deletion of the account on your server, started from inside the app, not a support email and not a sign-out. An app that offers account creation and no deletion path is rejected on a rule that has no exceptions for small teams.
If users can reach each other, are the four safeguards in place?
Guideline 1.2 asks for four things where anything one user writes reaches another: filtering of objectionable content, a way to report it, a way to block a user, and published contact information. Missing any one of them is a routine rejection, and the four are usually built at different times by different people.
Do the review notes say what a reviewer cannot work out alone?
A reviewer has an iPhone and nothing else. If the app needs hardware, a paired device, a provider account or a particular place to do anything useful, the notes have to say how to evaluate it without any of that. This is the rejection that is fixed with a paragraph rather than with code, and the one that costs the most review cycles when it is not.
What is left that a checker should not decide for you?
Some of it turns on what your policy says or what you are entitled to ship: whether a bundled SDK’s disclosure obligations are met, whether your own copy claims something the app does not do, whether a licence permits what you shipped. A scanner can point at these and should not settle them.
What no project scan can answer
A scanner reads project files. It cannot see your screenshots, your app’s runtime behaviour, your server’s responses, or the final signed entitlements, and all of those are things App Review evaluates. Whether your description matches what the app does, and whether the app is worth a place on the store, are judgements a person makes.
Half of the checklist above lives in App Store Connect rather than in your project, and a project scan cannot reach it. Those lines are questions you answer, and your answer is what the report records.
So the honest version of the promise is the one on every page here: this reduces submission risk, and nothing can guarantee approval. What it removes is the category of rejection that costs a review cycle for a value in a file you could have read.
Checking it yourself, or having it checked
Every line above can be checked by hand, and the guides say how. Doing it by hand costs an hour or two per submission and is easy to do partially: the Release column of a build setting, the entitlements file the Release configuration actually signs with, and a required-reason API declared by a dependency rather than by your own code are the three that get missed.
ReviewAhead reads the project and checks 38 of these requirements against it in one pass, then prints this checklist with each line marked ready, not ready, or unknown. Nothing is sent to Apple, and the extracted source is deleted when the scan finishes.