A 21-Point Checklist Before You Launch a Mobile App

Launch day problems are almost never surprises. The reviewer could not log in, the release build pointed at the staging server, push notifications worked in testing and failed in production, or the first crash reports arrived unreadable. This mobile app launch checklist collects the 21 checks we run in the weeks before a release, grouped by the part of the project they protect.

Work from top to bottom. The early items take longest to fix when they fail, which is why testing comes first and the release plan last.

Testing on real devices and real networks

1. Test the release build, not the debug build

Debug builds hide problems: different signing, no code shrinking, a developer's test account. Install the exact build you will upload on real phones, including an older, slower model for each platform. Do a fresh install, and an upgrade over the previous version if one exists.

2. Break the network on purpose

Use the app in airplane mode, on a throttled connection and while switching from Wi-Fi to mobile data in the middle of a request. Every screen should show cached content or a clear message with a retry, never an endless spinner or a duplicated order.

3. Interrupt it and refuse its permissions

Take a call mid-task, leave the app in the background for an hour, rotate the device, switch on dark mode and the largest system font. Then decline every permission prompt and confirm the app still works wherever the feature is optional.

4. Run a beta with people outside the team

TestFlight allows up to 100 internal testers from your team and up to 10,000 external testers, whose builds pass a beta review first. Google Play has internal, closed and open testing tracks. One hard rule affects schedules: personal Play developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 days in a row before they can publish to production.

5. Test payments end to end

Use Apple's sandbox testers and Google Play's license testers to buy, cancel, renew and restore on a second device. Check that your backend grants and removes access after each event, not only that the purchase sheet appears.

The store listing

6. Finalize the name and description

Both stores limit the app name to 30 characters. Say what the app does in the first sentence of the description, leave out claims you cannot support and keep keyword lists out of the title.

7. Produce screenshots of the real app

Capture the device sizes each store asks for, from the release build, with realistic sample data. Google Play also needs a feature graphic. Apple's listing should not mention other mobile platforms.

8. Complete rating, category, pricing and countries

Both consoles have an age or content rating questionnaire that must be answered before submission. If the app earns money, confirm that tax and banking details are approved, because those approvals can take days.

9. Write review notes and create a demo account

Give reviewers a working login with sample data, explain any feature that needs special hardware or a location, and keep the backend the build uses running during review. A reviewer who cannot get past the login screen rejects the build. The other usual causes are in our guide to App Store and Google Play rejections.

Privacy and policy

10. Publish the privacy policy

It needs a public address entered in both consoles and a link inside the app. It should say what you collect, why, which third parties receive it and how users ask for deletion. Have your counsel review it, since a template rarely matches your SDKs.

11. Make the privacy declarations match the code

Apple's app privacy details and Google Play's Data safety form both include what third-party SDKs collect. List every SDK, look up what it gathers and answer from that list, not from memory.

12. Review every permission prompt

Ask for each permission when its feature is first used, with a purpose text that says what the user gets. Remove permissions that only an unused SDK requested. If the app tracks people across other companies' apps, iOS requires the tracking prompt first.

13. Provide account deletion

If users can create an account, Apple requires deletion from inside the app, and Google Play requires an in-app path plus a web link for deletion requests. Test that deletion really removes or anonymizes the data on the server.

Analytics and crash reporting

14. Turn on crash reporting and upload symbol files

Without symbols, stack traces are unreadable. Upload dSYM files for iOS and the R8 mapping file for Android with every build, and keep the symbol files when a Flutter build uses --split-debug-info. Force a test crash in the release build and confirm it shows up, readable, in the dashboard.

15. Define and verify the core events

Pick the few events that describe success (sign-up completed, first key action, purchase) and check that each fires once, with the right properties, in the release build. Keep test traffic out of production analytics, and honor the consent your privacy policy promises.

Backend readiness

16. Point the release build at production

Check the API address, keys and feature flags in the release configuration. A store build that talks to the staging server is a classic launch-day discovery. Production needs its own database and its own credentials.

17. Check capacity, limits and backups

Load test sign-up, login and the main screen at a multiple of the traffic you expect from the announcement. Confirm that rate limits will not block many real users behind one office network, and that database backups run and restore.

18. Send a push from production

Apple's push service has separate development and production environments, and a token from one does not work in the other. Send a real notification to a TestFlight or store-signed build through the production credentials before launch.

19. Build in a forced update and a maintenance switch

The first version must already know how to show "update required" and "back soon", controlled by the server. Neither can be added to a build that is already on phones. The reasoning is in designing the backend API for a mobile app.

Support and the release plan

20. Set up support before the first review arrives

Add a contact or feedback option in the app that sends the app version and device model with the message. Decide who answers the support address and the store reviews in the first week, and who is on call for the backend.

21. Plan the release itself

Submit well ahead of the announcement and choose manual release (managed publishing on Google Play), so an early approval does not publish the app before you are ready. Phased release on the App Store and staged rollouts on Google Play apply to updates only, not to a first version. To limit exposure at launch, release in one or two countries first. Keep a tested fix build within reach, because users cannot be moved back to an earlier version.

Who should own the mobile app launch checklist

One named person, with a date against every item. Launches slip when each team assumes another one has handled the privacy form or the demo account. Several items (the beta period, account approvals, legal review) have waiting times you cannot compress, so start the list about a month before the date, not in the final week.

A team that has shipped before can run all of this alone. A first launch, or an app with payments, health data or a large announced audience, benefits from someone who has seen the failures. That is part of our mobile app development work, and after release the same checks repeat for every update under app maintenance.

Frequently asked questions

How early should we submit before the launch date?

Neither store guarantees a review time, and a first submission is the one most likely to be sent back. We suggest submitting a couple of weeks ahead with manual release selected. If approval comes quickly, the app simply waits until you press the button.

Should iOS and Android launch on the same day?

Only if marketing needs it. Launching one platform first lets you fix early problems with half the support load, and review timing differs between the stores anyway. If you announce both together, get both approved and held before the announcement.

What is a soft launch?

A release to a limited audience before the main announcement, usually one or two countries or an open beta. It exposes real-world crashes, server load and confusing screens while the number of affected users is small. Analytics and crash reporting must already be working for it to be useful.

Can we fix a bug right after launch?

Yes, but every update goes through review again, so a fix is not instant. Apple accepts requests for an expedited review for critical problems. Anything you can control from the server, such as feature flags and the maintenance switch, is faster than any store update.