To submit your first iOS app, create its App Store Connect record, upload a signed build, complete the product and review information, select the build, and send the finished submission to App Review. The order matters. App Store Connect will not let you complete later steps when an earlier identifier, agreement, build, or required field is missing.
This guide follows the current App Store Connect submission flow and shows where first-time founders usually lose time. It covers the submission itself, not every design, privacy, or monetization rule your app may need to satisfy.
The short version
- Create the App Store Connect record before uploading your first build.
- Match the record, bundle ID, version number, and signed build exactly.
- Give App Review a working path through login, payments, permissions, and hidden features.
- “Add for Review” prepares the submission; “Submit for Review” actually sends it to Apple.
Before you open App Store Connect
Your app should be release-ready before you start filling fields. Apple describes the App Review Guidelines as a living document and expects submissions to be final, testable versions with complete metadata and working URLs.
Confirm these prerequisites first:
- your Apple Developer Program membership is active;
- the Account Holder has accepted the latest agreements in App Store Connect;
- the production bundle identifier is final and registered;
- your version and build numbers are set correctly;
- the app runs on a physical device without development-only services;
- your privacy policy and support pages are public;
- any production backend, demo account, and required test data are available.
Apple says submissions should be “final versions with all necessary metadata.” That wording matters. A polished binary with placeholder screenshots, an empty support page, or an unreachable backend is still incomplete under Guideline 2.1.
I built AppRejectKit after going through my own first submission and researching the rejection paths that followed. The practical lesson is simple: treat the app, its App Store record, and the reviewer’s access path as one release.
Step 1: Create the app record
Create the App Store Connect app record before uploading your build. Apple uses the bundle ID and version information inside the build to associate it with this record.
In App Store Connect:
- Open Apps.
- Select the add button, then New App.
- Choose iOS and any other platform that belongs to the same app record.
- Enter the app name, primary language, bundle ID, and SKU.
- Choose full or limited user access.
- Select Create.
Apple’s new app record instructions require an Account Holder, Admin, or App Manager role. They also note that the latest agreement must be signed before a new app can be added.
The fields look harmless, but two deserve care:
| Field | What it controls | Common first-submission problem |
|---|---|---|
| Bundle ID | Connects the uploaded binary to this record | The Xcode target uses a different identifier |
| SKU | Internal identifier for your own reporting | A founder mistakes it for the public app name |
| Primary language | Default language for App Store information | The wrong language becomes the initial metadata base |
| User access | Which App Store Connect users can manage the app | A teammate cannot finish the submission |
After creation, the app status becomes Prepare for Submission. That means the record exists. It does not mean Apple has received anything for review.
Step 2: Upload and process the build
Upload a release archive with Xcode, Transporter, Swift Playground, or Apple’s supported command-line flow. Most first-time iOS developers use Xcode Organizer: archive the production scheme, validate the archive, then distribute it to App Store Connect.
The uploaded binary must match the record on three values:
- bundle ID;
- marketing version, such as
1.0; - build number, such as
1.
Apple’s build upload documentation explains that the build is processed before it appears in App Store Connect. You will receive an email when processing completes. Uploading the archive twice does not make processing faster.
If the build never appears, check the delivery email and Xcode Organizer before creating another app record. Typical blockers include a mismatched identifier, a reused build number, missing compliance information, or a processing error reported by Apple.
One app version can have several uploaded builds, but only one selected build is attached to that version at a time. You may change the selected build until the version is submitted to App Review.
Step 3: Complete the product page information
The App Store product page must accurately describe the build the reviewer receives. Finish the required fields for the version and each localization before selecting the final build.
Prepare at least:
- app name and subtitle;
- description and keywords;
- screenshots for every required device display;
- support URL and privacy policy URL;
- category, age rating, and content rights answers;
- version release notes when applicable;
- pricing, availability, and release method.
Apple’s app information reference currently limits both the app name and subtitle to 30 characters. It also requires a privacy policy URL for iOS apps.
Every claim on this page should be verifiable inside the submitted build. Do not advertise a feature that is behind an unfinished flag, missing from the review account, or available only in a later release. Screenshots should show the current interface rather than a design mockup that the reviewer cannot reproduce.
If your app uses subscriptions or in-app purchases, create and complete those products early. They can require agreements, tax and banking setup, localization, pricing, screenshots for review, and an explicit relationship to the app submission. A paywall that references an unavailable product is not a complete review path.
Step 4: Fill in App Review Information
App Review Information tells the reviewer how to reach and verify the parts of your app that are not obvious. It is private review metadata, not public App Store copy.
Provide:
- a real contact name, phone number, and email;
- a demo username and password when login is required;
- concise Review Notes for non-obvious setup or navigation;
- an attachment when a screenshot or short recording removes ambiguity.
Apple’s App Review overview warns that missing settings, account details, or special instructions may delay review or prevent the submission from passing. Guideline 2.1 also requires a demo account when the app includes login, unless Apple has approved another access arrangement.
A good review note is a test path:
- Launch the app from a clean install.
- Sign in with the supplied review account.
- Open the named tab or screen.
- Perform the action Apple needs to inspect.
- State the expected result.
Avoid biographies, sales copy, and arguments about why the app deserves approval. The reviewer needs access, state, and navigation. If a feature depends on location, hardware, an entitlement, a subscription state, or seeded data, say so before the reviewer has to guess.
Step 5: Answer compliance and privacy questions
Complete the declarations against the actual production build, including every third-party SDK it contains. These answers are part of the submission, even when the corresponding feature feels secondary.
Check:
- App Privacy data types and their purposes;
- tracking declarations and any required privacy manifest work;
- export compliance for encryption;
- content rights;
- advertising identifier usage;
- age-rating answers;
- account deletion when the app supports account creation.
Do not copy answers from another app or from a generic checklist without inspecting your binary and data flows. Analytics, crash reporting, authentication, payments, support tools, and ad SDKs can change what the app collects or transmits.
For privacy or regulated features, use Apple’s current documentation and obtain professional advice when needed. AppRejectKit provides product and submission guidance, not legal advice.
Step 6: Select the exact build you tested
Attach the processed build to the app version only after you have tested that exact archive or a distribution-equivalent build. In the version page, scroll to Build, choose the add button, and select the build.
Apple’s build selection instructions confirm that one build can be associated with each app version. You may replace it before submitting.
Record the selected version and build number in your release notes. Then run the reviewer’s path again:
- clean installation;
- first launch and permissions;
- account creation or demo login;
- core workflow;
- purchase, restore, and entitlement state when applicable;
- support, privacy, and account-deletion links;
- offline, empty, and error states that the reviewer can reach.
This last pass catches a common mismatch: the team tested build 14, then attached build 13 because both appeared in the picker.
Step 7: Add the version for review, then submit it
App Store Connect uses two separate actions. Add for Review places the app version into a draft submission. Submit for Review sends that draft to Apple.
The current submission instructions are:
- Open the app version and verify the selected build.
- Select Add for Review.
- Add the version to an existing draft submission or create a new one.
- Review every item in the draft submission.
- Select Submit for Review.
The app version becomes Ready for Review after the first action. Apple has not received it until the second action completes. After submission, its status moves to Waiting for Review, then In Review when review begins.
If Apple returns an issue, keep the message and selected build together before changing anything. The guide on what to do after an App Store rejection explains how to choose between a reply, metadata edit, new build, or appeal.
Subscriptions, in-app purchases, in-app events, custom product pages, and other items can be included in a submission. Apple notes that all items submitted together must be accepted for that submission to complete. Confirm that every item visible in the draft is intentional.
Run one final review-readiness pass
A final pass should verify the full submission, not just whether every red warning disappeared in App Store Connect. Apple reports that more than 40% of unresolved review issues relate to Guideline 2.1, which includes crashes, placeholders, incomplete information, and access problems. Apple also reports that 90% of submissions are reviewed in less than 24 hours, so an avoidable miss can return quickly and still cost another cycle.
Before submitting, verify these seven release surfaces:
- the selected build matches the version you tested;
- public metadata matches the current product;
- review credentials work from a clean device state;
- production services and URLs are live;
- subscriptions and purchases are visible and testable;
- privacy and compliance answers match the app and SDKs;
- Review Notes provide the shortest reproducible path.
FAQ about submitting your first iOS app
Do I need an App Store Connect record before uploading the build?
Yes. Apple requires the app record first. The uploaded build’s bundle ID and version information are then used to associate it with that record.
Can I change the selected build before review?
Yes. You can upload several builds and change the one attached to the app version until you submit that version to App Review.
Does Add for Review send the app to Apple?
No. It adds the version to a draft submission and changes the version to Ready for Review. You must still open the draft and select Submit for Review.
How long does App Review take?
Apple currently says 90% of submissions are reviewed in less than 24 hours. Complex, incomplete, or unusual submissions may take longer, so this is not a guaranteed review time.
Can I submit subscriptions with the first app version?
Yes. Subscriptions and in-app purchases can be included with the app version. Confirm that each item is complete, attached to the intended submission, and reachable in the reviewed build.
Conclusion
Your first App Store submission is a chain: record, build, metadata, reviewer access, compliance answers, selected items, and the final Submit for Review action. A missing link can stop the flow before review or return as an avoidable rejection.
Keep the version and build you tested written down, verify the reviewer’s path from a clean state, and read the draft submission once more before sending it.