From build to App Store: the iOS launch process and a realistic timeline

Stage 1: the Apple Developer account

Every app on the App Store belongs to an Apple Developer Program membership. Set this up early, ideally while the app is still being built, because verification can take time.

• Individual or organisation? An individual account publishes under your personal name. An organisation account publishes under your company’s name and needs a D-U-N-S number for the company plus authority to sign legal agreements for it. If you trade as a limited company, enrol as an organisation; the seller name on your product page should be the business people expect.
• Who owns it? You should. Enrol in your own company’s name, then invite your developer to your team with an appropriate role. Never let an agency publish your app under their own account; moving an app between accounts later is possible but involves conditions and paperwork.
• The fee is 99 US dollars per membership year, or the local equivalent, per Apple’s membership details.
• Agreements, tax and banking. If the app is paid or sells anything through In-App Purchase, accept the paid apps agreement and complete tax and banking details in App Store Connect. This can’t be skipped and is easy to forget until the last week.
• EU trader status. To distribute in the European Union, provide and verify your trader status under the Digital Services Act, per Apple’s upcoming requirements.

Stage 2: beta testing with TestFlight

TestFlight is Apple’s beta-testing service. Builds are uploaded to App Store Connect and testers install them through the TestFlight app. According to Apple’s TestFlight page:

• you can add up to 100 internal testers from your App Store Connect team;
• you can invite up to 10,000 external testers by email or public link;
• the first build you give to external testers needs a TestFlight review by Apple first.

Run two rounds if you can. Internal testing with your own staff catches the obvious problems. External testing with real customers catches the rest: confusing wording, a step people miss, a device or setting nobody on the team uses. Testers can send screenshots and comments straight from the app, and crash reports arrive automatically.

The single most valuable thing you can do here is watch two or three people use the app without helping them.

Stage 3: the product page

While testing runs, prepare the App Store listing in App Store Connect. It’s marketing copy, and it’s also checked by App Review for accuracy.

• Name (up to 30 characters) and subtitle (up to 30 characters). Make the subtitle say what the app does.
• Keywords (up to 100 characters), which aren’t shown but help search. Don’t repeat words already in the name.
• Description and promotional text. Promotional text can be changed without a new release, so use it for news.
• Screenshots for the required device sizes, and optionally an app preview video. Apple’s specifications in App Store Connect Help list the current sizes. Screenshots must show the app as it really is.
• Category, age rating and pricing. The age rating comes from a questionnaire in App Store Connect; Apple introduced an updated age rating system and asked developers to answer its new questions by 31 January 2026, per the upcoming requirements page, so check yours are complete.
• Support URL and privacy policy URL. Both are required for every app, and both must work.
• App Privacy details, describing what data the app collects and how it’s used. These must match the app’s privacy manifest and behaviour; see Privacy manifests, permissions and passing App Store review.
• Accessibility Nutrition Labels, optional but increasingly visible, stating which accessibility features the app supports. Only claim what works; Accessible iOS apps in SwiftUI explains what each means.

Stage 4: submitting for review

When the release build is ready:

1. Upload it from Xcode (or Xcode Cloud) to App Store Connect. Since 28 April 2026, uploads must be built with Xcode 26 or later and the iOS 26 SDK or later, per Apple’s requirements page; your developer will be on a current Xcode anyway.
2. Select the build for the version, check every field, and fill in App Review Information: a demo account if the app needs sign-in, contact details, and notes explaining anything the reviewer can’t easily reach.
3. Choose how to release once approved (see stage 5), then submit.

Apple states that App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, on its App Review page. The same page says over 40% of unresolved issues relate to guideline 2.1, App Completeness: crashes, placeholder content and incomplete information. A complete submission with a working demo account avoids most of them.

If the app is rejected, App Store Connect explains why and cites the guideline. Many rejections are fixed by a clarification or a small change, and you can resubmit straight away.

Stage 5: choosing how to release

You don’t have to go live the moment the app is approved. In App Store Connect you can choose:

• Automatic release as soon as review approves it;
• Manual release: approved and waiting until you press the button, which is the best option for a coordinated launch;
• Scheduled release on a date you choose, as long as review has approved it by then.

For updates, phased release rolls the new version out to people with automatic updates gradually over seven days, and you can pause it if a problem appears. For a first launch you can also offer the app for pre-order, so people can order it before release day and it downloads automatically when it goes live.

A realistic timeline

Every project differs, so treat this as an order of events with typical considerations rather than a fixed schedule:

The most common reason for a missed launch date isn’t App Review. It’s the build itself being “nearly finished” for longer than planned. Fix the date only once the app is feature-complete in TestFlight, and keep a buffer between submission and any public announcement.

Launch day and the week after

• Check the live listing on a device: name, screenshots, price, links.
• Download the App Store version yourself and complete the main journeys.
• Watch crash reports and reviews in App Store Connect and Xcode’s Organizer.
• Reply to early reviews, especially critical ones; you can respond publicly in App Store Connect.
• Have a fix-it build ready to go. If a serious bug slips through, Apple’s App Review page explains that you can request an expedited review for critical bug fixes.

Then the real work starts: learning from how people use the app and planning what comes next. The maintenance guide covers the year after launch.

Last-minute surprises worth checking early

A few things regularly turn up in the final week. Check them a month before launch instead:

• The privacy policy doesn’t mention a service the app now uses, such as a crash reporter or analytics tool.
• Screenshots show an old design, or a feature that was cut.
• The demo account for App Review has expired, or has no data in it.
• Sign-in with a third-party service has been added without the equivalent login option Apple requires; see the review guide.
• In-App Purchase products haven’t been created and submitted with the version, so the purchase screen is empty during review.
• The support URL points at a page that doesn’t exist yet.
• Push notifications work in development but the production configuration hasn’t been tested.

Each is quick to fix in advance and annoying to fix while a launch date looms.

Key takeaways

• Enrol in the Apple Developer Program in your own organisation’s name early; verification and agreements take time.
• Use TestFlight in two rounds, internal then external, and watch real people use the app.
• Prepare the product page, privacy details and support links during beta testing, not after.
• Apple usually reviews within a day or two; complete submissions with demo accounts avoid most delays.
• Use manual or scheduled release for a public launch date, and phased release for updates.

If you have an app nearing completion, or a launch date to hit, and want someone to steer it through these steps, get in touch.

Written by Lee Johnson. Published 30 October 2026.