How to Submit an App to the App Store: 2026 Guide

If submitting an app to the App Store took one button, you would not need this article and I would already be on the couch with an ice-cold beer. This 2026 guide covers how to submit an app to the App Store for a new iPhone or iPad app. It explains what you need before you start, how to get a release build from Xcode into App Store Connect, and what App Review checks.

This guide focuses on new iPhone and iPad apps submitted through Xcode. macOS, tvOS, visionOS, and watchOS follow the same broad App Store Connect workflow, but have their own SDK and screenshot requirements.

What you need before you start

You need more than a finished .xcodeproj and a brave click on the upload button. Before opening App Store Connect, make sure you have the right account, tools, agreements, and a release-ready build.

An Apple Developer Program membership

A free Apple developer account lets you use Xcode and test apps on your own devices. App Store distribution requires membership in the Apple Developer Program. Apple lists the membership at $99 per year, or the equivalent local price where available. That bill is not optional.

You can enroll as an individual or an organization. Individual enrollment puts your legal name on the store as the seller. Organization enrollment puts the company name there instead, after Apple verifies the company.

The person submitting the app also needs an appropriate App Store Connect role. Apple currently permits the Account Holder, Admin, or App Manager roles to submit an app for review, according to its submission instructions. If you can see the button but cannot press it, that is usually permissions.

Current Xcode and SDK versions

Apple updates its minimum SDK requirements regularly. As of April 28, 2026, iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 26 SDK or later. Apple lists the current requirements for each platform on its Submitting page.

I still check that page before every upload, because my muscle memory updates slower than Apple’s. A perfectly functional app built with an unsupported SDK cannot be uploaded.

Agreements, tax, and banking details

The Account Holder must accept Apple’s latest agreements before the team can create and distribute apps. If you plan to charge for the app or sell digital content through in-app purchases, complete the Paid Apps Agreement and provide the required tax and banking information in the Business section of App Store Connect. Apple describes this as part of the official App Store Connect workflow.

Do this early. Waiting until submission day can delay your release while you complete the required financial details.

Prepare your app for App Review

Apple reviews the binary, its metadata, and the experience a reviewer can access. A green archive does not mean the product is ready to ship.

Treat “ready for review” as a product state, not merely a build configuration.

Test the final build on real devices

Run the release candidate on the devices and OS versions you support. Test first launch, onboarding, sign-in, account recovery, purchases, permission requests, offline behavior, and any feature that depends on your backend. If it only works on your phone, it only works on your phone.

Apple’s App Review Guidelines say submissions must be final, tested on-device, and free of placeholder content. Guideline 2.1 also warns that incomplete binaries, crashes, broken links, and inaccessible features can prevent approval. “Lorem ipsum” is not a feature, even if the typography is excellent.

Test the same archive you intend to upload. Debug and release configurations can use different services, entitlements, compiler settings, or environment values.

“It worked in Debug” is useful diagnostic information, but not a store strategy.

Review signing, identifiers, and version numbers

In Xcode, confirm:

• The bundle identifier is unique and matches the App Store Connect record.
• The correct Apple Developer team is selected under Signing & Capabilities.
• Every target has the capabilities and entitlements it needs.
• The marketing version is the version customers should see.
• The build number is higher than previous uploads for that version.
• The app icon is included in the asset catalog.
• The deployment target and supported devices are intentional.

Xcode can manage signing automatically for most projects. Whichever signing method you use, archive the app without signing errors before moving on.

Check privacy requirements

Every app needs accurate App Privacy details in App Store Connect. These answers include the data practices of third-party code you include. Apple says they are required for new apps and updates on its submission overview. “We do not collect anything” is a lovely sentence. Confirm it against the SDKs before you publish it.

Your binary may also need a privacy manifest named PrivacyInfo.xcprivacy. The manifest records data collection, tracking domains, and uses of Apple’s required-reason APIs. Check your own code and each bundled SDK. Update SDKs that do not meet Apple’s third-party SDK requirements.

The privacy manifest and the App Store privacy label are related, but they are not interchangeable. One travels inside the binary. The other is information you enter in App Store Connect. Make sure they describe the same real behavior, not two equally confident guesses.

