How to submit an app to the App Store, step by step
The order is: upload the build, fill in the version record, answer the compliance questionnaires, attach the build, choose a release option, submit. Apple will not let you press the button until every required field is answered, so most of the time between "the build works" and "the app is live" is not review. It is the checklist.
What follows is that checklist in the order you actually hit it, with the thing that blocks each stage stated plainly. Every stage has exactly one common blocker, and it is nearly always a field you have not filled in yet.
1. Get the build to Apple
Archive in Xcode and use Distribute App → App Store Connect, or upload with xcrun altool/notarytool from a script, or let Xcode Cloud do it. The upload itself is the easy part.
What blocks it: signing. The build must be signed with a distribution certificate and a matching App Store provisioning profile for the exact bundle ID of an app record that already exists in App Store Connect. If the app record does not exist yet, create it first at Apps → ＋ → New App, because the bundle ID has to be registered before an upload will be accepted.
2. Wait for the build to finish processing
Uploading is not the same as arriving. Apple runs the binary through processing, and until that finishes the build does not appear in the Build section of your version or in TestFlight.
What blocks it: a build can come back Invalid Binary, which App Store Connect defines as "You've submitted your app to App Review, but the build does not meet the current binary requirements." Missing icons, an unsupported SDK version, a disallowed entitlement and bad Info.plist values all land here. You cannot repair an invalid build; you fix the project and upload a new one with a higher build number.
3. Create the version record
In the app's sidebar, add the version you are shipping. A fresh app record sits at Prepare for Submission, which Apple describes as "You've created an app record in App Store Connect but are still preparing information for it."
What blocks it: the version string must be higher than the last released one. Reusing a version number that has already shipped is rejected before review.
4. Write the listing
Name, subtitle, promotional text, description, keywords, support URL, marketing URL, and the same set again for every localisation you have added.
What blocks it: the character limits, which are hard limits enforced by the field, and the required URLs. A support URL that 404s is a real rejection reason, not a technicality. Keywords are invisible to users but are reviewed, and stuffing competitor names there is one of the more reliable ways to get a metadata rejection.
5. Screenshots and app previews
At least one screenshot for each required display size, per platform, per localisation you have chosen to localise assets for.
What blocks it: exact pixel dimensions. App Store Connect rejects the file at upload if the resolution is not one it recognises for that slot, so this failure is immediate rather than a review surprise. Screenshots that show a device frame, a competitor's UI, or content that is not in the app are a review problem instead.
6. Age rating
Under App Information, work through the age rating questionnaire. It now covers in-app controls, capabilities such as User-Generated Content, Messaging and Chat and Social Media, and then content descriptors across mature themes, medical or wellness topics, sexuality or nudity, violence and chance-based activities.
What blocks it: an unanswered questionnaire leaves the app Unrated, and Apple states plainly that "An Unrated app can't be published on the App Store." Note also that Apple has said responses to the social media questions become required for new apps and updates from September 2026.
7. App privacy
The privacy questionnaire, sometimes called the privacy nutrition label, asks what data your app and every SDK inside it collects, whether it is linked to identity, and whether it is used for tracking.
What blocks it: submission is refused until the privacy details are complete, and a privacy policy URL is required. The answers must cover third-party SDKs, not just your own code, which is the part most people under-declare.
8. Export compliance
Two or three questions about encryption. Almost every app uses HTTPS, so almost every app touches this.
What blocks it: nothing, if you answer it. Apple's own guidance is that encryption built into the operating system, "for example, when your app makes HTTPS connections using URLSession", is exempt from the documentation upload requirement. Set ITSAppUsesNonExemptEncryption in Info.plist once and you stop being asked with every upload. If you genuinely ship proprietary crypto, your version can sit at Waiting for Export Compliance while Apple processes a CCATS file, which is a queue outside App Review entirely.
9. Pricing and availability
Price tier, the countries and regions you are selling in, and any pre-order settings.
What blocks it: the Paid Applications agreement. If it is unsigned, paid apps and in-app purchases are not available at all, and only the Account Holder can sign it under Business in App Store Connect. This one catches teams late, because everything else looks finished.
10. Attach the build and answer App Review Information
On the version page, pick the processed build. Then fill in App Review Information: contact name, phone, email, and notes.
What blocks it: anything behind a login. If your app has a sign-in wall and you do not supply working demo credentials, the reviewer sees a login screen and nothing else, and you get a rejection that costs a full round trip. Give a demo account that does not expire, and note anything a reviewer would not find on their own, such as a feature that needs a hardware peripheral or a specific region.
11. Choose the release option
Three options, in Apple's wording: "Manually release this version", "Automatically release this version", and "Automatically release this version after App Review, no earlier than" a date and time you set.
For updates you can also switch on phased release, which rolls the update out to users with automatic updates over seven days at 1%, 2%, 5%, 10%, 20%, 50% then 100%. Anyone can still download the new version manually from the App Store during a phased release, so it limits blast radius, not availability. You can pause a phased release for up to 30 days in total, and Release to All Users ends it early.
What blocks it: nothing, but pick deliberately. Manual release is the safe default when you want to coordinate a launch, and the cost is that an approved build waits for you.
12. Submit
Add the version to a submission and send it. In-app purchases, in-app events, custom product pages and Game Center items can ride along in the same submission, but items for different platforms cannot share one.
What blocks it: any incomplete field above, and the concurrency limit. You can only have one submission containing an app version in review at a time per platform.
13. Waiting for Review, then In Review
Waiting for Review means, in Apple's words, "Apple received your submission, but hasn't started the review." In Review means "App Review is reviewing your app." You can pull a submission back yourself, which sets the status to Developer Rejected: "You removed your app from review."
What blocks it: nothing you control. Apple publishes one figure, that "on average, 90% of submissions are reviewed in less than 24 hours", and there is no queue position, no ETA, and no way to see where you sit.
14. If it is rejected
Rejected means the build or its behaviour failed a guideline. Metadata Rejected means "App Review didn't accept your metadata", which is better news, because metadata can usually be fixed without a new build.
What blocks it: you do. Read the resolution centre message, fix the specific citation rather than guessing broadly, reply in the same thread with what changed, and only upload a new build if the rejection actually needs one. If you believe the decision is wrong, there is an appeal to the App Review Board, one per rejected submission.
15. Pending Developer Release, then live
If you chose manual release, approval lands you at Pending Developer Release: "Your app was accepted, but you still need to release it for distribution on the App Store." Click Release This Version. Apple's help notes it may take up to 24 hours to appear on the App Store, and that you get an email reminder if a version sits here for more than 30 days.
The final status is Ready for Distribution. That is live.
Everything above is fifteen stages, four questionnaires and one binary, and the failure mode is always the same: one unanswered field holding the whole thing. AppSubmit runs the same checks in the same order before it talks to Apple, so a missing demo account or an off-size screenshot fails on your screen rather than three days into a review queue. You can do every one of these by hand from this list.