Shipping2 min read

The checklist I run before every Google Play release

Target API level, app bundles, testing the upgrade path, Android vitals and staged rollouts: the checks that stand between a solo developer and a one-star week.

Shipping solo means there’s no QA team between you and the reviews. So before every release, big or small, I work through the same list. None of it is clever; all of it has caught something at least once.

Build

  • Target the required API level. Google Play requires new apps and updates to target a recent Android version, and the deadline moves up every year. Check the current requirement in the Play Console before you build, not after the upload is rejected.
  • Upload an Android App Bundle. Play has required .aab files for new apps since 2021, and bundles let Play deliver smaller, device-specific downloads.
  • Build with IL2CPP for ARM64. Play requires 64-bit support, and IL2CPP is the only backend that provides it.
  • Bump the version code. Play rejects an upload that reuses one, and it’s the easiest thing to forget at midnight.
  • Check what went into the build. The Editor log lists every asset by size after a build. One uncompressed texture can add more download size than your whole codebase.

Test

  • Test the release build, not a development build, on the oldest and slowest phone you support. Development builds hide performance problems and skip code stripping.
  • Test an upgrade, not just a fresh install. Install the version that’s live on Play, make some progress, then install the new one over it. That’s where save files break — see Save files that survive your next update.
  • Interrupt it. Lock the screen mid-level, rotate the phone, take a call, background it during an ad, kill it while it saves.
  • Install from the internal testing track. Uploading to Play’s internal track and installing from the store catches signing and bundle problems that a local build never shows.

Release

  • Use a staged rollout. Release to a small share of players first — 10 to 20% — and watch for a day or two before going to everyone. A staged rollout can be halted; a full release can only be followed by a fix.
  • Watch Android vitals. The Play Console tracks your crash and ANR (app not responding) rates. Stay well under Google’s bad-behaviour thresholds, because crossing them hurts how visible the game is on the store.
  • Check the Data safety form. Updating an ads or analytics SDK can change what data the game collects, and the form has to match.

After launch

  • Update the store listing. Fresh screenshots, a “What’s new” that says what actually changed, and a short description that fits Play’s 80-character limit.
  • Answer reviews in the first week. People often raise their rating when you reply and fix their problem, and every reply is public proof that someone is listening.
  • Google Play
  • Android
  • Release

Written by

Logical Programmer

Solo indie developer. I build games in Unity, ship them on Google Play, and document all of it.

Keep reading

All articles
  • Tutorial2 min read

    Object pooling in Unity, the built-in way

    Unity has shipped a generic object pool since 2021. How to use UnityEngine.Pool properly: prewarming, resetting state, and the one mistake that corrupts a pool.

    Read

  • Game design2 min read

    Why your mobile joystick feels wrong

    Three numbers decide whether an on-screen joystick feels sharp or mushy: the dead zone, the travel radius and where the stick’s centre sits. How to tune each one.

    Read

  • Tutorial2 min read

    Save files that survive your next update

    Every update that changes your save format can wipe a player’s progress. A version number, one migration step per version and a safe write stop it from ever happening.

    Read