12 June 2026
What a release readiness review actually opens first
Before architecture debates, we check whether the build in hand can be signed, installed, and explained to the store.
When a team books a release readiness review, they often expect a lecture on clean architecture. We start somewhere less glamorous: can this exact binary be produced again, signed correctly, and described truthfully in the store listing?
Signing and entitlements
On iOS we verify profiles, capabilities, and whether push or associated domains match what the binary actually uses. On Android we confirm upload keys, app signing by Google Play where applicable, and that flavour-specific application IDs have not drifted from the Play Console listing.
Permissions versus screens
A permission that still appears in the manifest while the related screen was removed last sprint is a classic late-stage embarrassment. We compare declared permissions to reachable features in the candidate build.
Changelog honesty
Marketing copy that claims “offline mode” when the merge only added a stub is not a store policy footnote — it is a trust problem with users. We read the merged tickets against the draft release notes you plan to publish.
If your freeze date is inside a week, request a Release Readiness Review early enough that a “wait” recommendation still has calendar room.