The Short Answer
Set up App Store Connect in this order: enrol in the Apple Developer Program, register your bundle identifier, create the app record, fill in the app information and pricing, complete the privacy questionnaire, upload your build, then add screenshots and metadata. Doing it in that order matters because several steps are blocked until an earlier one exists, and two of the early decisions cannot be undone later.
Before You Create Anything
Two decisions carry forward permanently, and both are made in the first five minutes by people who did not know they mattered.
The bundle identifier is the permanent internal identity of your app. Reverse domain format, lowercase, no placeholder words you will regret. If you register com.mycompany.testapp1 you will be looking at that string for the life of the product, because it cannot be renamed and cannot be reused even after deletion.
The app name is claimed on the App Store when you create the record, and it can only be changed while the app has never been released. Once your app is live, changing the name is a submission of its own. Decide it first, and check it is not already taken before you build anything around it.
- Bundle ID in reverse domain form, using a domain or company name you will still be using in two years.
- No words like test, demo, v2, or new in the bundle ID.
- App name checked for availability on the store before you commit to branding.
- Primary language chosen deliberately, because it sets the default for all your metadata.
The Order That Avoids Rework
Setup sequence and why each step comes when it does
| Step | Why this position |
|---|---|
| Enrol in the Apple Developer Program | Nothing else exists until this is approved, and approval is not instant |
| Register the bundle identifier | The app record cannot be created without one |
| Create the app record in App Store Connect | Everything else attaches to this record |
| Fill app information, category, and pricing | Cheap to do early and it unblocks other sections |
| Complete the privacy questionnaire | It requires knowing every SDK, so start the audit early |
| Upload the first build | Processing takes time, and you want a build in place before the final push |
| Add screenshots, description, and keywords | The most time-consuming part and the most common last-minute blocker |
The developer program enrolment being first is not a formality. Approval involves verification that can take days, particularly for a company account rather than an individual one, and everything downstream is blocked until it completes.
The Privacy Questionnaire Catches Everyone
This is the section that surprises first-time developers most, because it asks what data your app collects and that includes data collected by anything you added to it. Analytics, crash reporting, advertising, authentication, any third-party service.
You cannot answer it accurately without listing every SDK in your project and checking what each one collects. Guessing here is genuinely risky, because an inaccurate privacy declaration is a compliance problem rather than a rejection you can quietly fix.
- List every third-party package and service in your project.
- Find the published privacy documentation for each one.
- Note what each collects and whether it is linked to the user's identity.
- Answer the questionnaire from that list rather than from memory.
- Keep the list, because you redo this whenever you add a dependency.
Screenshots Are a Hard Requirement
Screenshots are not optional and they must match exact pixel dimensions for the required device sizes. A submission cannot proceed without them, and this is where a launch most often slips by a day because nobody treated it as real work.
Beyond the technical requirement, these are the primary thing that decides whether someone downloads your app. The first two are visible without scrolling, so they should show the single most useful thing your app does, not a login screen or an empty state.
- Generate them from the simulator at the exact required sizes rather than resizing afterwards.
- Show a populated, realistic screen. Empty states look like an unfinished product.
- Put your strongest feature in the first two, since those are what most people see.
- Keep any overlaid text short enough to read on a small thumbnail.
- Avoid anything in the images that is not actually in the app, which is a rejection reason on its own.
The Fields That Quietly Block Submission
A handful of smaller fields hold up submissions far more often than their size suggests, mostly because they sit in sections people scroll past.
Easy to miss, expensive to discover late
| Field | What goes wrong |
|---|---|
| Support URL | It is required and must be a working page, not a placeholder |
| Privacy policy URL | Required for essentially every app, and it must actually load |
| Age rating questionnaire | Must be completed even for apps with no sensitive content |
| Demo account for review | If anything is behind a login, review needs working credentials or it gets rejected |
| Export compliance | Asked at every build upload, and it surprises people who did not write encryption code |
| Agreements, tax, and banking | Paid apps cannot go live until these are complete, and they take longer than expected |
Where to Go From Here
Before you create anything, write down your bundle ID and your app name and sit with them for ten minutes, because those are the two you cannot take back. Then start the developer enrolment, since it is the step with a waiting period attached and everything else depends on it.
Inside App Store Launch Club, members walk through the setup with their actual app in front of them and we catch the permanent decisions before they get made. Join at applaunchclub.co for $9 a month.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
What order should I set up App Store Connect in?
Developer program enrolment, bundle identifier, app record, app information and pricing, privacy questionnaire, build upload, then screenshots and metadata. Several steps are blocked until an earlier one exists, so working out of order creates rework.
Can I change my bundle identifier later?
No. It is permanent and cannot be reused even after an app is deleted. Use reverse domain format with a company or domain name you will still be using in two years, and avoid words like test or demo.
Can I rename my app after publishing?
Only through a new submission, and the name is claimed the moment you create the app record. While the app has never been released, changes are easy. After release they become a review cycle.
Why is the privacy questionnaire so difficult to complete?
Because it asks about data collected by every SDK in your app, not just code you wrote. You need a list of every third-party package and what each one collects, which is why it is worth auditing during development rather than on submission day.
Do I really need screenshots to submit?
Yes, at exact pixel dimensions for the required device sizes. Submission cannot proceed without them, and they are also the main thing that decides whether someone downloads, so the first two should show your strongest feature rather than a login screen.
What is the most common avoidable rejection at this stage?
Not providing a working demo account when part of the app sits behind a login. Reviewers cannot see the app, so it is rejected. Put working credentials in the review notes every time.
Last reviewed by David on August 15, 2026
