App Store release checklist: privacy, StoreKit, review, and launch operations

The short answer

A production App Store launch is not “upload the binary and wait for review.” It is a coordinated release across code signing, App Store Connect metadata, privacy disclosures, account and entitlement configuration, backend compatibility, StoreKit behaviour, reviewer access, staged rollout, analytics, support, and incident response.

The minimum professional sequence is:

1. freeze the release contract and ownership;
2. test a clean installation and real account lifecycle on physical devices;
3. reconcile app behaviour, privacy manifests, App Privacy answers, permissions, and policy;
4. test purchases and subscription state transitions in Xcode, Sandbox, and TestFlight;
5. prepare complete metadata and review instructions;
6. verify backend, feature flags, observability, support, rollback, and kill switches;
7. submit without making unreviewed production changes;
8. monitor review, phased release, crashes, purchases, support, and first-use outcomes.

No checklist guarantees approval. Apple’s guidelines and platform behaviour change, and App Review can identify issues unique to an app. The checklist reduces preventable failures and creates evidence for responding quickly.

Define the release contract

Before creating the final build, write a release record:

The build must be reproducible enough to answer “what is under review?” Record the source revision, Xcode and SDK versions, dependency lock state, build configuration, entitlements, environment, and generated assets.

Do not silently change a production API or remote configuration after testing and before review. Reviewers and users may encounter a state different from the signed-off release. If remote configuration is necessary, version it and include it in the release evidence.

Decide the rollout boundary. A submission can contain code whose risk is controlled by server capability, account cohort, region, or feature flag, but the reviewed app must remain complete and honest. Apple’s App Review Guidelines say submissions should be final, metadata and URLs should be functional, and hidden or undocumented functionality should not be used to mislead review.

Verify accounts, signing and capabilities

Many launch failures are account-state failures rather than code failures.

Check:

• Apple Developer Program membership and agreements;
• legal, banking, and tax status where paid apps or purchases apply;
• bundle identifier and SKU;
• App ID capabilities;
• certificates and provisioning profiles;
• team and role permissions;
• distribution certificate expiry and ownership;
• push notification keys;
• Sign in with Apple configuration;
• associated domains and universal links;
• app groups, keychain groups, iCloud, HealthKit, VPN, or other entitlements;
• App Store Connect API keys and CI secrets;
• domain and support-email access.

Treat signing assets and store roles as operational credentials. Keep organizational ownership, least privilege, documented recovery, and an offboarding process. A release should not depend on one person’s laptop or personal account.

Compare entitlements in the archive with the capabilities that the app actually uses. A development build may work because a developer profile is permissive while distribution signing exposes a mismatch.

For extensions—widgets, share extensions, network extensions, watch apps, notification services—verify each target’s bundle ID, version, signing, privacy manifest, app groups, and deployment settings. The main app passing does not prove every embedded target is valid.

Test the complete user lifecycle on physical devices

Simulator success is not release evidence for hardware, permissions, notifications, camera, location, Bluetooth, HealthKit, network extensions, background execution, or StoreKit.

Use a device matrix proportional to audience and risk:

• oldest supported OS on representative hardware;
• current production OS;
• latest available OS used by the team;
• small and large screen where layout differs;
• poor network, offline, and restored network;
• low storage and interrupted operations where relevant;
• locale, region, time zone, 12/24-hour clock, dynamic type, dark mode;
• VoiceOver and keyboard/switch paths where applicable.

Test these installation states:

1. clean installation with no previous keychain or account assumptions;
2. update from the current App Store version;
3. reinstall where keychain or server account persists;
4. restored device or second device where the workflow supports it;
5. logged-out, expired-session, deleted-account, and revoked-permission states.

The first launch must handle backend unavailability, configuration delay, and permission denial without trapping the user. Permissions should be requested in context, after explaining value, and the app should remain understandable when access is denied.

Test the complete account lifecycle:

• sign up and verification;
• sign in and Sign in with Apple edge cases;
• password or credential recovery;
• account linking and duplicate identity;
• session expiration and token refresh;
• logout on one and multiple devices;
• data export where offered;
• account deletion and re-registration;
• subscription restoration after account changes.

Capture evidence with build number, device, OS, account type, time, steps, expected result, actual result, and logs. “QA passed” is not reproducible.

Reconcile privacy, permissions and disclosures

Privacy has several representations that must describe the same product:

• actual runtime data flow;
• third-party SDK behaviour;
• permission purpose strings;
• privacy manifest files;
• App Store Connect App Privacy answers;
• privacy policy and privacy-choices pages;
• consent and in-app controls;
• deletion and retention operations.

