Xpense Dev Retrospective
Everything up to this point, the code, the database, the theming, signing, gets you a real .aab file sitting on a computer. Getting that in front of an actual stranger who downloads it from the Play Store is a separate process entirely, with its own requirements that have nothing to do with whether the code works.
Before a single listing can exist, a Google Play Developer account has to be registered, a one-time fee, identity verification, and for an individual developer, a personal identity check rather than a business one. This isn't a quick toggle, it's a real verification step, and Google's own processing time for it isn't instant.
| Requirement | What it actually is |
|---|---|
| Store listing | App name, description, screenshots, feature graphic, icon |
| Content rating questionnaire | A form determining the app's age rating based on its actual content and features |
| Data safety section | A declaration of what user data the app collects and shares, if any |
| Privacy policy | A hosted, publicly accessible page, required even for an app collecting no data |
| Target API level compliance | Must meet Google's current minimum targetSdk requirement at submission time |
The data safety section was genuinely simple for Xpense. Every expense, every settlement, every setting stays entirely on the device. There's no account system, no server, no analytics phoning anything out. The honest answer to almost every question on that form is "this app doesn't collect that."
New developer accounts don't get to publish straight to production. Google requires a closed testing track first, a real group of opted-in testers actually using the app for a minimum period, before production access opens up for a first app from a new account.
Build uploaded to a closed testing track rather than production.
A group of testers opted in, meeting Google's minimum tester count for that track.
Testers actually install and use the app for the required minimum number of days.
Once that period and tester threshold are satisfied, production access opens up for the account.
This isn't a formality to route around. It's the actual mechanism Google uses to slow down bulk publishing of low-effort or malicious apps from brand new accounts. Rushing testers who don't genuinely use the app, or trying to game the tester count, defeats the entire point and risks the account itself, not just this one app.
Once production access exists, uploading a new .aab through Play Console, filling in a release name and release notes, and rolling it out is the actual mechanical publishing step, genuinely the simplest part of this whole process. Google runs its own automated and sometimes manual review on every submission, new app or update, before it goes live.
Worth naming honestly: Play Console's exact screens and flow shift over time as Google changes the interface. The requirements described here, developer verification, content rating, data safety, closed testing before production, are the real substance of the process. The specific click-by-click layout of any given screen isn't something worth memorizing here, since it's the part most likely to have already changed by the time this is read.
That's the full arc, from a Java file with a flat JSON blob to a Kotlin app backed by Room, signed, and sitting on the Play Store with real people using it. Every post in this series covered something that was either learned the hard way or decided on purpose, sometimes both at once. Whatever gets built next on top of Xpense gets its own posts when it happens.