App Store Connect Checklist: Before You Submit an iOS App

Ah, App Store Connect: the part of launch day where one last checkbox can suddenly take center stage. This App Store submission checklist is for app developers with a tested build. It helps you make sure the App Store listing, privacy answers, and reviewer information all describe the same app before you submit it.

It is a final check of what App Store Connect asks you to complete and the app behavior that makes those answers true. If you still need the full account-to-release guide, start with our guide on how to submit an app to the App Store.

Know what App Store Connect checks, and what it does not

App Store Connect is Apple’s tool for managing an app record, uploading and selecting builds, running TestFlight tests, setting store information, and submitting a version to App Review. Apple’s App Store Connect Help is the source of truth for the exact fields and current screens.

Sort your final checks into three parts:

The binary: the app archive you upload. It contains the code, bundled settings, app icons, privacy manifests, and in-app behavior.
The listing: information entered in App Store Connect, such as screenshots, description, App Privacy details, price, and availability.
The reviewer route: review contact details, login credentials, Notes for Review, and anything else needed to test a feature.

When the build, store listing, and review instructions tell the same story, a reviewer has less detective work to do.

If you change the binary, upload a new build with a new build number. If the app is correct but a screenshot, privacy answer, or note is wrong, update that information in App Store Connect. This saves many unnecessary archives.

A store submission is not one form. It is a build, a listing, and a short map for the person reviewing both.

Before you open App Store Connect

Do the app-side checks first. A complete listing cannot rescue a build that crashes, opens a staging server, or keeps the main feature behind an expired test account. Apple’s App Review Guidelines say submissions should be final, tested on a device, and free of placeholder content.

Test the release build

Install the same release candidate you plan to upload on supported physical devices. Check first launch, sign-in, account recovery, permissions, the main task, purchases, links, and any flow that depends on your backend. Bring in a tester who did not build the feature if you can. Your own brain already knows all the secret handshakes.

Run the build through TestFlight as well. TestFlight is beta distribution, not App Review, but it confirms that Apple processed the uploaded build and gives you a chance to test the artifact users and reviewers would receive.

Check the account and version

Before creating a submission, confirm that:

The account has the agreements needed for your release. Paid apps and in-app purchases need the relevant financial setup.
Your Apple Developer membership and team access are active.
The bundle ID in Xcode matches the app record.
The version shown to customers is correct.
The build number is new for that version.

Apple requires an Account Holder, Admin, or App Manager role to submit an app for review. If the final button is unavailable, check access before blaming the browser. I have done the browser blaming. It was not the browser.

Complete the app record and product page

Apple’s required properties reference shows which app and version fields are required, localizable, or editable. App Store Connect changes over time. Treat the required-field markers in your own app record as the final checklist.

Make the App Store metadata match the build

Review each localization that you plan to ship. Check the app name, subtitle, description, keywords, category, content rights, copyright, and version information. Your screenshots and previews should show the current product, not a polished memory of it from three sprints ago.

Also test the support URL and privacy-policy URL from a device without your internal network or logged-in admin session. Apple’s guidelines require accurate metadata and accessible privacy information. A link that works only because you are already signed in can fail for users and reviewers.

Set the commercial details intentionally

Choose the price, tax category, storefront availability, and release method for the app. Apple’s publishing overview says you set pricing and availability before submission, then choose whether to release manually, automatically, or in phases where eligible.

Finish the age-rating questionnaire based on the content and capabilities users can access. Include user-generated content and unrestricted web access where they apply. The desired age rating is not the answer key, sadly.

Reconcile privacy and permissions

Privacy work often has three owners: the app developer, the person entering App Store Connect details, and the person who added an SDK six months ago. The reviewer still sees one app, so those descriptions need to match.

Compare the build, App Privacy, and policy

Review the release build and every bundled third-party SDK. Then make sure your App Privacy answers disclose what data is collected, whether it is linked to the user or used for tracking, and why it is collected. Your privacy policy must describe the same real behavior. It must be available both in the app and in App Store Connect.

If the app or an SDK uses APIs covered by Apple’s privacy manifest requirements, check the PrivacyInfo.xcprivacy file in the archive. A privacy manifest travels inside the build. App Privacy answers do not. Similar names, different suitcases.

A privacy policy, an App Privacy label, and a permission prompt should be three descriptions of one honest app.

Trigger every permission at the right moment

