How to publish an app on the App Store: the complete walkthrough

Three things, and none of them are code.

An Apple Developer Program membership. "The Apple Developer Program is 99 USD per membership year. Prices may vary by region and are listed in local currency during the enrollment process." Individuals need an Apple Account with two-factor authentication on and must be of legal age of majority in their region; your personal legal name goes on the contracts. Organizations need more: "Your organization must be a legal entity that can enter into contracts with Apple. We do not accept DBAs, fictitious business names, trade names, or branches." — plus a D-U-N-S Number from Dun & Bradstreet for identity verification (government entities excepted). Nonprofits, accredited educational institutions, and government entities can request a fee waiver.

A Mac with Xcode. Builds reach Apple through Xcode, Transporter, the altool command line, or the App Store Connect API — and from 2026 Apple requires Xcode 14 or later for Xcode uploads. Whatever built your app, the archive that goes to Apple is produced on a Mac. (The honest survey of workarounds for people without one is a separate page; for a serious iOS product, the Mac is part of the budget.)

A privacy policy URL and a support URL. Both are required fields in App Store Connect for iOS apps, and the support URL "must lead to actual contact information" — a legal address, an email, or a phone number. A landing page with a contact form is not enough. Have them live before you create the app record, not the night before submission.

Enroll at developer.apple.com or through the Apple Developer app, using the Apple Account that will own the app for its whole life. Organizations: get the D-U-N-S Number first — it is the step most likely to add days, because it involves a third party. The person enrolling becomes the Account Holder and "must have the legal authority to bind your organization to legal agreements"; choose that person deliberately, because every later contract, tax form, and agreement update routes through them.

Once approved, sign the Paid Applications agreement and complete tax and banking information in App Store Connect even if your first version is free. Agreements that are not signed block features silently later — in-app purchases and paid tiers cannot go live until the paperwork is done, and the paperwork takes its own time.

In App Store Connect, add a new app: platform, name, primary language, bundle ID, and SKU. Two of these are permanent. Apple’s reference is explicit: the bundle ID "cannot be changed after uploading a build" and "must match the bundle ID set in your Xcode project"; the SKU "cannot be changed after adding the app." Name and subtitle are limited to 30 characters each (the name must be at least 2), and the name is editable only until you submit — after that it changes with a new version.

Set the age rating (required, app-wide) and the primary category. If the app contains third-party content, the Content Rights declaration asks whether you hold the rights in every region you sell in. If the app is for children, understand that the Kids category is a one-way door: once approved there, every future update must follow Kids guidelines.

In Xcode: set the version and build number, select "Any iOS Device" as the destination, and choose Product → Archive. From the Organizer, validate the archive, then distribute it to App Store Connect. Apple’s description of what happens next: "The first time you upload a build, a beta version of the app is created in your account. However, the build needs to be processed in Apple's system before it appears in App Store Connect. You'll receive an email when this process is complete."

Processing is where three predictable snags live. The build number must be higher than any previously uploaded for that version. Every permission your app requests — camera, location, contacts, photos — needs a purpose string in Info.plist explaining why, in plain language; a missing or vague one is a rejection reason in its own right. And the export-compliance question about encryption appears for every build; answer it in the project’s configuration once so it stops blocking uploads.

If you built with Modaal, this step is unchanged: the output is a standard Xcode project on your Mac, so Archive, validate, and upload work exactly as above.

TestFlight is the rehearsal, and skipping it is how apps arrive at review with a crash on first launch. The numbers, from Apple’s overview: up to 100 internal testers (App Store Connect users on your team) and up to 10,000 external testers; builds are testable for 90 days, after which they expire. External testing has its own gate: "When you add the first build of your app to a group, the build gets sent to App Review to make sure it follows the App Review Guidelines. A review is required only for the first build. Subsequent builds may not require a full review." That first external build is, in practice, a free preview of App Review — if it stalls there, your real submission would have too.

Test on the oldest device and iOS version you claim to support, not just your own phone. Test with a fresh account, not the one that has been signed in since development started. Test with the network off. And have at least one person outside the team install it from the TestFlight invitation with no instructions — the onboarding is part of what gets reviewed.

The listing is metadata, and Apple reviews metadata as strictly as code. The limits, from the App Store Connect reference: promotional text 170 characters (editable without a new build — use it), description 4,000 characters, keywords 100 bytes total (comma-separated, no spaces, don’t repeat words already in your name or subtitle), "What’s New" 4,000 characters.

