App Review submission guide
Submitting to App Review should feel boring because everything is already ready.
A clean submission package includes the selected build, metadata, screenshots, App Privacy details, age rating, support routes, demo access, reviewer notes, release notes, and a documented release decision.
Submit app to App Store searches often happen when the build is ready but App Store Connect still feels unclear. The practical question is not just where the button is. It is whether the package around that button is complete enough for review.
Official source note: Apple explains that after preparing a submission, the app status changes to Ready for Review and the submission is sent when you submit it for review in App Store Connect: Submit an app.
Submission flow
Quick answer
Submit to App Review only after the full release package is ready.
Before submission, confirm the build, version, metadata, screenshots, App Privacy details, age rating, support URL, privacy policy, reviewer notes, demo account, hardware or region constraints, in-app purchase context, release notes, and release timing.
Quick answer: App Review submission checklist
Choose the build that passed TestFlight or release QA, not simply the latest upload.
Complete metadata, screenshots, privacy details, age rating, support links, and product information.
Provide demo credentials, testing steps, paid-feature notes, and any restricted-access context.
Decide manual, automatic, or phased release behavior before approval arrives.
Watch review status, respond clearly, release deliberately, and document the outcome.
Phase 1: select the right build
The build you submit should be the build you actually tested. Confirm the version, build number, App Store Connect processing status, release configuration, production endpoints, permissions, and known issues.
Build selection worksheet
| Item | What to confirm |
|---|---|
| Version | Public release version is correct |
| Build number | Matches the QA-approved build |
| Configuration | No staging endpoints, debug panels, or test flags |
| Permissions | Permission prompts explain the feature need |
| Login | Demo account works without extra manual steps |
| Stability | Crashes and blockers from TestFlight are fixed or understood |
Phase 2: complete metadata and required forms
The App Review submission is not only the binary. Metadata, screenshots, App Privacy details, age rating, support links, pricing or availability choices, and optional in-app purchase items must align with the build.
Submission package checklist
- Store listing copy is accurate.
- Screenshots match the submitted build.
- Privacy policy and support URL are live.
- App Privacy details are completed and owner-approved.
- Age rating is completed.
- In-app purchases, subscriptions, or paid access are represented correctly where applicable.
- Release notes are clear and non-sensitive.
- App Review contact can respond quickly.
Phase 3: reviewer access and notes
Reviewer notes can prevent unnecessary delays. If the app needs login, paid access, a specific region, hardware, a test role, seeded data, or a business account, explain it clearly. Do not assume the reviewer will infer a restricted workflow.
Provide durable demo access
Demo credentials should work throughout review and should not require SMS OTP to a founder's phone unless that path is explicitly planned.
Explain gated areas
If a feature requires subscription, purchase, admin approval, or a test account, describe exactly how the reviewer can reach it.
Call out device needs
Apps tied to hardware, Bluetooth, location, or external systems need specific review instructions.
Route review questions
Use a monitored contact so the team can respond quickly to clarification requests.
Phase 4: choose release behavior
Approval and release are separate planning decisions. A manual release can be safer for launches that need website updates, announcements, customer support, backend switches, or store listing coordination. Automatic release may be fine for routine updates.
Submitting the newest untested build
The latest upload is not always the best submission candidate. Submit the QA-approved release candidate.
No demo credentials
Apps with restricted login often slow down when reviewer access is incomplete or expires during review.
Privacy answers not owner-approved
App Privacy details should be approved by the business owner because they are public product-page claims.
No post-review owner
Someone must monitor review, answer messages, and decide when to release after approval.
Phase 5: after submission
After submission, monitor App Store Connect status and messages. If Apple asks for clarification or rejects an item, read the exact message and guideline context before changing the build. Sometimes the right response is a metadata fix, clearer reviewer note, a privacy adjustment, or a binary update. Sometimes the team needs to remove a rejected related item and continue with accepted items.
FAQ
What should be ready before submitting an app to App Review?
The selected build, metadata, screenshots, privacy details, age rating, support URL, privacy policy, reviewer notes, demo access, release notes, and release option should be ready and approved.
Does clicking submit guarantee review acceptance?
No. Submission starts the App Review process. Apple controls the review decision and may ask for changes, clarification, or resubmission.
Should I release automatically or manually after approval?
Manual release gives the owner more control for coordinated launches. Automatic release can fit simpler updates. Choose based on launch timing, marketing, operations, and risk.
