On this page
An app launch is ready when the intended audience can complete the core tasks, the release information matches the product, and the team can operate and recover the service. Uploading a build is one step in that process. It does not establish that account access, backend configuration, support, and data handling are ready for live use.
Use this checklist as a planning framework and adapt it to the product's actual risks and distribution channel. Platform requirements change, so verify the current official requirements and the outstanding tasks in the project's own developer account before submitting or publishing.
Identify the exact release candidate
Record the version, build identifier, source revision, and environment configuration being reviewed. The team should be able to distinguish the candidate from an earlier test build or a later unreviewed change.
Confirm the intended audience and release channel. An internal test, a closed beta, and a public production release create different expectations. Keep the store listing, invitation, and in-app messaging consistent with that scope.
Freeze or control changes during the final review. If code or configuration changes afterward, assess which evidence is affected and repeat the relevant checks. Do not attach a passing result from one build to a different build without examining the difference.
Verify the complete core journeys
Choose the tasks that define the product's value and exercise them through the actual entry points. Include first use, returning use, and the important state changes. A manually prepared development screen is not enough if users cannot reach it from the released app.
Check persistence and recovery where they matter. A saved record should remain available after the app closes and reopens. An interrupted submission should not leave the user guessing whether to repeat an action that may already have completed.
Use representative test data and accounts with the appropriate permissions. Verify that an ordinary user cannot perform restricted actions merely by bypassing a hidden control. Keep sensitive production information out of broad test evidence.
Check permissions and denied-permission behavior
Request device permissions in the context where they are needed and explain their purpose accurately. The app should handle a denied or later-revoked permission according to the intended product behavior.
Test the path for a person who chooses not to grant an optional permission. A feature that genuinely needs access may explain the limitation, while unrelated functionality should behave according to the product's requirements.
Review the data collected by the app and its third-party components. Store declarations, privacy information, and in-product explanations must reflect the actual release, including analytics and advertising components where present.
Prepare accurate distribution information
Check the app name, description, screenshots, support details, privacy link, and other required metadata. Show the actual product rather than a concept screen or a feature planned for a later release.
Provide the access and instructions reviewers need to evaluate account-based or otherwise restricted functionality. Use the platform's supported review-information fields and suitable review accounts. Do not place private credentials in public descriptions or screenshots.
Keep necessary backend services available during review and verify that the review environment behaves as described. If a feature depends on a particular setup, explain that setup clearly instead of assuming the reviewer will infer it.
Review the upgrade path separately from a fresh install
A clean installation can pass while an upgrade fails because of stored data, schema changes, cached settings, or old authentication state. Test the supported transition from the relevant previous version using representative data.
Decide how the app handles data it cannot migrate automatically. The user may need a clear recovery or support path, and the team needs a way to investigate without losing the original record.
Do not assume that uninstalling and reinstalling is an acceptable workaround for every user. It may remove local data or create an access problem. Any recovery instruction should reflect the actual storage and account behavior of the product.
Establish operational ownership
Name the person or team responsible for watching the release, responding to incidents, and making a pause or rollback decision. Confirm that they have the necessary access through the organization's normal controls.
Prepare a support route that works from the released product and public listing. A support address that nobody monitors is not a complete support plan. Give the team enough context to distinguish a known limitation from a new failure.
Choose a small set of useful operational signals. Crashes, failed core actions, unavailable dependencies, and unusual support volume may matter more than a broad dashboard of numbers with no response plan.
Make rollback and containment realistic
Write down what can be reversed and what cannot. A server change may be rolled back quickly, while a mobile build already installed on devices may remain in use. A database migration may require a specific recovery path rather than simply deploying the previous application version.
Use available rollout controls correctly. For eligible Google Play updates, a staged rollout can limit initial distribution, and it can be halted if an issue appears. Halting does not remove the version from users who already received it. First production releases have different options, so check the current platform behavior.
Identify a safe way to contain a failing feature where the architecture supports it. Feature controls need their own verified behavior and ownership; an untested switch should not be treated as a guaranteed rescue mechanism.
Decide what evidence blocks launch
Separate unresolved blockers from accepted limitations and deferred scope. Missing core functionality, an unverified access boundary, or an unavailable required provider can prevent the intended release even when the interface looks polished.
Record who accepts a material limitation and why. The release decision should be based on its effect on users and operations, not on a desire to make the issue count reach zero.
Do not describe store approval as a complete quality certification. Platform review serves its own purpose; the product team remains responsible for verifying the service it is releasing and operating it appropriately.
Verify the public result after publication
Check the actual released version through the supported user route. Confirm the listing, installation or update, core journey, and relevant backend behavior. A successful upload or publication message is an intermediate result.
Keep the launch observation period focused and assign follow-up work for real findings. Compare the live evidence with the release candidate and investigate differences before broadening availability where rollout controls permit that choice.
Close the launch record with the released version, verification evidence, known limitations, and the next operational owner. The checklist is complete when the team can show that the intended audience has a usable, supported product and a credible response if something goes wrong.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Apple: App Review Guidelines Submissions need complete and accurate information, review access, functioning backend services, and compliance with current applicable requirements.
- Google Play: Prepare and roll out a release Release preparation includes the app setup, review, release track, and publication choices; first releases and updates have different rollout options.
- Google Play: Staged rollouts Eligible updates can use staged rollout controls; halting a rollout limits further distribution but does not remove the update from people who already received it.