July 1, 2026
Shipping an Android app is exciting, but a rushed launch can undo months of good work. Over the past few projects, I’ve built a short checklist I run through before hitting publish on the Play Store.
1. Test on real, low-end devices. Emulators are convenient, but they rarely reveal the jank you get on a three-year-old budget phone. If your app feels smooth on a $150 device, it’ll feel smooth for most of your users.
2. Audit your permissions. Every permission you request is a reason for someone to uninstall before they even open the app. Cut anything you don’t strictly need for the first release.
3. Handle offline and slow-network states. Not everyone has a stable connection. Build explicit loading, empty, and error states instead of letting the app hang or crash silently.
4. Check your APK/AAB size. Large downloads lose installs, especially on limited data plans. Enable code shrinking and compress your assets before you build the release bundle.
5. Have a rollback plan. Use staged rollouts so a bad release only reaches a small percentage of users before you catch it, not everyone at once.
None of these take long to check, but skipping them is exactly how a good app gets a rough first week of reviews.
6. Verify your crash reporting is actually wired up. I’ve seen more than one launch where Crashlytics was added to the project but never initialized correctly, so the first real signal of trouble was one-star reviews instead of a stack trace. Send a test crash from a release build before launch day and confirm it shows up in your dashboard.
7. Read through your Play Store listing as a stranger would. Screenshots, the short description, and the first two lines of the long description do most of the persuading. If they don’t make it obvious what the app does and who it’s for within five seconds, that’s worth fixing before launch, not after.
It’s tempting to skip real-device testing when an emulator on a fast development machine feels smooth. But emulators run on desktop-class CPUs and don’t reproduce thermal throttling, background process pressure, or the fragmented GPU drivers you’ll find across the actual Android device landscape. Google’s own Android Vitals guidance exists precisely because so many apps ship fine in the emulator and then get flagged for jank or excessive battery use once they hit real hardware. I keep a cheap low-end test device on my desk specifically so this check never gets skipped under deadline pressure.
A staged rollout is the safety net that ties all of this together. Even with every box above checked, real users will find things a five-person QA pass never will. Releasing to 10% of users first, watching crash-free rate and ANR reports for 24 to 48 hours, then widening the rollout, turns a potential fire drill into a quiet, boring launch. If you’re weighing whether an app needs to be native at all for your product, I broke down that decision in Web App vs Mobile App: How to Choose the Right Fit.
On one project, everything on this list checked out except one: we skipped the staged rollout because the client wanted “everyone to see it at once” for a coordinated marketing push. A rare device and OS combination we hadn’t tested triggered a crash on first launch for roughly 4% of installs. Because we’d released to 100% immediately, that 4% translated into hundreds of one-star reviews within the first 48 hours, reviews that stuck around long after the actual bug was fixed in the very next release. A 10% staged rollout would have caught the same crash from a few dozen users instead, with almost no public damage.
That single incident is why the rollback plan and staged rollout items are non-negotiable on every project now, regardless of how confident the client feels about the release. Confidence isn’t the same as evidence, and the Play Store’s own crash-free user rate is one of the few pieces of evidence you get before the reviews start arriving.
One more habit worth adding: freeze feature work a few days before submission. The riskiest bugs I’ve shipped were introduced by a “quick” feature addition merged the night before a release build. Locking the release branch and only allowing bug fixes in the final stretch removes that entire category of risk.
A pre-launch checklist isn’t about bureaucracy, it’s about making sure the excitement of shipping doesn’t quietly skip the boring steps that prevent a bad first week.
Relying on remembering seven checklist items under launch-day pressure is how items get skipped. I keep this as an actual checklist file in every project repository, checked off item by item with the specific evidence attached, a screenshot of the low-end device test, a link to the test crash in the dashboard, the actual APK size number, rather than a mental “yeah I think we covered that.” A checklist that lives as a document survives changes in who’s running the release, while a checklist that lives in one person’s head doesn’t.
It’s also worth revisiting the list itself after every launch. Each release tends to surface one new thing worth checking that wasn’t on the list before, a specific manufacturer’s notification behavior, a particular Android version’s permission dialog wording. Treating the checklist as a living document that grows after every release, rather than a fixed template written once, is what keeps it actually useful years into a product’s life rather than gradually becoming outdated advice nobody trusts anymore.
If you take away one thing from this list, make it the staged rollout. It costs nothing extra to set up, and it is the single control that turns an inevitable surprise into a minor fix instead of a public one.
One last habit worth mentioning: after every release, however small, I write a two-line note on what almost went wrong and what caught it. Six months later, those notes are the fastest way to remember why a specific check exists instead of relearning the lesson the hard way a second time.