Publishing an iOS app on the App Store means enrolling in the Apple Developer Program, creating a distribution certificate and provisioning profile, uploading a signed build through Xcode, completing your App Store Connect listing, and submitting for Apple’s manual review, which typically takes 24 to 72 hours. Each step has specific technical requirements, and missing even one of them is the most common reason first-time submissions stall or get rejected.

This guide covers the actual submission process in depth, not the broader question of how to build an iOS app in the first place. If you’re still earlier in development, our guide on how to build an iOS app covers everything leading up to this exact point.

The technical complexity that used to make this process genuinely difficult has largely disappeared over the past several years, automatic code signing, clearer App Store Connect guidance, and better validation tooling have all reduced the number of steps that used to require deep iOS expertise. What remains is closer to a documentation and preparation exercise, one with specific, predictable requirements Apple publishes clearly, but that most first-time publishers still don’t fully read until they’re already stuck partway through.

What Is App Store Connect?

App Store Connect is Apple’s portal for managing everything about your app’s presence on the App Store, from creating your listing and uploading builds to managing TestFlight testers, reviews, and analytics after launch. Nearly every step covered in this guide happens inside this one platform, which is why understanding its layout before you start saves real time compared to learning it while under pressure to hit a launch date.

The platform organizes around a single app record that tracks status through the entire lifecycle, from an initial “Prepare for Submission” state through review and eventual release, with a clear visual indicator showing exactly where a given build sits in that process at any moment. Getting familiar with this status system before your first real submission means you’ll recognize immediately whether something needs your attention or is simply progressing normally through Apple’s pipeline, rather than wondering whether a long wait on one particular status actually signals a problem.

What You Need Before You Start

Gather these five things before opening App Store Connect, since missing any one of them mid-submission means stopping to go get it and picking up where you left off later.

• An active Apple Developer Program membership, $99 per year for individuals or $299 per year for organizations
• A registered Bundle Identifier that exactly matches what your app was built with
• A Distribution Certificate and matching Provisioning Profile
• A hosted, live privacy policy URL
• App icon and screenshot assets sized correctly for current requirements

Step 1: Create Your Distribution Certificate and Provisioning Profile

What These Two Files Actually Do

A Distribution Certificate proves that your app binary was actually built by you, specifically an “Apple Distribution” certificate for App Store submissions, while a Provisioning Profile ties that certificate together with your App ID and confirms which distribution method, App Store, Ad Hoc, or Enterprise, the build is authorized for. Xcode can generate and manage both of these automatically if automatic signing is enabled, which is the right default for most teams unless you have a specific reason to manage signing manually.

Understanding why this system exists helps it feel less arbitrary once you’re working through it. Apple needs a reliable way to know that a given build genuinely came from a developer authorized to publish it, and the certificate and provisioning profile system is how that trust gets established cryptographically, not just through account login credentials that could theoretically be shared or compromised more easily. It’s a genuinely more secure model than a simple username and password, even though it adds real setup complexity the first time through.

The Wildcard App ID Mistake

A wildcard App ID, one using an asterisk to cover multiple apps under one identifier, is not compatible with push notifications, Sign in with Apple, in-app purchases, or several other entitlements. If your app uses any of these capabilities, register an explicit App ID from the start, since discovering this incompatibility mid-submission means going back to fix a foundational setup choice rather than a quick correction.

Step 2: Create Your App Record in App Store Connect

Create your app’s record in App Store Connect before a build can appear in TestFlight or get submitted for review, entering your app’s name, primary language, Bundle ID, and a unique SKU used internally to track the app. App names are capped at 30 characters, worth checking for availability early, since a name that’s already taken by another app forces a rename after you’ve potentially already built marketing around it.

Step 3: Prepare Your Screenshots and Store Assets

Current Screenshot Requirements

Apple requires screenshots for at least one iPhone size, the 6.9-inch display size as of 2026 submissions, with iPad screenshots optional unless your app supports iPad specifically. Screenshots need to be JPEG or PNG format without status bars visible, and while the technical minimum is one screenshot per required size, uploading four to eight tends to convert meaningfully better since the first three screenshots are what actually appear in App Store search results.

App Icon Requirements

Your app icon needs a 1024×1024 pixel version for the App Store listing itself, separate from the various in-app icon sizes Xcode generates automatically from your asset catalog. Getting this wrong is an easy, avoidable delay, since an incorrectly sized or formatted icon is flagged during Apple’s automated validation before a human reviewer even looks at your app.

Step 4: Complete Your Privacy Labels and Policy

Every data type your app collects needs to be explicitly declared in App Store Connect’s Privacy Labels section, and this declaration needs to match what your app’s actual code does, not just what you intended to build. If your app tracks users across other apps or websites for advertising purposes, an App Tracking Transparency prompt is required, and your privacy policy URL needs to be live and accessible, not a placeholder page, before you can submit.

This step connects directly to the mandatory Privacy Manifest requirement that took effect in 2026, requiring specific disclosure around any third-party SDK accessing sensitive device APIs. Treating this as a genuine audit of what your app and its dependencies actually collect, rather than a form to fill out quickly, avoids a rejection that traces back to a mismatch between your declared privacy labels and your app’s real behavior.

