Choose phased release, manual release, or automatic release after approval

Separate review approval from public availability

Apple's publishing workflow lets developers control how an approved app or update becomes available. That control matters because review completion can happen outside your team's preferred launch window, while backend migrations, support staffing, announcements, or partner timing may still need coordination.

Do not submit with an automatic release habit if the version depends on a server switch, data migration, paid campaign, or embargo. Conversely, do not use manual release as a substitute for review readiness; it only controls availability after approval.

Match the option to the operational risk

• Automatic release: use when approval can safely become public without human coordination.
• Manual release: use when marketing, support, backend, legal, or partner dependencies need a release button.
• Scheduled release: use when a specific availability date matters and the app is already approved in time.
• Phased release: use for eligible updates when gradual exposure helps detect production issues.
• Emergency fix: consider whether a phased rollout is appropriate or whether users need the fix as quickly as possible.

Prepare monitoring before a phased release starts

A phased rollout only helps if the team watches the right signals. Define crash thresholds, backend error budgets, purchase conversion checks, login failures, support tags, negative review themes, and any feature-specific health metric before releasing.

AppReviewReady interpretation: write the pause criteria in advance. A vague plan to 'keep an eye on it' often fails when the first signals are ambiguous. Decide who can pause, who investigates, and what evidence allows the rollout to continue.

Use a post-approval runbook

1. Confirm the approved build number, release option, App Store metadata, and server compatibility.
2. Check migrations, feature flags, support staffing, status page, payment configuration, and analytics dashboards.
3. For manual or scheduled release, assign one owner to press release and another to verify availability.
4. For phased release, record the start time, pause criteria, and daily monitoring owner.
5. After release, sample install, launch, login, purchase, restore, and the primary changed feature from a customer-like account.

Document the decision before submission

The release option should be visible to engineering, product, support, and marketing before the app enters review. Changing the plan after approval is possible in many workflows, but last-minute changes increase the chance that one team believes the version is live while another is still preparing.

Release option decision:
Version/build: [version]
Chosen option: [automatic, manual, scheduled, phased]
Reason: [risk/timing/dependency]
Post-approval owner: [name or role]
Monitoring signals: [crashes, backend, purchases, support]
Pause or rollback criteria: [specific threshold]
Customer communication: [none, release notes, campaign, support macro]