The App Store Submission Checklist for iOS

The submission itself is a deliverable, not paperwork squeezed into the last afternoon before a launch. Apple's review process checks the build, the metadata, the privacy behavior, and the marketing claims together, so a flaw in any one of them can hold up the others. Teams that prepare the submission alongside the feature work tend to pass review in fewer cycles, and they keep a buffer for the feedback that always seems to arrive at an inconvenient moment.

Signing starts with the account. The organization needs an active Apple Developer Program membership, a role in App Store Connect that permits app management, and a bundle identifier registered before the first archive. Xcode's automatic signing handles most certificate and provisioning profile choreography, but the distribution certificate and profile still have to be valid at upload time. Store the membership credentials and signing assets somewhere the team can find them, because a departing contractor should never take the ability to ship with them.

The build path is short but unforgiving: archive the release configuration, verify the version and build number, complete the export compliance questions, and upload to App Store Connect. TestFlight then becomes the rehearsal space. Internal testers should exercise the exact build that will be submitted, on real devices, with production-like data. Export compliance answers and encryption declarations belong in the checklist too, since an incomplete answer can stall processing before a human ever looks at the app.

Privacy is where many submissions lose their first round. App privacy labels must match what the app and its SDKs actually collect, purpose strings must explain each permission in plain language, and tracking prompts must appear before any tracking occurs. If the app offers account creation, Apple expects an in-app way to delete the account as well. The privacy policy URL must resolve, describe the data practices, and not contradict the label. Auditing third-party SDK behavior is part of this work, not an optional nicety.

Metadata needs the same care as interface copy. The app name, subtitle, keywords, description, promotional text, category, age rating, support URL, and copyright each influence not only review but discovery. Screenshots are checked against the real interface, so placeholder images or mock screens that do not exist in the build invite rejection. Required sizes, an optional app preview, and localized listings should be planned once and updated deliberately, rather than regenerated in a hurry every release.

Version numbers are part of the submission contract. Every upload needs a build number higher than the last, and the marketing version should follow a scheme the team has committed to, because App Store Connect rejects duplicates without ceremony. Run a short pre-submission pass: confirm the build is signed with the distribution certificate, the scheme is Release rather than Debug, the app record points at the right bundle identifier, and the metadata matches this exact version. Fifteen minutes of checking prevents a day of waiting on an upload error that only surfaces at the end of the process.

Review notes save days of back-and-forth when they are specific. Provide a demo account with credentials that work from a clean install, note any hardware or configuration needed, and explain features a reviewer might not otherwise reach. In-app purchases must be configured and visible in the build under review. If a feature is region-locked or behind an allowlist, say so and describe how to see it. Reviewers test what they can find; anything hidden will be treated as missing.

Common rejection reasons are mostly preventable: a crash on launch, placeholder or lorem-ipsum content, a sign-in wall without demo access, incomplete screens presented as finished, misleading metadata, or an app that is essentially a website wrapper without enough native value. Guideline 4.2 on minimum functionality is worth reading before submitting a thin client. Every rejection costs a calendar cycle, so an internal review against the guidelines before submitting is cheaper than discovering the same problem from a reviewer.

If a rejection does arrive, read it carefully and respond in the Resolution Center rather than resubmitting blindly. Fix the stated issue, explain what changed, and include any evidence the reviewer needs. If the rejection is factually wrong, a calm appeal with references to the specific guideline behavior is the right path; an expedited review request exists for genuine time-sensitive situations but is not a general fast lane. Resubmitting an unchanged build simply restarts the clock with the same outcome likely.

After approval, a phased release lets you watch crash reports and feedback before the whole user base updates. Monitor App Store Connect metrics, crash logs, and reviews for the first days, and keep the previous version ready in case a regression requires a quick follow-up. A submission checklist is not a one-time document: it becomes the release runbook that each version executes with fewer surprises than the last.