Getting privacy documentation and the rest of this submission process right the first time is exactly the kind of detail-heavy work mobile app development planning should account for before a launch date gets set around an optimistic assumption about review timelines.

Step 5: Configure In-App Purchases If Your App Sells Anything Digital

Any app selling digital goods, subscriptions, or unlockable content needs its in-app purchases configured and approved through App Store Connect before submission, a process that runs somewhat parallel to your app’s own review. Apple requires all digital goods and services to use its in-app purchase system rather than an external payment link, a policy worth confirming your monetization plan actually complies with well before this becomes a submission blocker.

Step 6: Test Through TestFlight Before You Submit

Distribute a build through TestFlight to real testers before submitting to the App Store, catching device-specific bugs, crashes, and usability issues a small internal team testing on one or two devices will consistently miss. This step uses the same distribution certificate and provisioning profile setup from Step 1, so getting that foundation right early pays off again here rather than requiring a separate configuration.

Step 7: Archive and Upload Your Build in Xcode

Set your version number, using CFBundleShortVersionString for the user-facing version and CFBundleVersion for the internal build number, then choose Product, then Archive in Xcode to compile your release build. Once archiving completes, use the Distribute App option to upload directly to App Store Connect, where Xcode will validate the binary and flag common errors, incorrect signing, missing entitlements, size violations, before the upload even completes. As of April 28, 2026, every new submission must be built using Xcode 26 with the iOS 26 SDK or later, a requirement worth confirming before you archive rather than discovering after an upload gets rejected outright.

Keeping these two version numbers straight trips up more first-time submitters than it should. The user-facing version is what appears in the App Store and what users see when checking if an update is available, while the build number is an internal counter that needs to increment with every single upload, even minor ones, regardless of whether the user-facing version changed. Reusing a build number Apple has already seen, even for a genuinely new upload, will get that submission rejected before a reviewer ever looks at the app itself.

Step 8: Submit for Review

What Happens During Apple’s Review

Once your build finishes processing on Apple’s servers, typically after a malware scan and automated validation pass, select it in App Store Connect and submit for review, which generally takes 24 to 72 hours and involves a real person manually testing your app against Apple’s guidelines, not just an automated scan. Apple blocked nearly 2 million risky submissions from reaching users in a recent year alone, a scale that explains why the review process remains genuinely thorough rather than a formality.

That human element is worth planning around specifically. Two apps that look nearly identical on paper can receive different reviewer feedback depending on details an automated system would never catch, a confusing test account flow, a screen that reads as misleading even if unintentionally, content that sits in a gray area of the guidelines. Providing clear, specific notes for the review team in the App Review Information section, working test credentials, and context about anything that might not be immediately obvious from just using the app, genuinely reduces the odds of a rejection based on a reviewer misunderstanding something your app actually does correctly.

Why Apps Actually Get Rejected

The most common, avoidable rejection reasons trace back to incomplete submission materials, not broken functionality: a missing or inaccessible privacy policy URL, test credentials the review team can’t actually use to access a login-gated feature, incorrectly sized screenshots, or privacy labels that don’t match what the app’s code actually does. Gathering every required asset and piece of information before you open App Store Connect, rather than discovering a gap mid-submission, is what separates a smooth first-attempt approval from a frustrating multi-cycle back and forth.

Step 9: Choose How Your App Releases After Approval

Once approved, choose between automatic release, where your app goes live the moment Apple approves it, manual release, where you control the exact go-live moment yourself, or a phased release that gradually rolls your update out to a percentage of users over time rather than everyone at once. A phased release is particularly worth using for major updates, since it limits exposure if an unexpected issue only surfaces once real users at scale start using the new version.

Manual release specifically matters more than it might seem for a launch tied to any external timing, a press announcement, a product launch event, a coordinated marketing push. Approval and public availability aren’t the same moment unless you choose automatic release, and a team that assumes they are can find their app live before the announcement meant to introduce it, an avoidable mismatch that a five-minute setting change prevents entirely.

Using Custom Product Pages to Test Your Listing

App Store Connect allows up to 35 unique custom product pages per app, each with different screenshots and descriptions and its own shareable URL, letting you run targeted campaigns or test which store listing variant actually converts better before committing to one as your primary listing. This is a genuinely underused feature for a step most developers treat as a one-time task rather than something worth testing and iterating in the same way they’d test any other part of their funnel.

A practical use case worth considering: if your app serves genuinely different audiences, a consumer version and a business version of the same core product, for example, custom product pages let you tailor the screenshots and messaging to each audience without maintaining two separate app listings entirely. Treating your App Store listing as a living asset worth optimizing after launch, rather than a form filled out once and never revisited, is a real opportunity most teams leave on the table simply because they don’t realize the feature exists.

If you’re weighing this entire submission process against how the equivalent Android process works, the contrast is worth understanding before you commit engineering time to both platforms simultaneously.

iOS app development in USA partners specifically bring the advantage of having navigated Apple’s review process repeatedly for the US market, catching the kind of submission-specific details that trip up teams going through this for the first time.

Frequently Asked Questions