How to Publish an App to Google Play: Checklist

1. Google Play developer account

You create a developer account in Play Console and pay a one-time registration fee. When you sign up, you choose between a personal and an organization account and Google will want to verify your identity with an ID and a payment card in your name. An organization account also needs a D-U-N-S number, which your company can get for free from Dun & Bradstreet.

The account type shapes your first release. According to Play Console Help, personal accounts created after November 13, 2023 have to run a closed test before the app can go live, while organization accounts don't. If you're publishing for a company or a client, start with an organization account.

2. Source code, builds and app signing

Your app's source code is probably already in a repository, for example on GitHub or GitLab. Production builds of a mobile app should come from CI, not from a developer's laptop. For a native Kotlin or Java app, ./gradlew bundleRelease builds the bundle for Google Play and you can run it in GitHub Actions, GitLab CI, Bitrise or Codemagic. In Flutter, the equivalent is flutter build appbundle.

For Expo and React Native apps, EAS Build builds the app in the cloud and EAS Submit uploads it to Google Play. You'll find builds, store submissions and credentials in the project on expo.dev. To submit to Google Play, EAS needs a Google service account key with access to Play Console.

Before upload, you sign the bundle with an upload key stored in a keystore file. Google keeps the app signing key that signs the app for users through Play App Signing, so you can reset a lost upload key in Play Console. Keep the keystore and its passwords in a password manager and in your CI secrets, never directly in the repository.

3. Push notifications and Google services in Firebase

Firebase is Google's platform that delivers push notifications on Android through Firebase Cloud Messaging. In Firebase you can also turn on Crashlytics for crash reports, Analytics, Remote Config or Authentication. The google-services.json config file from the Firebase console, which you add to your source code, connects your app to the Firebase project.

Other Google APIs, such as Maps or Sign in with Google, are managed in Google Cloud Console under the same project. Restrict your API keys there to the app's package name and signing certificate fingerprint.

4. Testing before release

Testing on Google Play starts with internal testing, which you release to a small group of people. A new personal account then has to run closed testing with testers who stay opted in for the number of days Google sets (usually 14). Once you meet the criteria, you apply for production access from the Dashboard and Google reviews your request.

For every uploaded bundle, Google Play automatically runs a pre-launch report, which checks the app with a robot test on several real devices and flags stability, accessibility or security issues. For your own testing on specific devices, you can also use external services. Samsung Remote Test Lab gives free remote access to real Galaxy phones and BrowserStack App Live covers devices from many manufacturers. Appetize runs your app in the browser, which works well for testers, support or a client demo.

5. Crash reporting, monitoring and logging in production

Set up crash reporting before your first release so you hear about crashes from your very first users. Sentry or Firebase Crashlytics catch crashes and also errors that don't crash the app and you'll get basic info about the device and Android version too. If you send the app version with each error (a release in Sentry), you'll see which version introduced a bug and whether the fix worked.

Google Play tracks your app's stability on its own in Android vitals. If your user-perceived crash rate goes above 1.09% or your user-perceived ANR rate above 0.47%, Google makes the app less visible in the store, according to the Android vitals docs. Most mobile apps depend on their own API, so backend logs and API uptime checks belong to your monitoring too.

6. Legal requirements: privacy policy, terms and GDPR

Google requires a privacy policy for every app, even one that doesn't collect any personal data. If people in the EU use your app, the policy also covers your GDPR transparency duties: what you collect, why, how long you keep it and who you share it with. It has to be a public web page, not a PDF, and you need to link it both in Play Console and inside the app.

The Data safety form in Play Console has to match your policy and include data collected by third-party SDKs, typically Firebase Analytics, Crashlytics or Sentry. Under GDPR, you need a data processing agreement (DPA) with every service that processes personal data for you; large providers let you accept it in your account settings. If users can create an account in your app, they must be able to delete it in the app and through a web page. Google doesn't require terms of service, but you'll need them for apps with accounts or payments.

This overview isn't legal advice, so have a lawyer review the exact wording of your documents.

7. What to prepare for Play Console

Before you create the app in Play Console, get the app bundle, marketing graphics and texts ready. Without them, you can't send a new release for review.

8. Keep all your mobile app's links in one place

By release day, a mobile app relies on quite a few services: the repository, CI or the Expo project, Firebase, Play Console, testing services, Sentry and legal documents. In AboutTheApp, you keep links to all of them with the app, sorted into categories. Your team finds them in the dashboard and on the About page, while users in the app see only the public ones.

1. 1

   Create the app

   In the dashboard, click Add product and fill in the name and alias. The alias sets the About page address, for example aboutthe.app/room-booking.

2. 2

   Add links by category

   Click Add resource, pick a category from the table below and paste the URL. Use a custom label to tell apart links in the same category, for example Sentry and Crashlytics.

3. 3

   Decide who sees each link

   Set internal services to private and the privacy policy, terms, support and store page to public. You can give external testers or a testing agency an unlock code, so they see the private links without an AboutTheApp account.

4. 4

   Use the About page as the app's website

   If the app doesn't have its own website, put the About page address in the Website field in Play Console. The Privacy policy field still needs the policy's own URL.

5. 5

   Show the public links in the app

   In a web or hybrid app, embed the About box. In a native app, load the data from the JSON API at https://aboutthe.app/api/v1/abouts/<alias> and show it on your own about screen. When you change a link in the dashboard, the app picks it up without a new release.

9. After approval: staged rollouts and updates

A staged rollout sends an update to a share of your users first, for example 10%. You then watch for problems in Sentry or Crashlytics and in Android vitals. If there aren't any, you raise the percentage, otherwise you can halt the rollout completely.

Every update goes through the same review as the first release, usually faster. Before each upload, bump the versionCode and check the target API level. Play Console takes short release notes, up to 500 characters per language. Add the full release notes in AboutTheApp under Product versions → Add version or let a GitHub Actions step record them. If you're not sure how to number versions, read the guide on app versioning.

Frequently asked questions