Version and build number App Review checklist

Identify the exact build under review

Record marketing version, build number, commit, release branch, feature flags, server environment, database migration state, and App Store Connect metadata snapshot. A reviewer should not be testing an unknown mixture of binary and backend behavior.

If multiple builds were uploaded, remove or clearly ignore stale candidates so the release owner does not submit the wrong archive under pressure.

Synchronize binary and metadata

• What's New text describes the submitted build, not the next roadmap item.
• Screenshots and app previews match the build's navigation and feature set.
• Review Notes include new gated features, credentials, hardware, regions, or subscriptions.
• Privacy details, age rating, support URL, and pricing reflect the version being submitted.
• Server flags are frozen or documented for review.

Separate hotfixes from feature releases

A hotfix should minimize metadata churn and server changes. A feature release should get full regression, screenshot, privacy, and review-note review. Mixing them creates review and rollback confusion.

AppReviewReady interpretation: the build number is a traceability tool. Use it to connect App Review feedback to exact product state.

Run the final submission gate

1. Install the archived build from the same artifact submitted to App Store Connect.
2. Verify login, purchase, permissions, critical flows, and any newly changed feature.
3. Confirm no staging endpoints, debug banners, test copy, or unreleased feature claims remain.
4. Capture the build provenance record before clicking Submit for Review.
5. Keep rollback and manual release decisions visible to operations.

Build provenance record

A good record shortens rejection diagnosis because the team can connect the reviewer message to one exact build state.

After approval, keep the record with incident notes and support issues. It becomes the baseline for deciding whether the next update is a small fix or a broader review-risk release.

If review is delayed, revalidate server configuration before the reviewer opens the build. Feature flags, pricing records, API schemas, and demo accounts can drift while the binary waits in the queue.

For urgent hotfixes, decide which metadata fields are intentionally unchanged. Editing screenshots, privacy details, or pricing during a hotfix can expand the review surface and slow the actual repair.

When a build is rejected, do not reuse the same internal release name for a materially different archive. Support and engineering need to know which binary customers eventually received.

For teams with web and mobile releases shipping together, include web deployment time in the build record. A mobile binary that depends on a web checkout, help page, or API contract should not be reviewed against an uncoordinated web state.

Build record:
Version/build: [numbers]
Commit/archive: [identifier]
Server config: [frozen/flags]
Metadata changed: [fields]
Review notes changed: [yes/no]
Critical flows tested: [list]
Release mode: [manual/phased/automatic]