What Changes After an App Hits 1.0

Before an app hits 1.0, releasing it is easy. You build it, you upload it, testers get it. If something's wrong, you upload another one an hour later. Nobody is waiting on it, and nobody notices the version number.

That changed this month. I submitted PlaySori 1.0 to Apple's App Review on October 14, and five days later Crease 1.0.0 went to Google for production review. Game Night already has users on Google Play. So for the first time I have three Android apps at the same stage, and the loose way I'd been shipping stopped being good enough.

Here's what actually changed.

The Version Number Means Something Now

On a pre-1.0 app, the version is a label. After 1.0, it's a contract with the store.

Apple is the strict one. Once a version is approved, that version is closed. You can't upload another 1.0 build, even a tiny fix, so every upload after that has to be 1.0.1, 1.0.2, and so on. I made that the rule for PlaySori the week I submitted it: every store upload gets a patch bump, no exceptions. The bump went in as its own small pull request, with a commit message that says why.

Google cares less about the version name and more about the version code, the hidden number that has to go up with every upload. Bumping it by hand is easy to forget. Crease and PlaySori now set it automatically to the number of minutes since January 1, 2026. It always goes up, two builds can't collide, and I never think about it.

Game Night is older and works differently. Its version code comes from the version in package.json, so 1.2.42 becomes 1002000042. It's not how I'd set it up today, but it works, and changing a live app's numbering scheme isn't worth the risk.

Production Is a Manual Click

The script I use to upload builds can push to internal testing and closed testing. It can't release to production. That's on purpose. The account it runs as doesn't have production rights, and the script refuses the production track even if you ask.

Production is me, in Play Console, promoting a release I've already tested. I also leave managed publishing on, so even after Google approves an update, it doesn't go live until I click publish. That way an approval that lands at 11 at night waits for the morning.

It's one extra step. After 1.0 there are real users on the other end, and I'd rather lose thirty seconds than ship something by accident.

One Checklist for Every App

All three apps now go through the same steps:

1. Check the branch, and check what's already live, so the new version is actually newer.
2. Bump the version the way that app does it.
3. Run the tests and lint locally. Not every repo has CI, so the local run is the bar.
4. Build and sign, and write down the version code it prints.
5. Upload to internal testing, then trust the readback from the store, not the upload command.
6. Tag the commit the build came from.
7. Promote to production by hand.

None of that is new. What's new is that it's written down once, and each app's quirks are noted next to it instead of living in my head.

The Quirks Are the Whole Point

The checklist is short. The notes under it are where the value is, because each one is a mistake I made or came close to making.

Game Night is an Ionic app, so the Android build packages whatever web code was last copied into it. In September I published two releases that showed the right version number in Play Console and still contained the old app inside, because I'd skipped the web build step. Now the notes say to never run the Android build alone, and spell out the full sequence.

Crease is a widget app. Installing a store-signed build over a debug build forces an uninstall, which wipes every folder and widget on the phone. For a folder app, that's the whole app. The notes say which build to use for testing on my own phone so that never happens.

And on a brand-new Play listing, in-app purchases show "item not found" until you send the app's first changes for review. Waiting doesn't fix it. Only sending it for review does.

What I'd Tell Myself at 0.9

Write the release steps down before 1.0, not after. Before 1.0 is when mistakes are cheap, and it's also when you find out what your app's weird parts are.

I still review every change that goes into a release, which I wrote about in why I still manually review every pull request. The checklist doesn't replace that. It makes sure the reviewed code is what actually ships. If you want a hand getting your own app to 1.0, that's what my mobile app work is for.