How to publish your app on the App Store

Shipping an app to the App Store has two parts: building something people can use, and helping Apple understand exactly what you’re asking it to review. App Store Connect is where those two parts meet. The first trip through it can feel like a maze of forms, but the process gets much clearer once you know what each step is for.

Here’s a practical walk from enrolling in Apple’s developer program to releasing your first version, then sending an update. Apple changes screens and requirements over time, so use this as a map and check the linked Apple documentation when you submit.

Start with the right developer account

To distribute an app on the App Store, join the Apple Developer Program. You can enroll as an individual or as an organization. With an individual membership, your legal name appears as the seller. With an organization membership, the organization’s legal name appears instead.

For an organization, Apple checks that the business is a legal entity and asks for its D‑U‑N‑S Number, a work email tied to the organization’s domain, and a public, working website. An individual needs an Apple Account with two-factor authentication, a legal name, and real contact details. Apple lists the membership at US$99 per year, with local pricing and some fee waivers available.

Think about the seller name before enrolling. If you want the company name on the store page, choosing an individual account and hoping to change it later is a poor shortcut. Get the legal entity and enrollment details in order first. After Apple verifies the information, the Account Holder accepts the program agreement and completes enrollment.

Make the app record before you upload a build

In App Store Connect, open Apps and choose the plus button, then New App. Apple requires an app record before it can associate an uploaded build with your app. You don’t need to have finished the app in Xcode to create this record, but you do need an active membership and the latest required agreements signed.

You’ll choose the platform, app name, primary language, bundle ID, and an internal SKU. The app record setup asks for a bundle ID that must match the one in your Xcode project, and you can’t change it after uploading a build. The SKU is just your own identifier for tracking; customers won’t see it. Pick both carefully, especially the bundle ID, because rebuilding around a mistaken identifier can cost time.

If you work with a team, give each person only the App Store Connect role and app access they need. The Account Holder owns the membership and agreements; other roles can handle app management, development, marketing, or finance tasks. An app record’s initial status is Prepare for Submission, which is your workspace for the product page and release details.

Give the product page the same care as the app

Before review, fill in the product information that tells people what the app does and what they can expect. That includes a description, keywords, category, age-rating answers, support information, privacy policy, screenshots, and any required pricing and availability details. Your name and subtitle have tight character limits, so use them to describe the product clearly rather than stacking search terms.

For screenshots, show real app screens and make the sequence tell a simple story: what the app is for, how it works, and what a user gets from it. Apple allows one to ten screenshots in supported formats. App previews are optional. Avoid placeholder content, simulated controls that don’t exist, or captions promising features the submitted build doesn’t contain. The product page is part of the review experience too.

Set the age rating honestly by answering the questionnaire about content and features. Add a privacy policy URL, then complete App Privacy details for data your app and its third-party SDKs collect. These answers appear on the product page, and Apple expects them to match the app’s actual practices. “We don’t collect data” is only right if your app and its integrated partners don’t collect data covered by Apple’s definitions.

Also check content rights, price, tax category, and the countries or regions where you plan to offer the app. If you use encryption, answer export-compliance questions accurately; ordinary use of Apple’s built-in networking encryption is often exempt from extra documentation, but don’t guess about a custom crypto library. The relevant answers depend on what your app and its dependencies actually do.

Test the build as if you were the reviewer

Upload a release build from Xcode, Transporter, or another supported workflow. App Store Connect uses the bundle ID and version number to associate it with the app and version record, while the build number distinguishes uploads. After upload, wait for Apple’s processing to finish before expecting the build to appear in the version page.

Apple’s App Review Guidelines focus on a safe, trustworthy experience: a working app, accurate claims, appropriate privacy practices, legal content, and a clear user experience. Common trouble spots include crashes, broken links, a login the reviewer can’t get past, missing demo credentials, unavailable backend services, incomplete purchases, and a product page that describes behavior the app doesn’t have. An app that feels like a thin website wrapper or offers too little lasting utility can also run into the minimum-functionality guideline.

In the review notes, tell Apple what to test, how to reach important features, and which credentials or sample data to use. Explain anything that might look unusual from the outside. A reviewer shouldn’t have to guess where the app’s main value is.

Submit, then choose when the app goes live

On the version page, select the build you intend to ship and confirm the required metadata is complete. Choose a release setting: release automatically after approval, hold for a manual release, or release no earlier than a date you choose. Manual release gives you a final timing decision after approval; automatic release removes that extra step.

There are two buttons in the submission flow that are easy to mistake for one. Add for Review prepares the draft; Submit for Review sends it to Apple. After adding it for review, open the draft and choose Submit for Review. Watch the status in App Store Connect and reply to questions in the App Review section. Approval is not the same as the app already appearing in every storefront; allow time for the release to become available.

For a first launch, consider distributing through TestFlight first. It gives a small group a chance to use the actual release candidate and report confusing flows or bugs before customers see it. It can’t guarantee approval, but it can catch problems that are easier to fix before review.

An update starts with a new version, not a new app

Once the current version is Ready for Distribution, create a new version from the same app record. Increase the App Store version number, update the build number in Xcode, upload the new build, and attach that build to the version. App Store Connect carries the previous version’s metadata forward, so review it instead of assuming it is still accurate.

Write “What’s New in This Version” for the person updating: describe the changes, fixes, or improvements they’ll notice. Review screenshots and privacy details too. If the update changes what data the app or its SDKs collect, update the privacy answers so they describe the new version. Apple reviews updates as well as first releases; approval of an earlier build doesn’t exempt new code or changed behavior from review.

Submit the update through the same review flow. For automatic updates, you can optionally use a phased release that rolls out over seven days. That can give you time to notice a serious issue as adoption grows, although it doesn’t slow down users who manually choose to update. If a release needs to stop, pause the phased rollout while the option is available and prepare a fix as a new version. Apple doesn’t let you roll the store back to an older version.

When Apple says no, treat the message as a diagnosis

A rejection is a request to resolve a specific issue, not a verdict on the whole idea. Read the message and guideline reference, reproduce the problem, then either correct the app or explain the behavior with clear steps and evidence. You can reply to App Review in App Store Connect; for a metadata-only issue, Apple may allow the same build to be resubmitted after you fix the information.

Keep a release checklist for each version: correct bundle and build, stable backend, working sign-in and purchases, accurate screenshots and descriptions, complete review notes, privacy details that match the shipped code, and a release setting you understand. Remove surprises before the reviewer has to find them. Apple wants to be able to verify that what you submit works, says what it does, and treats people fairly.

Once the first release is out, the path gets more familiar: build, test, describe what changed, answer what’s new, submit, and pay attention to the review conversation. Then you can spend more of your time making the app better for the people who opened it.