App Store pre-order review and launch checklist

Decide whether pre-order fits the launch

Pre-order works best when demand generation starts before availability and the app's public promise is stable. It is risky when pricing, territories, compliance answers, screenshots, core features, or server readiness are still changing daily.

Write the reason for pre-order in one sentence. If the reason is only 'we want more time after review', use manual release or scheduled release instead. Pre-order creates a public product page and user expectation before the app is downloadable.

Freeze product-page claims earlier

• Screenshots should show features that will exist on launch day, not aspirational roadmap panels.
• Description, subtitle, keywords, and promotional text should avoid promises tied to uncertain backend or content partnerships.
• Privacy labels, age rating, category, support URL, and marketing URL should be final enough for public scrutiny.
• Pricing, launch date, territories, and availability should be documented before campaigns begin.

Keep the review build fully testable

A pre-order app still needs a submitted build that a reviewer can evaluate. If launch-day content is gated by server date, feature flags, or invitation codes, provide a review path that bypasses calendar waiting while preserving the customer launch plan.

AppReviewReady interpretation: never make the reviewer wait for the public release date to see the core value. Use demo data, review flags, or a controlled test account if live inventory or content is not public yet.

Check IAP and subscription readiness separately

1. Confirm submitted IAP or subscription products match paywall copy in the pre-order build.
2. Test StoreKit product loading from a clean install and with the review account state.
3. Verify the app handles launch-day entitlements for users who pre-ordered before content was live.
4. Confirm support and refund language matches whether payment occurs through the App Store.
5. Record whether any products should remain hidden until release and how the app behaves before then.

Use a launch-day runbook

Pre-order mistakes often show up after approval rather than during review. Assign owners for availability, support, analytics, server capacity, App Store page monitoring, and incident decisions before the public countdown reaches zero.

Pre-order launch runbook:
Launch date/time: [local and UTC]
Release owner: [name or role]
Build/version: [number]
Territories: [list]
Server readiness checks: [APIs, content, payments]
Monitoring: [crash, login, purchase, support]
Rollback or delay criteria: [threshold]

Choose pre-order, scheduled release, or manual release

Choose pre-order when public demand capture matters and launch facts are stable. Choose scheduled release when timing matters but product-page exposure does not need to start early. Choose manual release when operations readiness is uncertain and a human should verify dependencies after approval.