Apple’s Guideline 5.1.1 requires every app to include an accessible privacy policy both in App Store Connect and inside the app. The policy must explain what data the app collects, how it uses that data, its sharing practices, and its retention and deletion policies. Linking to a blank Notion page is, sadly, not a policy.

Handle account creation and login correctly

If users can create an account in the app, Apple’s Guideline 5.1.1 requires you to let them initiate account deletion inside the app. A logout button does not delete an account, despite its admirable work ethic.

If you use a third-party or social login service for the user’s primary account, review Guideline 4.8. It generally requires an equivalent login option with specific privacy characteristics, subject to the exceptions Apple lists there.

Also prepare a demo account for App Review if the app requires sign-in. Give it realistic sample data and access to every feature under review. Keep its backend services running for the entire review, including weekends. Reviewers do work then too, somehow.

Verify purchases and subscriptions

If the app includes in-app purchases or subscriptions, configure the products in App Store Connect and make them available to the reviewer. Test purchase, restore, renewal, cancellation, and entitlement behavior with Apple’s sandbox tools. Sandbox receipts are odd. They are still better than “it works on my credit card.”

Guideline 2.1 says in-app purchase items must be complete, current, visible, and functional. If a product is difficult to find or needs a particular sequence, explain that sequence in the review notes. Reviewers are talented, not telepathic.

Create your app in App Store Connect

You must create an app record before uploading its first build. Apple confirms this ordering in its App Store Connect workflow.

1. Sign in to App Store Connect.
2. Open Apps.
3. Click the + button.
4. Choose New App.
5. Select the platform or platforms.
6. Enter the app name, primary language, bundle ID, and SKU.
7. Choose the users who should have access.
8. Click Create.

The bundle ID must match the identifier in Xcode. The SKU is an internal identifier and is not shown to customers. You can name it something useful instead of something poetic. Apple’s Add a new app documentation explains the available fields and required roles.

After creation, the record appears with a Prepare for Submission status. You can start filling in its information before the binary is ready, but recheck it if the product changes.

Set pricing and availability

Choose whether the app is free or paid, where it should be available, and how you want to release it. If the app is paid, the required business agreements must already be active.

For the release method, you can let Apple release the app automatically after approval, release it manually, or schedule eligible releases. Manual release is useful when your website, support team, or launch announcement must go live at the same time. Automatic release is useful when you enjoy surprises.

Build your App Store product page

The product page is your store listing and part of what Apple reviews. Its promises must match what the submitted build does. Marketing copy that describes a future app is still, in Apple’s view, a lie.

Add accurate metadata

Complete the required fields for each localization:

• App name and subtitle
• Description
• Keywords
• Category
• Support URL
• Privacy policy URL
• Copyright
• Version information
• App Review contact details

Apple’s Guideline 2.3 requires accurate metadata. Screenshots, previews, descriptions, privacy information, and listed features must reflect the real app experience. If the screenshot shows a dashboard the build cannot open, that is not “aspirational.” That can cause a rejection.

Avoid promising work-in-progress features. Do not add competitor names, unsupported superlatives, or unrelated search terms to the metadata. Apple limits app names to 30 characters and expects keywords to describe the app accurately, as stated in Guideline 2.3.7.

Upload screenshots and the app icon

Use screenshots captured from the current version of the app. They should demonstrate meaningful screens and features rather than showing only a splash screen or sign-in form. A beautiful launch screen is still just a beautiful launch screen.

App Store Connect shows the screenshot sets required for the devices your app supports. Apple’s screenshot specifications change as supported devices evolve. Check the current dimensions in App Store Connect instead of copying sizes from an old article. Last year’s pixel counts are folklore.

Your build normally supplies the App Store icon through its asset catalog. Confirm that it looks clear at small sizes and does not include transparency or pre-rounded corners. Apple would like to round those corners itself, and it will.

Complete the age rating

Answer the age-rating questionnaire based on the app’s content and capabilities. Apple updated its age-rating system for the 2026 platform releases and displays the resulting rating in the App Information section, as described on its Submitting page.