Open the release candidate and trigger every permission request users can reach. Confirm that each purpose string explains why the app needs access. Also confirm that the request appears when the feature needs it. If declining permission changes the experience, test that route too.

Give App Review clear test instructions

Use App Review Information to tell the reviewer exactly how to test the app. Add a contact person who can respond during review. If the app needs sign-in, give Apple working credentials that can access the features you are submitting. Keep the account, sample data, and backend online until review is complete.

Use Notes for Review to state:

The fastest path to the main feature.
What changed in this version, when that is not obvious.
How to test purchases, subscriptions, or account deletion.
Any special hardware, sample file, location, user role, or regional condition.

Keep the notes factual and short. Apple’s App Review guidance asks developers to explain non-obvious features and provide what reviewers need to test them. A two-minute route is more helpful than a page of launch copy.

For account-based apps, check the App Review Guidelines for the current access requirements. If you use a third-party login as the main account sign-in, check the current exceptions and requirements in Guideline 4.8 before submitting.

Check features that become required when you use them

Some App Store Connect checks only appear because your app has a certain feature. Do not skim past them because they were absent from the last release.

Purchases and subscriptions

Make each in-app purchase or subscription complete, visible, and testable. Test buying, restoring, and the entitlement that follows. If a reviewer needs a special path to find a product, put that path in Notes for Review.

Your paywall should accurately show what customers receive, the price, and the terms that apply. Apple’s payments rules contain the details and exceptions, especially where a feature could be sold inside the app.

Accounts, user content, and regulated features

If users can create an account, test the in-app account-deletion path. If people can publish content, comment, or message each other, test the reporting, blocking, filtering, and support routes that apply under Apple’s user-generated content rule.

For apps with regional limits, regulated services, or special hardware, explain what the reviewer can access. Attach or describe the evidence Apple needs. A clear limitation is easier to review than a feature that seems to be missing.

Attach the correct build and submit

When the binary, listing, and reviewer route are ready, submit in this order:

Open Apps in App Store Connect and select the app version.
In the Build section, attach the exact processed build you tested.
Complete any remaining required fields and answer applicable compliance questions from the shipped app.
Click Add for Review and choose or create the draft submission.
Open the draft submission and check every included item.
Click Submit for Review.

Add for Review prepares the draft. Submit for Review is the moment it leaves your hands.

Those last two buttons do different jobs. Apple’s submission instructions say Add for Review creates or updates a draft submission. Submit for Review starts review and moves the status to In Review. The first time I learned this, I congratulated myself one click early.

Final App Store Connect checklist

Run the short version at the finish line, then submit the draft you actually checked.

The release build works on supported physical devices and has been tested in TestFlight.
Bundle ID, version, build number, services, and app icon are correct.
Required agreements, pricing, availability, and age-rating answers are complete.
App Store metadata, content rights, screenshots, previews, and URLs match the selected build.
App Privacy details, privacy policy, permissions, and privacy manifest match the app and its SDKs.
Purchases, subscriptions, account deletion, or content-moderation paths are ready when the app includes them.
Review contact details, demo credentials, and Notes for Review give Apple a working test route.
The correct processed build is attached to the version.
You reviewed the draft after Add for Review and then clicked Submit for Review.

FAQ

Do I need App Store Connect to submit an iOS app?

Yes. Apple uses App Store Connect to manage the app record, store information, uploaded builds, TestFlight distribution, and App Review submission. You still prepare the archive in Xcode or another supported build system first.

What is the difference between Add for Review and Submit for Review?

Add for Review puts the version into a draft submission. Submit for Review sends that draft to App Review. Check the draft’s included items and selected build between those two actions.

Can I fix an App Store Connect problem without uploading a new build?

Yes, when the problem is only in the listing or reviewer information. Update metadata, screenshots, pricing, App Privacy answers, or review notes in App Store Connect. Upload a new build when the app code, bundled configuration, icon, or other binary content changed.

What should I put in App Review Notes?

Give a concise test path, working credentials where needed, and any special instructions for payments, permissions, hardware, regional behavior, or hard-to-find features. The goal is to let the reviewer reproduce the intended experience.

Conclusion

The useful App Store Connect checklist checks the build, listing, and reviewer route together. Test the app users will receive, make the store page tell the truth about it, and give App Review the shortest path to its purpose.

The final submission click should be the last check, not the first time all the pieces meet.

Further reading: How to submit an app to the App Store and the App Review Guidelines checklist.