How to Publish an App to the App Store: The 2026 Step-by-Step Guide

Publishing an app to the App Store is not hard, but it is specific. The specificity is where first time submitters get stuck. This guide covers the whole arc, from signing up for an Apple Developer account to hitting submit for review, with the common mistakes and rejection reasons surfaced so you don't have to learn them the painful way.

Nothing here assumes you wrote any code yourself. We'll note where the process differs between "I built this by hand in Xcode" and "I built this with an AI app builder and have a GitHub repo."

Before you start: the prerequisites

Three things have to be true before you can submit anything.

1. You have an Apple Developer Program membership. This costs $99 per year. Sign up at developer.apple.com. You need a valid photo ID (passport or driver's license) and a credit card. If you're enrolling as an organization rather than an individual, you also need a D U N S number (free to get, takes a few days if you don't have one yet).

2. You have a working build of your app. If you built with an AI app builder, you already have this in the form of a GitHub repo. If you built by hand, you have an Xcode project that compiles to a device.

3. You have the app store metadata ready. Name, description, keywords, screenshots, icon, privacy policy URL, support URL, age rating answers. More on each of these below.

Don't skip to step two. A week trying to get your D U N S number while your build is ready is a real situation that happens to people.

Step 1: Create the app in App Store Connect

App Store Connect is Apple's portal for managing your apps. Different from developer.apple.com, which is where you manage certificates and your developer account itself. You'll end up using both.

Go to appstoreconnect.apple.com. Click "My Apps." Click the plus button to create a new app.

You'll be asked for:

• Platform. iOS, tvOS, macOS, visionOS. Most of this guide assumes iOS.
• App name. What shows up in the App Store. Maximum 30 characters. Can be different from the name inside your app if you want (though usually they match).
• Primary language. The main language your app is in.
• Bundle ID. This is the unique identifier for your app. Usually reverse domain style, like com.yourname.appname. You create this first in developer.apple.com under "Identifiers," then it appears in the Bundle ID dropdown here. Once you submit, you cannot change this. Pick carefully.
• SKU. An internal identifier for you. Users don't see it. Can be anything.

Hit Create.

Step 2: Fill in the app listing

Inside the app you just created, you'll see a lot of fields. Here's what each one is and how much it matters.

Name. What you entered in step 1. You can change it in later submissions but it needs to approximately match the name on your icon and inside the app, or Apple rejects for misleading branding.

Subtitle. 30 character tagline that appears under the name. Very valuable for keywords and for telling the user at a glance what the app does. "Daily habit tracker for friends" is better than "Habits made easy."

Promotional text. 170 characters that can be updated without submitting a new build. Use this for seasonal messages ("New in April") or launch push. Less critical than description or subtitle.

Description. Up to 4,000 characters. This is the long form pitch. Apple does not index this for search (only the subtitle and keywords are indexed), so write it for humans, not algorithms. Structure: one sentence pitch, three to five bullet points of features, one line about who it's for.

Keywords. 100 characters separated by commas, no spaces. This is what Apple's search actually looks at. Put your most important terms here, do not waste characters with your own app name (it's indexed automatically), and do not include competitor names (Apple rejects for this).

Support URL. A URL you own where users can contact you. Can be a simple contact page. Required.

Marketing URL. A URL for your product. Optional but include it.

Privacy policy URL. Required. Must actually be a privacy policy. We'll cover this below.

Copyright. Usually something like "2026 Your Name or Company."

Step 3: Upload screenshots and an icon

This is where first time submitters spend longer than expected.

Icon requirements. A 1024 by 1024 PNG with no transparency and no rounded corners (Apple rounds them automatically). RGB color space. No alpha channel.

Screenshot requirements. Apple currently requires screenshots for these device sizes:

• 6.7 inch display (iPhone Pro Max): 1290 by 2796 pixels
• 6.5 inch display (iPhone 11 Pro Max): 1284 by 2778 or 1242 by 2688 pixels
• 5.5 inch display (iPhone 8 Plus): 1242 by 2208 pixels
• iPad Pro 12.9 inch (if your app supports iPad): 2048 by 2732 pixels
• iPad Pro 11 inch: 1668 by 2388 pixels

You need at least one screenshot per required size, up to ten. Apple shows the first three in search results and on the product page above the fold, so make those three count.

You can use the iOS Simulator to generate raw screenshots, then compose them in Figma or a dedicated tool (Rotato, Screenshot.rocks, App Mockup). The overlay text on App Store screenshots ("One tap to log a habit") matters. It converts. Good screenshots can double install rates on a listing with otherwise identical metadata.

Step 4: Age rating and content questions

Apple asks a set of yes or no questions about your app's content: violence, gambling, adult themes, user generated content, medical or health advice, and so on. Answer honestly. Apple spot checks and if they find you lied, they pull your app.

If your app has any user to user messaging or posting, you will be required to add a content reporting mechanism and a blocking mechanism before Apple will approve. This is a 2022 rule that still trips up a lot of submitters. Build these from day one if you have any UGC surface.

Step 5: Privacy

Apple has two privacy related requirements that have gotten stricter over the last few years.

Privacy policy URL. Must be a real, hosted privacy policy. If your app is simple (no account, no tracking, no third party SDKs), you can use a free generator like iubenda or write your own. If your app has any complexity, get a lawyer to review. A bad privacy policy is a real legal liability, separate from App Store approval.

Privacy nutrition labels. Inside App Store Connect, under Privacy, you answer a detailed questionnaire about what data your app collects, why, and whether it's linked to the user. Apple generates a summary card from your answers that shows up on your listing.

Be accurate here. Apple cross checks against the actual SDKs in your binary. If you say "we don't collect location" and Apple sees the Core Location framework in your build, they reject.

Common trips:

• You used Firebase Analytics. That's tracking. Disclose it.
• You used Sentry or another error logging service. That's diagnostic data. Disclose it.
• You used a third party login (Google, Apple, Facebook). Disclose that authentication data is collected.

Step 6: App Tracking Transparency

If your app uses any SDK that tracks users across other apps or websites (including ad networks like AdMob), you must present the App Tracking Transparency prompt before you collect or share tracking data. Apple added this in iOS 14.5. Failing to implement it is an automatic rejection.

If you built with an AI app builder, the relevant NSUserTrackingUsageDescription string should already be in your Info.plist. If it isn't, add it with a clear human readable explanation of why you're asking.

Step 7: Build and upload

This is where building by hand and building with an AI app builder diverge most.

If you built by hand. In Xcode, select "Any iOS Device" as the target, go to Product menu, hit Archive. The archive shows up in the Organizer. Hit "Distribute App," pick "App Store Connect," follow the prompts. Xcode uploads the build.

If you built with an AI app builder. The good ones hide all of this behind one button. In Appsanic you hit Publish, connect your Apple account once (an App Store Connect API key, never your password), and it builds the release in the cloud and uploads it straight to TestFlight for you. No terminal, no .ipa to move around. Prefer to do it yourself? The project comes with an eas.json, so you can still run eas build --platform ios and eas submit from a terminal.

Either way, the build appears in App Store Connect under the "TestFlight" tab within 15 minutes to an hour. You're not done yet.

Step 8: TestFlight (optional but highly recommended)

Before you submit for public review, let real people use the app on their phones. TestFlight is Apple's beta distribution tool and it's free.

Inside App Store Connect, go to TestFlight. Your uploaded build will be there. Add testers (internal testers are on your team, up to 100; external testers can be anyone with an email, up to 10,000). External testers require a onetime review from Apple ("beta app review") that usually takes 24 hours.

Get 5 to 20 real people to use the app for a few days. Watch what they do. Fix the bugs they find. Iterate. This is where you catch the issues that reviewers won't catch and users will.

Apps that skip this step usually come back with embarrassingly obvious bugs in their App Store reviews.

Step 9: Submit for review

Inside the app listing, pick the build you uploaded, confirm all fields are filled, agree to the App Review Guidelines, and hit "Submit for Review."

Apple's review takes 24 to 72 hours for most apps. Expedited review is available but reserve it for real emergencies (security patch, ongoing crash, etc.). Requesting expedited review for "we want to launch Monday" can burn your credit with them.

Common rejection reasons

The top five that catch first time submitters.

1. Crashes. Apple tests on at least one device. If it crashes on launch, rejected.

2. Guideline 4.3: Design spam. If your app looks like a thin template, very little content, or copies of other apps, rejected. Don't submit a reskinned tutorial.

3. Guideline 5.1.1: Privacy. Asking for permissions you don't need, missing privacy policy URL, or broken privacy nutrition labels.

4. Guideline 2.1: Incomplete app information. Something in your listing references a feature that doesn't work, a test account that Apple can't log into, or metadata that doesn't match the app.

5. Guideline 4.8: Sign in with Apple. If you offer any third party login (Google, Facebook, etc.), you must also offer Sign in with Apple. Period. Even if you don't want to.

When Apple rejects, they send a specific guideline reference and usually a screenshot or description of the problem. Address the specific issue, reply via the Resolution Center, and resubmit. Most first rejections are fixable in under an hour.

What happens after approval

You get an email: "Your app has been approved." At this point your app is either live immediately or live on a date you chose in App Store Connect (you can schedule releases).

Your app now has a product page. People can search for it. You can share the link. If you're launching publicly, this is when you light up your marketing.

Version 1 is live. Version 2 is a repeat of all of the above, with fewer first time mistakes. Updates generally clear faster than first submissions, usually 12 to 48 hours.

Frequently asked questions

How long does App Store review take in 2026? Most apps clear in 24 to 72 hours. Complex apps or first submissions from new developers can take up to a week. Expedited review is available for emergencies.

What's the Apple Developer Program fee? $99 per year. Required to publish to the App Store. There's a separate $299 per year Enterprise program for internal distribution, but most people don't need it.

Do I need a Mac to publish an iOS app? For building by hand, yes. For AI app builders that use EAS cloud builds, technically no, you can do everything from a Windows or Linux machine. But a Mac still helps for Safari debugging and iOS Simulator work.

Can I publish to the App Store as an individual or do I need a company? Both work. Individual accounts show your personal name on the App Store. Organization accounts show your company name and require a D U N S number.

What if my app gets rejected? Read the specific guideline reference Apple cites, fix the issue, reply in the Resolution Center (or resubmit with notes), and Apple reviews again. Most rejections clear on the second submission.

Can I use the same build for iOS and Android? If you used React Native, Flutter, or Expo: yes, one codebase, two builds. For native Swift or Kotlin, you'd maintain two separate codebases.

Do I need to submit updates to the App Store? Yes, for any change that modifies the app's binary. For content only changes (remote config, text updates, remote images), you can release without a new submission.

How much does Apple take from sales? 15 percent for the first $1 million of annual revenue (Small Business Program), 30 percent after. For subscriptions longer than a year, the rate drops to 15 percent after year one.

The summary

Publishing to the App Store is mostly a paperwork exercise once your app is built. The build is the hard part. The submission is the part that feels hard the first time and becomes routine the third time. Go slow the first time. Screenshot the review process if you want to remember it. By your second submission, it takes 30 minutes.