Mobile app launch checklist: from a working build to release

Use this with the build you plan to release

Work through this list on an installable build. The checkboxes below are temporary and reset when you reload; download the Markdown copy to keep your own notes and evidence.

Record which build you tested, the device and the outcome. Mark an item not applicable only when you can explain why. This is a practical starting point, not a complete audit or a guarantee of store approval.

The main task

Ask someone unfamiliar with the app to complete its main task without coaching. Record where they hesitate and check the saved result.

A new user can reach the first useful action.
The main task completes and shows a clear result.
Saved data remains correct after closing and reopening.
Empty, invalid-input and failed-request states are understandable.
An accidental action can be corrected where appropriate.

On a real phone

Browser previews are useful during development. Native permissions, keyboards and navigation still need device testing.

Content fits the supported screen sizes and larger text settings.
The keyboard does not hide required inputs or actions.
Permission denial has a usable fallback.
Slow or lost connectivity does not silently discard work.
Sign-in links and navigation return to the intended screen.

Accounts and production configuration

Test with separate accounts when the app stores personal data. Keep test records and services separate from the environment real users will use.

The release uses the intended production services.
One account cannot read or modify another account’s private data.
Secret credentials are kept out of public app configuration.
Account deletion and data handling match the app’s disclosures.

If the app has paid features

A configured payment integration is only part of the work. Verify the entitlement that actually unlocks the feature, including what happens when the purchase is cancelled or restored.

The price and terms are clear before purchase.
Successful and cancelled test purchases behave correctly.
Restore purchases works for a returning eligible user.
Expired access and failed purchases do not leave misleading access states.

Listing and review

Use screenshots and descriptions of the release version. Consult the current rules for each store and the category you are submitting.

The listing describes features that work in this build.
Support and privacy-policy links open successfully.
Reviewers can access any protected features they need to test.
The backend stays available during review.

After release

Prepare a small operating routine before inviting more users. Define who reads support requests and how a failed release will be handled.

Support has a monitored contact route.
Crash and error reporting are checked with a test event.
Important data has a recovery plan appropriate to the app.
The next improvement is based on observed user problems.