A practical walkthrough of archiving, signing, and uploading your iOS app to App Store Connect using Xcode, then submitting it for review.
Submitting an app to the App Store is the final, official step of iOS development, and Xcode is the tool that gets you there.
Before you start, you need a few things in place. You must be enrolled in the Apple Developer Program, which is a paid annual membership required for App Store distribution.
You also need an app record created in App Store Connect, with a bundle identifier that matches your Xcode project.
Finally, your app should be tested, your version and build numbers set, and your app icons and required metadata ready. With those in hand, the Xcode process is straightforward.
Sign in to App Store Connect with your Apple Developer account and create a new app record under the My Apps section.
You will provide the app name, primary language, bundle identifier, and an SKU. The bundle identifier must exactly match the one in your Xcode project.
While you are there, you can begin filling in the listing: description, keywords, screenshots, support URL, and privacy details. Some of this can be completed later, but the app record must exist before you upload a build.
Keep App Store Connect open in a browser tab; you will return to it after the Xcode upload completes.
In Xcode, select your app target and open the General and Signing & Capabilities tabs.
Confirm your version (the user-facing number) and build (an internal incrementing value). Each upload to App Store Connect needs a unique build number.
Under Signing & Capabilities, make sure a valid team is selected. Automatically manage signing is the simplest path; Xcode will handle distribution certificates and provisioning profiles for you.
Double-check the bundle identifier matches your App Store Connect record, and confirm your deployment target and supported devices are correct for the app you intend to ship.
Archiving requires building for a real device architecture, not the Simulator. In the run destination menu, choose Any iOS Device (arm64) rather than a specific simulator.
Then go to Product > Archive. Xcode performs a release build and creates an archive, which is a packaged, signed version of your app suitable for distribution.
This build can take longer than a normal run because it is a full optimized release build. When it finishes, the Organizer window opens automatically and shows your new archive.
If Archive is grayed out, it is almost always because a simulator is still selected as the destination. Switch to Any iOS Device and try again.
In the Organizer, select your archive and click Validate App. Validation checks your build against many App Store requirements before you upload.
Xcode will ask about distribution options, signing, and may run a series of checks. Validation can catch issues like missing icons, invalid entitlements, or signing problems early.
Fixing problems at validation is much faster than discovering them after upload or during App Review. Read any warnings carefully.
When validation succeeds, you are ready to distribute. If it fails, address the reported issues in your project and create a new archive.
Back in the Organizer, select the validated archive and click Distribute App.
Choose App Store Connect as the distribution method, confirm your signing options, and let Xcode prepare and upload the build. Automatic signing handles most of this for you.
The upload sends your build to App Store Connect, where Apple processes it. Processing can take anywhere from a few minutes to longer, and you may receive an email when it completes.
Once processing finishes, the build appears in App Store Connect, ready to be attached to a version or used in TestFlight.
Return to App Store Connect and open your app's version page. Select the build you just uploaded under the Build section.
Complete all required metadata: screenshots for the required device sizes, description, keywords, support and privacy URLs, age rating, and App Privacy details.
When everything is filled in, click Add for Review and then Submit. Your app enters Apple's App Review queue.
Review times vary. If Apple finds an issue, you will receive feedback in App Store Connect, and you can respond or upload a fixed build. Once approved, you control when the app goes live.
Before submitting for public release, many teams distribute the same uploaded build through TestFlight first. TestFlight is Apple's official beta testing service, built into App Store Connect.
Once your build finishes processing, you can invite internal testers from your team or external testers via email or a public link, and they install your app through the TestFlight app.
This lets real people exercise the app on real devices before it reaches the store, catching crashes and usability issues you might miss in the Simulator.
External TestFlight builds go through a lighter Apple review, so plan a little lead time. Using TestFlight is optional, but it is a low-cost way to ship with more confidence.
A surprising number of rejections come from incomplete metadata rather than code. Missing screenshots for a required device size, a broken support URL, or an unfinished privacy section will all hold up a submission.
App Privacy details are mandatory. You must declare what data your app collects and how it is used, and inaccuracies here can cause rejection.
Build-number collisions are another frequent stumble. If you forget to bump the build number, App Store Connect refuses the upload, so increment it for every new archive.
Finally, read Apple's App Review Guidelines for anything unusual your app does. Knowing the rules before you submit is far cheaper than discovering them through a rejection.
This entire pipeline assumes a native app. Archiving, signing, and uploading all depend on Xcode and Apple's toolchain.
AI-powered web app builders are useful for prototyping and shipping web experiences, but they typically produce web or React code rather than native Swift.
A web app cannot be archived and submitted as a native iOS app the way described here. To put a genuine native app on the App Store, the build must go through Xcode.
So even if you design and validate a concept with other tools, plan for this Xcode submission flow as the real path to the App Store.
Archiving requires a device build target. Select Any iOS Device (arm64) instead of a simulator in the run destination menu, then Product > Archive will be available.
Yes. App Store distribution requires enrollment in the paid Apple Developer Program. A free account can run apps on your own device but cannot publish to the store.
The version is the user-facing release number, while the build is an internal value that must increase with each upload. App Store Connect rejects duplicate build numbers.
Not as a native app through this flow. AI web builders output web code; a native iOS app must be compiled, signed, and uploaded via Xcode and Apple's toolchain.