Apple’s App Privacy Details require developers to disclose data collection by the app and integrated third parties, including whether data is linked to identity or used for tracking. Data processed only on the device and never sent to a server is treated differently from collected data. Do not infer the label from SDK marketing; inspect network, storage, configuration, and contracts.

Privacy manifest files describe collected data, tracking domains, and required-reason API use for an app or SDK. Each relevant executable or dynamic library needs accurate declarations. Apple’s required-reason API guidance requires approved reasons consistent with actual functionality and prohibits fingerprinting.

Build an SDK register:

Remove an SDK that does not justify its privacy and operational cost. Disabling collection in your code may not disable every default SDK behaviour; verify configuration and traffic.

Check every permission string against the feature visible to the user. Generic copy such as “we need access for a better experience” is weak. Explain what the app does with the permission. Verify denied, restricted, one-time, limited-library, approximate-location, and settings-changed states where relevant.

The public privacy policy must be reachable, current, and consistent with the released app. App Review may inspect it, but the higher standard is that a user can understand data use and exercise available choices.

Test StoreKit as a state machine

Purchases are asynchronous state transitions, not a success callback.

Define entitlement from verified transactions and server state where appropriate. Handle:

• products unavailable or configuration mismatch;
• user cancellation;
• pending approval;
• purchase success;
• interrupted transaction;
• restored purchases;
• purchase on another device;
• renewal;
• billing retry or grace period;
• expiration;
• refund or revocation;
• upgrade, downgrade, and cross-grade;
• introductory and promotional offer eligibility;
• account mismatch;
• delayed or duplicated server notification;
• offline launch with cached entitlement.

Apple’s StoreKit testing guidance distinguishes StoreKit Testing in Xcode, Sandbox, and TestFlight. Each environment provides different signing and control. Use Xcode for deterministic errors and automated scenarios, Sandbox for App Store Connect products and server integration, and TestFlight for realistic beta distribution. No single environment covers everything.

Use StoreKitTest to automate renewal, Ask to Buy, failures, and other transaction cases where applicable. Test server-to-server notifications, reconciliation, and idempotency independently.

Verify that product identifiers match across code, configuration, App Store Connect, backend, analytics, and support documentation. Never grant entitlement from a button tap or unverified local flag.

Purchase UI must show the localized product name, duration, price, renewal behaviour, trial or offer terms, restore path, and links required by policy. Do not hardcode a price string when StoreKit provides localized product data.

Test from a clean account and from accounts with history. Offer eligibility and subscription group state can produce different UI even on the same build.

Prepare App Store Connect metadata as product truth

Metadata is not decoration. It forms the user’s expectation and the reviewer’s model of the app.

Verify:

• app name, subtitle, category, age rating, and availability;
• description and promotional text;
• keywords without misleading or irrelevant claims;
• screenshots for every required device class and locale;
• app preview video if used;
• support URL, marketing URL, privacy policy URL;
• copyright and legal entity;
• version release notes;
• export-compliance answers;
• content rights;
• advertising identifier use;
• review contact and notes;
• demo credentials or approved demo mode;
• attachment for flows requiring special hardware or setup.

Screenshots must represent the released experience. Check status bars, personal data, test banners, placeholder content, outdated paywalls, and features behind flags. Localized metadata should be reviewed by a person who understands the product; a linguistically correct translation can still promise the wrong workflow.

The App Review Guidelines require accurate metadata and complete review access. If the app requires login, provide stable credentials that will remain valid throughout review, preload necessary data, and explain multi-factor authentication or role selection. If a feature depends on location, hardware, subscription, enterprise configuration, or backend sequence, give concise reproducible instructions.

Review notes should help, not argue:

1. what changed;
2. where the reviewer finds it;
3. credentials and role;
4. configuration or hardware prerequisites;
5. purchase items included;
6. explanation of a potentially ambiguous policy area;
7. support contact monitored during review.

Use TestFlight as a release environment

TestFlight is not production, but it is more than a distribution button.

Apple’s TestFlight guidance supports internal and external groups, tester feedback, screenshots, and crash context. External testing requires beta information and may require TestFlight App Review.

Create cohorts:

Give each group a test charter. “Please try the app” produces low-signal feedback. Ask users to complete a real task and report context, expected outcome, actual outcome, and whether they recovered.

Do not let beta accounts bypass production authorization in a way that hides a release issue. Test environments can use dedicated data, but the permission model and core backend contract should remain representative.

