Release readiness check
App identity and version are final
Bundle ID or package name, app version, build number, icon, and target platform are correct.
- 01Release target
- 02Production build
- 03Real-device test
- 04Store package
- 05Submission
- 06After approval
Define the release you are shipping.
A clear target keeps the last week from turning into moving requirements.
One person owns the release
Someone can access the build system, store consoles, and required credentials.
The release scope is frozen
The must-ship flows and acceptance checks are written down; new ideas have a later place.
Produce the artifact people will install.
A development build can hide the configuration that matters in production.
The signed production build succeeds
The release profile produces an installable iOS archive or Android app bundle.
Signing and upload access are verified
Certificates, profiles, keystore, and upload permissions are available to the release owner.
The installed build uses production services
API endpoints, keys, entitlements, and feature flags are correct in the actual release candidate.
OTA update compatibility is checked
If you use EAS Update, the release channel and runtime version match the native build.
Test the release build as a user would.
Use the exact candidate, outside a debugger, on devices that represent your users.
Fresh install and upgrade both work
Test a new installation and an upgrade from the current live version where applicable.
The core user journeys pass
Walk through onboarding, sign-in, the main task, and any purchase or account flow your app uses.
Native and device-specific flows pass
Check relevant permissions, notifications, deep links, camera, payments, and background behavior.
Crash and release signals are visible
The team can see crashes or failed critical flows from the production environment.
Make the store record match the app.
The binary and its listing are reviewed together, so both need a final pass.
Listing text and screenshots are current
Descriptions, screenshots, localizations, support contact, and shown features match this build.
Privacy declarations reflect real data use
The policy and store answers account for your app and third-party SDKs.
Reviewers can access the app
If sign-in or special setup is required, test credentials and instructions are ready.
App Store Connect record is complete
For iOS: the correct build, required metadata, pricing, availability, and review information are set.
Google Play production access is available
For Android: confirm the account can use production; newer personal accounts may need closed testing first.
Send the right build through review.
Upload is only one part of submission; the selected version and release settings matter too.
The intended build is selected
The store console points to the exact candidate that passed your release checks.
Release settings are deliberate
Regions, pricing, content rating, and manual, automatic, or staged rollout are set as intended.
Someone will handle review feedback
A named person will watch status changes and respond with a fix or clear explanation.
Be ready for the first real users.
Release work continues through rollout, monitoring, and a clean handover.
The first release window is monitored
Someone will watch crashes, support messages, store feedback, and the core user flow.
A hotfix or rollback path is known
The team knows which issues can use an update and which require a new native build.
Release notes and ownership are recorded
Build ID, changes, known issues, credentials owner, and next follow-up are documented.
YOUR RELEASE READOUT / SELF-REPORTED
Your next steps are ready.
Done0
Needs work0
Not sure0