Screenshots: one to ten per device size. For iPhone, the 6.9-inch display set is required — or 6.5-inch if you don’t provide 6.9-inch — and "if screenshots with the accepted sizes aren't provided, scaled screenshots" from the larger size are used for smaller devices. If the app runs on iPad, 13-inch iPad screenshots are required too. Screenshots must show the app as it actually is on that device; a marketing composite that misrepresents the UI is a rejection reason Apple lists by name. For a practical walkthrough of preparing App Store screenshots and handling device sizes, watch our YouTube video.

App Review Information: this is the field first-timers leave empty and pay for. If your app has a login, provide a working demo account and password. If a feature needs a specific setup — a paired device, a subscription, a location — explain how the reviewer can reach it in the notes (up to 4,000 bytes). A reviewer who cannot get past your login screen rejects under 2.1 and you lose the round.

Privacy: the privacy policy URL is required, and the App Privacy section must declare what data the app collects, how it is used, and whether it is linked to the user or used for tracking. Apple’s review guidance is specific that the policy itself must identify the data collected, its uses, third-party sharing, retention and deletion, and how users can withdraw consent. Every SDK you added — analytics, crash reporting, ads — collects something; declare it.

Select the build, choose manual or automatic release, and submit. Apple lists what review evaluates: app completeness, functionality and performance, content compliance, design quality against the Human Interface Guidelines, privacy and data handling, and metadata accuracy. Apple also publishes the reasons unresolved issues pile up, and they are worth reading as a pre-flight checklist rather than a post-mortem: crashes and bugs; broken links; placeholder content; incomplete information and missing demo credentials; privacy-policy problems; unclear data-access requests; inaccurate screenshots; substandard UI; and three guideline-4 categories — apps that are web clippings or content aggregators without unique functionality (4.2), near-duplicate apps (4.3), and copycats (4.1).

Guideline 4.2 deserves a plain sentence because it decides the fate of a whole category of AI-built apps: an app that is a website in an app shell with no app-specific functionality is exactly what "web clippings" describes. No page can tell you whether a given wrapper will pass — reviewers decide case by case — but the more your app does that the website cannot, the smaller that risk gets.

If you are rejected, read the message twice, reply in Resolution Center with specifics, fix what is real, and resubmit. If you believe the rejection is wrong, Apple accepts appeals to the App Review Board — one per rejected submission, with specific reasons the app complies. Expedited review exists for critical bug fixes and event-tied apps; it is a request, not a right, and it works best when you have used it rarely.

On approval the status becomes "Ready for Sale" (or "Pending Developer Release" if you chose manual release — the right choice when you want to line up marketing, or release on a weekday morning rather than whenever review finishes). The listing can take some hours to appear in search across regions; the direct App Store link works immediately.

The first week is when you learn what TestFlight didn’t show you: crash reports from devices you don’t own, one-star reviews from people who expected something the screenshots implied, and the metadata fields you now wish you had written differently. Promotional text and keywords can change without a new build; the description, screenshots, and name change with the next version. Plan version 1.0.1 before 1.0 ships — you will need it, and a build that is already archived and validated turns a bad first week into a one-day fix.

For the Android half, the Play Store has its own ceremony — a one-time $25 developer fee, pre-production testing requirements for new personal accounts, and its own review — covered step by step in the Android guide’s Google Play section. If you are deciding which store to go to first, that question has its own page.

Nothing above cares how the app was written — Apple reviews the archive, not the process. But the process decides how often you get to Step 6 with an app that passes. Apps built without structure tend to arrive at review with exactly the 2.1 problems: a crash on a device the builder never tested, a placeholder screen nobody replaced, a permission request with no explanation because nobody planned the feature that needed it.

Modaal’s answer is to move that planning to the start: for every feature your own AI agent writes a plan first — scenarios, approach, risks, the permissions it will need — and you approve it before code is written, in a standard Xcode project on your disk. The result is native Swift/SwiftUI for iPhone, and Kotlin/Jetpack Compose for Android from the same project, so the Play Store ceremony reuses the work instead of restarting it. Free plan: one project, unlimited prompts. If you are earlier than that — still deciding whether the idea deserves the $99 — test the idea first, and the full path from idea to both stores is in how to build a mobile app from scratch.