App Store submission checklist: ship without a rejection

Apple’s review is the one step of an iOS launch you do not control. What you do control is everything before it. This App Store submission checklist walks through the accounts, assets and settings Apple asks for, in the order you will need them, plus the reasons apps get rejected most often. Apple updates its rules every year, so treat this as a map and confirm the details in App Store Connect and the current App Review Guidelines before you submit.

Accounts and agreements

Start here, because some of it takes days.

• Apple Developer Program membership. You can enrol as an individual or as an organisation. The app will be listed under the name you enrol with, so most companies should enrol as an organisation. There is an annual fee; check the current amount on Apple’s site.
• A D-U-N-S number for organisation accounts. Apple uses it to verify your company. If you do not have one, request it early, because it can take a while to issue.
• Agreements in App Store Connect. Accept the latest Apple Developer Program License Agreement. If you sell anything, also complete the Paid Applications agreement, tax forms and banking details. Unsigned agreements quietly block releases.
• Team roles. Add your developers and agency with the right roles, so nobody has to share a login.

Build and technical requirements

• A current Xcode and SDK. Apple sets a minimum Xcode and SDK version for new uploads and raises it regularly. Check the current requirement before your final build.
• Bundle ID, signing and capabilities. The bundle ID is permanent once the app is live. Enable only the capabilities you use, such as push notifications or Sign in with Apple.
• Privacy manifest. Apps and many third-party SDKs must declare the data they collect and the reasons they use certain system APIs. Update your SDKs, because old versions are a common cause of upload warnings.
• Permission strings. Every permission prompt (camera, location, photos, contacts) needs a clear purpose string that says why the app needs it. Vague text like “We need access” invites a rejection.
• Export compliance. Answer the encryption questions. Most apps that only use standard HTTPS qualify for an exemption, but you still have to declare it.

Privacy and data

Apple reviews privacy closely. This part of the checklist deserves real attention.

• App Privacy details (the “privacy nutrition label”). In App Store Connect you declare what data the app collects, whether it is linked to the user, and whether it is used for tracking. Include data collected by your SDKs, such as analytics and crash reporting. The label must match what the app actually does.
• App Tracking Transparency. If you track users across other companies’ apps or websites, you must ask permission with the system prompt first.
• A privacy policy URL, linked in App Store Connect and reachable inside the app.
• Account deletion. If users can create an account in the app, they must also be able to start deleting it from inside the app.
• Sign-in options. If you offer third-party or social login, review the current login services guideline. In many cases you also need to offer an equivalent privacy-focused option, such as Sign in with Apple.

The App Store submission checklist for your listing

Item	What to prepare
App name and subtitle	Short, accurate, no keyword stuffing or competitor names
Description	What the app does, in plain language. Do not mention other platforms or prices that may change
Keywords	A comma-separated list within Apple’s character limit
Screenshots	Real screens from the app for each required device size. Check App Store Connect for the current required sizes, and add iPad screenshots if the app runs on iPad
App preview video	Optional. Must show footage captured from the app itself
App icon	Included in the build, with no transparency
Category and age rating	Pick an honest category and answer the age rating questionnaire carefully
Support URL	A working page where users can reach you
Review notes	How to use the app, a working demo account, and anything the reviewer cannot see without help

Screenshots should show the app as it is. Marketing frames and captions are fine, but the screens inside them must be real and current.

Test with TestFlight first

TestFlight is Apple’s beta testing service, and it is the best rehearsal for review.

• Internal testing is for people on your App Store Connect team. Builds are available to them right after processing.
• External testing lets you invite a wider group by email or a public link. The first build for external testers goes through a short Beta App Review, which often catches problems before the real review does.
• Test on real devices, including an older iPhone and the smallest screen you support. Simulators miss memory, performance and permission issues.
• Test a fresh install with no saved login, on a slow network, with every permission denied once. That is roughly how a reviewer meets your app.

Common rejection reasons

Most rejections are avoidable, and each item below maps back to a line in this App Store submission checklist. These come up again and again:

• Crashes and bugs (App Completeness). The reviewer hits a crash, a dead button or a blank screen. Test the build you submit, not an earlier one.
• Placeholder content. Lorem ipsum, test data or “coming soon” sections.
• No working demo account. If the app needs a login, the reviewer needs credentials that work for the whole review, with sample data inside.
• Inaccurate metadata. Screenshots or descriptions that show features the app does not have.
• Privacy mismatches. The privacy label, permission strings or policy do not match the app’s behaviour.
• Digital goods sold outside in-app purchase. Rules on payments for digital content are detailed and vary by region, so read the current guideline before you design your paywall.
• Minimum functionality. An app that is mostly a wrapped website, or does too little to be useful as an app.
• Missing account deletion when the app supports account creation.

If you are rejected, read the message carefully, reply in Resolution Center with specifics, and fix the exact issue. Disagreements can be appealed, but a clear reply often solves it faster.

Release settings

Before you press submit, choose how the approved build goes live: automatically, manually on a date you pick, or with phased release, which rolls an update out to users gradually over several days. For a first launch, a manual release gives you control over timing, so marketing and support are ready.

Store prep is part of every mobile project we run. In a 2Sprint, days 11 to 13 are reserved for QA on real devices and store prep, so nothing avoidable is left for the reviewer to find. The full calendar is in how a two-week sprint works.

Frequently asked questions

How long does App Store review take?

It varies. Many apps are reviewed within a day or two, but first submissions, complex apps and busy periods can take longer. Plan launch dates with a buffer and do not announce a day you cannot move.

Do I need a company to publish on the App Store?

No. Individuals can publish. An organisation account shows your company name as the seller, which most businesses prefer, and it needs a D-U-N-S number.

Does every update go through review?

Yes. Each new version is reviewed, though updates are often faster than first submissions. Clear review notes help every time.

What should go in the review notes?

A short description of the main flow, a working demo account, and any hardware, location or setup the reviewer needs. If something is hidden behind a feature flag or a paid plan, explain how to reach it.

Review can still surprise you, but a careful checklist turns most surprises into a quick fix instead of a lost week.