How Apple App Store Deployment Works in 2026: Build, TestFlight, Review and Release
Publishing an iPhone or iPad app runs through Apple’s App Store Connect. The workflow in 2026 is still account → build → review → release, but the details matter. This guide walks through each stage and is explicit about which parts you can hand to a developer and which parts must be completed through your own Apple account.
A short history of the workflow
Since the App Store launched in 2008, distribution has been centralised: apps are not side-loaded to customers in the ordinary case. Instead, a developer signs a build, uploads it to Apple, and Apple reviews and hosts it. The tools have modernised — TestFlight, phased releases, automated screenshots — but the fundamental account-to-review-to-release shape has stayed the same.
The Apple Developer Program
To distribute an app you need an active Apple Developer Program membership. The annual fee is 99 USD (the Apple Developer Enterprise Program, which is for private in-house distribution rather than the App Store, is 299 USD). Prices may vary in local currency.
Personal vs organization accounts
An individual account publishes under your personal name. An organization account publishes under a legal entity such as a company or charity. If you want the app to appear under your business name, an organization account is the correct choice.
The D-U-N-S number
Organization enrollment requires a D-U-N-S number — a unique identifier for your legal entity issued by Dun & Bradstreet. It is free to request but can take time, so it is worth starting early if you do not already have one.
Bundle ID
Every app has a bundle identifier, a reverse-domain string such as com.example.myapp. It is registered in your developer account and identifies the app uniquely. Changing it later is awkward, so it is worth getting right up front.
Signing and the build
An app must be signed with an Apple certificate and provisioning profile before it can be installed or submitted. The finished, signed artefact is an IPA (iOS App Store Package), uploaded through Xcode, Transporter or a cloud build service such as EAS. Signing is the part that most often trips up a manual process, so a cloud or CI/CD pipeline that manages certificates is a real help.
App Store Connect
App Store Connect is the dashboard where the app record lives. You create the app, upload builds, and configure everything the store displays. This is where most of the submission work happens.
Metadata, screenshots and assets
- App name and subtitle
- Description and promotional text
- Keywords and category
- App icon (multiple sizes)
- Screenshots (specific dimensions per device)
- Support URL and privacy policy URL
- Age rating information
Privacy information
The App Privacy section asks you to declare what data the app collects and how it is used. This is a factual, legal declaration, not marketing copy. It must match what the app actually does, or the review can be delayed or rejected.
TestFlight
TestFlight is Apple’s beta-testing system. Internal testing lets up to 100 people on your team install builds quickly without a review. External testing supports up to 10,000 testers through a public link or email, and the first build for external testing goes through a lighter beta review.
App Review
App Review is a manual review of each submission against the App Review Guidelines. Rejection is common and usually fixable. At a high level, frequent rejection categories include: crashes or unfinished behaviour, incomplete or misleading metadata, privacy declarations that do not match the app, and payment mechanisms that bypass in-app purchase rules.
Responding to review
When a build is rejected you receive the reason and a way to respond. You fix the issue, upload a new build or update the metadata, and resubmit. A clear, factual reply speeds things up; arguing rarely does.
Release and updates
Once approved you can release immediately or use a phased or scheduled release. Every update runs the same build → review → release cycle, so planning updates as a repeatable pipeline rather than a one-off is worth the effort.
Certificates and provisioning profiles
Two things are needed to install a signed iOS build. A certificate identifies who is signing the app, and a provisioning profile says which devices and app identifiers that build may run on. For App Store distribution you use a distribution certificate and an App Store provisioning profile. This is the step most likely to go wrong when managed by hand, which is why a cloud build service that generates and renews these automatically is valuable.
App versions and build numbers
Each upload needs a version string (what users see, such as 1.2.0) and a build number (an internal counter that must increase with every upload). Apple rejects a build whose version and build-number combination has already been used, so keeping these straight is part of a clean submission.
Screenshot and preview requirements
- Screenshots must be captured at Apple’s required device dimensions (for example the 6.7-inch and 6.5-inch iPhone sizes, plus iPad sizes for a universal app).
- Screenshots must not be misleading; they should show the actual app.
- App preview videos are optional and have their own length and content rules.
Phased release and rollback
Once approved, you can release to everyone immediately or use a phased release that rolls the update out to a percentage of users over seven days. You can pause a phased release if a problem appears. You cannot remotely downgrade users who have already installed the update, so testing before release is the real safety net.
A practical order of operations
- 1Enrol in the Apple Developer Program (and obtain a D-U-N-S number for an organization).
- 2Register the bundle ID.
- 3Build and sign the app.
- 4Create the App Store Connect app record and fill in metadata, screenshots and privacy.
- 5Upload the signed build.
- 6Run a TestFlight beta.
- 7Submit for App Review.
- 8Release (immediately, scheduled or phased).
What Linux Stewards can handle
- Build preparation, signing configuration and IPA upload
- Bundle ID and App Store Connect app-record setup
- Metadata, description and screenshot preparation
- TestFlight internal and external beta setup
- Submission checks before review
- Drafting replies to App Review queries
What requires your own Apple account
- The Apple Developer Program membership and payment
- Your legal entity information (and D-U-N-S for organizations)
- Accepting Apple’s agreements
- Final approval of what is published under your account
Why nobody can guarantee approval
Apple makes the final decision on every submission. We can prepare a clean, compliant, well-tested build and respond carefully to review feedback, but no one can legitimately promise App Store approval. Be wary of anyone who does.