Do not choose the rating you would prefer for marketing. Choose the rating supported by the content users can actually encounter, including user-generated content and unrestricted web access.

Complete App Privacy details

In the App Privacy section, disclose:

• The data your app and integrated partners collect
• Whether that data is linked to a user
• Whether it is used to track users
• The purposes for which each data type is collected

Audit the final build rather than answering from memory. Analytics, advertising, authentication, crash reporting, and support SDKs can all affect the disclosure.

Give App Review everything it needs

In App Review Information, provide a current contact person, review notes, and demo credentials when necessary. Explain unusual navigation, required hardware, region-specific behavior, or steps needed to reach a feature. If a feature hides behind a long-press on a setting nobody would guess, write that down.

Apple says missing settings, account information, or special instructions can delay review or cause the submission not to pass. Its App Review guidance recommends a demo video or hardware arrangements when a feature depends on an environment the reviewer cannot easily reproduce. Reviewers do not have your Bluetooth thermometer, office Wi-Fi, or patience.

Keep notes short but specific. A reviewer should be able to answer three questions quickly: How do I get in? Where is the feature? What special setup does it need?

Upload your build with Xcode

Once the app is configured and tested, create an archive and send it to App Store Connect.

1. Open the project or workspace in Xcode.
2. Select the app’s release scheme and a generic or eligible device destination.
3. Confirm the version, build number, signing team, and bundle identifier.
4. Choose Product → Archive.
5. Wait for Xcode Organizer to open.
6. Select the archive and choose Distribute App.
7. Select the App Store Connect distribution option.
8. Validate the archive and review any warnings.
9. Upload the build.

Processing continues after the upload finishes. The build appears in App Store Connect after Apple processes it. Apple may email you about binary or privacy-manifest problems it finds during processing. That email is never as exciting as it sounds.

Fix warnings you can act on before submitting. If a fix changes the binary, increment the build number, archive again, and upload the replacement. Reusing a build number can make App Store Connect ignore your new binary.

Teams with automated release pipelines can also upload builds and manage parts of the workflow through Apple’s tooling and the App Store Connect API. For a first submission, Xcode Organizer is usually the clearest option because it shows signing and validation problems directly.

Test with TestFlight before you submit

TestFlight is Apple’s beta distribution service. It lets you share processed builds with internal and external testers before publishing on the App Store. Apple supports up to 10,000 external testers, according to the Apple Developer Program overview. You do not need 10,000. You need one person who did not write the onboarding.

At minimum, install the processed build from TestFlight yourself. This confirms that the uploaded artifact launches and can reach its production services. That is a low bar, but it still catches real problems.

Ask someone who did not build the app to test its main user flow. They are more likely to find assumptions hidden in onboarding, permissions, empty states, or reviewer instructions. When you know the app well, your mind can fill in missing steps.

Use feedback and crash reports to fix release-blocking issues. Then upload a new build and select it for the App Store version. The build you meant to submit is not always the one currently selected. Double-check.

Submit the app for review

When the build and listing are ready:

1. Open the app in App Store Connect.
2. Select the version you want to submit.
3. Scroll to the Build section and select the correct build.
4. Resolve any remaining required fields or compliance questions.
5. Click Add for Review.
6. Open the draft submission and check every included item.
7. Click Submit for Review.

The distinction between the last two buttons matters. Apple’s official submission instructions say Add for Review moves the item into a draft submission; it does not send the app to reviewers. Submit for Review sends that draft. I have celebrated at the wrong button before, and I’m not embarrassed to admit it.

Depending on the app, App Store Connect may ask about export compliance, content rights, advertising identifiers, encryption, or other regulatory details. Answer based on the shipped binary and the territories you selected, not on the vibe of the feature set.

What happens after submission?

App Store Connect shows the submission status and emails the team when it changes. A normal path moves through states such as Waiting for Review, In Review, and an approved or developer-release state. Refreshing the page does not make reviewers faster. I have tested this.

Apple says that, on average, 90% of submissions are reviewed in less than 24 hours. That is an average, not a deadline. Incomplete information and apps requiring additional investigation can take longer, according to Apple’s review-status guidance.