Define exit criteria before the beta:

• no unresolved critical crashes or data loss;
• core journeys complete on the device matrix;
• privacy and permission states reconciled;
• purchase matrix passes;
• backend and minimum-version behaviour passes;
• support and incident owners ready;
• known limitations documented and accepted.

Prepare backend and operations

The mobile binary may be reviewed for hours or days and remain installed for years. The backend must support mixed client versions.

Before submission:

• deploy backward-compatible API changes first;
• verify migrations and rollback;
• set minimum supported version policy deliberately;
• confirm remote configuration defaults;
• exercise feature and emergency kill switches;
• create dashboards for activation, errors, latency, purchases, notifications, and critical jobs;
• set actionable alerts with owners;
• prepare support macros and escalation;
• document incident and release rollback paths;
• confirm backups and restore evidence where required;
• monitor certificate, key, and agreement expiry.

A rejected build must not leave production in a half-migrated state. A delayed phased release must not break the previous version. An expedited fix must not require an unsafe schema rollback.

Feature flags need lifecycle ownership. Record purpose, default, audience, dependency, removal date, and emergency behaviour. A flag system full of undocumented combinations creates a second untested application.

Analytics should answer release decisions without collecting unnecessary personal data. Define activation, critical task completion, failure, purchase, restore, and support signals. Preserve build and app version dimensions.

Submit, respond and release deliberately

Run a final archive check:

• correct version/build and distribution configuration;
• expected symbols and dSYMs;
• no development endpoints, test accounts, debug menus, or verbose sensitive logs;
• valid signing and entitlements for every target;
• privacy manifests present and valid;
• required icons and launch assets;
• export and upload validation clean;
• exact archive stored or traceable.

After submission, freeze material assumptions. Monitor App Store Connect and the review contact. Respond to questions with facts, steps, and evidence. If rejected, classify the issue:

Do not resubmit unchanged with a longer argumentative note. Change the relevant evidence or use the appeal path when the application of policy is genuinely disputed.

Choose manual, automatic, or phased release based on operational readiness. A phased release limits distribution rate, not every risk: backend changes and existing users can still create exposure. Keep monitoring and the ability to pause or disable the affected capability.

Operate the first seven days

First hour

Verify store availability, correct version, product page, deep links, clean install, login, core task, purchases, remote configuration, backend health, and dashboards.

First day

Review crash-free use, critical errors, onboarding abandonment, purchase/restore failures, support contacts, reviews, and unexpected data or cost signals. Segment by version and OS.

Days 2–3

Inspect real failure cases, not only averages. Confirm notifications, background tasks, renewals, and delayed integrations. Correct metadata or support information if users misunderstand the release.

Days 4–7

Decide whether to expand, pause, or complete rollout. Record incidents and turn important failures into regression tests. Remove temporary access and release flags when safe.

Do not claim success from downloads alone. Evaluate whether intended users activate, complete the critical task, retain appropriate entitlement, and avoid high-severity failure. Compare against a documented baseline without inventing causation.

Release checklist

Product and policy

• Release scope, non-goals, owners, and gates are written.
• App behaviour matches metadata, screenshots, review notes, and policy.
• Known policy-sensitive workflows have evidence and an owner.

Build and device QA

• Exact archive, source revision, tools, dependencies, and configuration are recorded.
• Clean install, upgrade, reinstall, session expiry, account deletion, and recovery pass.
• Physical-device, accessibility, localization, offline, and poor-network cases pass.
• Every embedded target has valid signing, entitlements, versions, and privacy manifests.

Privacy and security

• Runtime data flow, SDK register, permissions, manifests, App Privacy, and policy agree.
• Secrets, logs, administrative access, data deletion, and incident response are reviewed.

Purchases

• Product identifiers and localized StoreKit data agree across systems.
• Purchase, pending, cancel, restore, renewal, expiry, refund, revoke, and offer cases pass.
• Server notifications and entitlement reconciliation are idempotent and observable.

Store and review

• Agreements, roles, metadata, URLs, screenshots, age rating, compliance, and IAPs are ready.
• Stable review credentials and concise reproducible notes are ready.
• TestFlight exit criteria are satisfied.

Operations

• Backward-compatible backend, migrations, flags, dashboards, alerts, support, and rollback are ready.
• First-hour, first-day, and seven-day owners know what to inspect.

A launch is ready when the team can explain what it is releasing, prove the important journeys, detect failure, protect users, and recover. Approval is necessary; safe operation is the outcome.