Before You Submit to Google Play: A Release Checklist

What does Google Play check before your app goes live?

Google Play reviews more than the app itself. Before a release goes out, your developer account, your privacy policy, your answers about how the app handles data, your store listing and the technical build all have to meet Play's requirements. Many first-time delays come from preparing these items in response to a rejection rather than before submission.

This is the checklist we work through before submitting an app, the same one we use for the apps we publish on Google Play ourselves (see our work). Requirements change, so where a rule has a current figure or deadline, the item points to Google's own documentation instead of repeating it.

Is your developer account set up correctly?

Register the account in the right name. If the app belongs to your company, the developer account should too. Moving an app to another account later is possible, but it adds work you can avoid. An organisation account needs a D-U-N-S number from Dun & Bradstreet, so request one early if your company does not have it.
Check which testing rules apply to you. Google requires personal developer accounts created after 13 November 2023 to run a closed test with a minimum number of testers for a minimum period before they can publish to production. Read the current testing requirements early, because this adds calendar time you cannot compress at the end.

Are your privacy policy and Data safety form ready?

Publish a privacy policy at a public URL. Google requires one to complete the Data safety form, even for apps that collect no user data.
Complete the Data safety form accurately. It asks what data the app collects and shares, and why. Your answers must also cover data collected by third-party libraries in the app, such as analytics or crash reporting tools, not only your own code. Google's Data safety guidance explains each question.
Make the policy, the form and the app agree. If the app asks for location, the policy and the form should both say so and say why.

Are you asking only for the permissions you need?

Map every permission to a feature a user can see. If you cannot name the feature, remove the permission.
Ask at the moment it is needed. A camera request when the user taps "Scan" is easier to understand than a list of prompts on first launch.
Expect extra steps for restricted permissions. Some permissions, such as access to SMS, call logs or all files on the device, are restricted, and apps that use them must submit a declaration explaining why.

Is the build ready?

Meet the current target API level. Google raises the minimum Android version your app must target on a regular schedule, for new apps and for updates. Check the current target API level requirement before you start the release, not after an upload is rejected.
Plan your signing keys. With Play App Signing, Google holds the key that signs the app delivered to users, and you keep an upload key to sign what you submit. Store the upload key and its password somewhere your company controls, not on one developer's laptop. Google explains both keys in Use Play App Signing.
Turn on crash reporting and analytics before release. The first hours after a release are when you most need to see what is breaking.
Test on real devices. Include an older, lower-memory phone and a slow network, not only the phones your team carries.

Test the release build properly first: see how to test an Android app before release.

Is the store listing complete?

Write the descriptions for people. Say what the app does in the first line of the short description.
Choose screenshots that show the core job. The first few screenshots carry most of the message.
Answer the content rating questionnaire and target audience questions honestly. If children may use the app, additional policies apply.
Give a support email someone reads. Both users and Google will use it.

How should the release itself go?

Roll updates out in stages. Play lets you release an update to a percentage of users, increase it over time, and halt it if something goes wrong. Staged rollouts apply to updates only, not to an app's first release. See staged rollouts in Play Console Help.
Watch the crash and analytics dashboards for the first days after each release, and be ready to halt a rollout.
Keep a written record of what went into each release and when it went out.

What happens after launch?

A release does not end Play's requirements. Target API levels move and policies change. An app that falls behind the target API requirement stops being offered to new users whose devices run a newer Android version than the app targets. Plan for regular updates from the start. Our maintenance retainers exist for exactly this. For what upkeep covers, read what app maintenance involves after launch.

Before you reach release, make sure the scope is right. Our guide on how to scope an app MVP covers what to build now, what to build later and what not to build.

Preparing a first Play Store release? Our Play Store release service covers the listing, policy documents, signing and a staged rollout. Questions about ownership and what happens after launch are answered in our FAQ.