If you chose automatic release, the approved app moves toward publication. If you chose manual release, App Store Connect waits for you to release it. That is the one waiting period in this process you control.

If Apple rejects the app

A rejection asks you to resolve a specific review issue. It does not mean the launch is doomed. Read Apple’s message and the cited guideline before changing anything. Especially before changing everything.

Then:

1. Reproduce the reviewer’s path when possible.
2. Decide whether the issue is in the binary, metadata, configuration, or reviewer access.
3. Ask a concise question in App Store Connect if the message is unclear.
4. Fix the issue and explain the change in your reply or review notes.
5. Upload a new build if the binary changed.
6. Resubmit.

You can communicate with App Review from the app’s App Review page. If you believe Apple misunderstood the app and discussion does not resolve the issue, Apple also provides an appeal process through the App Review Board. Use an appeal as a second step, not a first reaction.

Expedited review is reserved for extenuating circumstances, such as a critical bug fix or an app tied directly to an imminent event. Apple asks developers to include the relevant reproduction steps or event details when making an expedited review request. “We announced it on Twitter” is not, by itself, an imminent event.

Pre-submission checklist

Before the final click, verify this list. It is long because Apple appreciates thoroughness.

• Developer membership and agreements are active.
• The app uses Apple’s currently accepted SDK.
• Bundle ID, version, and build number are correct.
• The release build works on supported devices.
• Production APIs and sign-in services are online.
• Privacy details match the app and its SDKs.
• The privacy manifest contains required declarations.
• The privacy policy is available in the listing and app.
• Account deletion exists when account creation exists.
• Login options meet Guideline 4.8 where applicable.
• Purchases and subscriptions work in the sandbox.
• Screenshots and metadata match the current build.
• Age-rating answers are accurate.
• Demo credentials and review instructions work.
• The uploaded build has been tested through TestFlight.
• The correct build is attached to the version.
• The draft was actually submitted for review.

FAQ

How long does App Store review take?

Apple says 90% of submissions are reviewed in less than 24 hours on average. Some reviews take longer, especially when information is missing or the app needs additional investigation. Leave schedule room for questions, fixes, and resubmission.

Do I need a Mac and Xcode to submit an iOS app?

Apple accepts builds made with its supported SDKs and tools. Xcode on macOS is the standard way to archive, validate, and upload a native iOS app. Hosted build services can run those tools for cross-platform or automated projects, but the resulting binary must still meet Apple’s signing and SDK requirements.

What is the difference between TestFlight and App Store submission?

TestFlight distributes beta builds to testers. An App Store submission sends a selected build and its product-page information to App Review for public distribution. TestFlight testing does not replace App Review.

What should I provide if my app requires login?

Provide a working demo username and password with access to the features under review. Add exact navigation instructions and explain special setup in App Review Information. Keep the account and backend active until review is complete.

Can I change the bundle ID after creating the app?

Treat the bundle ID as permanent. It identifies the app across Xcode, signing, capabilities, and App Store Connect. Verify it before creating the app record and uploading the first build.

What happens if my app is rejected?

Apple sends a message identifying the problem and usually cites the relevant guideline. You can reply through App Store Connect, correct metadata or configuration, upload a corrected binary when necessary, and submit again. Appeals are available when you believe the review decision is based on a misunderstanding. Read the message twice before rewriting the app once.

Can I submit an unfinished app and finish it during review?

No. Apple’s Guideline 2.1 requires final, functional submissions with complete metadata and working URLs. Use TestFlight for beta testing, then submit the finished release candidate. Review is not a pair-programming session.

Conclusion

Submitting an app to the App Store is a series of small checks. Use the current tools, prepare a complete build, create accurate store information, disclose privacy behavior, give the reviewer reliable access, test through TestFlight, and submit the correct build.

A review goes more smoothly when the binary, metadata, privacy disclosures, and reviewer notes all describe the same working app.

Before you submit, check that each piece matches. Then the review team can evaluate what you intend to ship without having to solve a mystery first.

Further reading: App Store Connect checklist and the App Review Guidelines checklist.