Your first release is live. Sooner or later you will change something, and an update on Google Play has rules the first upload did not: a number that must go up, a signature that must match, and no undo button. This guide is the routine for shipping updates without locking yourself out of your own listing.
Does a website app even need an update?
Often not. An app that shows your website picks up every change to the site the next time it loads a page: new products, new articles, a redesigned checkout. None of that needs a Play release. You need a new build when something inside the app package changes:
- the app name, icon or splash screen;
- permissions (the camera for a new scanner page, notifications, location);
- native settings baked into the build: ads, push provider, deep links, share targets, the start URL of a bundled app;
- Google Play's yearly target API level deadline, which forces a rebuild even if nothing else changed;
- a fix to the app shell itself.
If you only want to change the start page, show an announcement or put the app into maintenance, check whether your builder supports a remote update file first: it changes installed apps without a store review.
The two version numbers
| versionCode | versionName | |
|---|---|---|
| What it is | A whole number | Free text, e.g. 1.4.2 |
| Who sees it | Android and Google Play only | Users, on the listing and in app settings |
| Rule | Must be higher than every version code ever uploaded to the app, on any track | No rule; keep it meaningful |
| Limit | 2,100,000,000 | - |
The rule that catches people: the code must beat every upload, including a build you uploaded to internal testing and then abandoned. If Play Console says "Version code 3 has already been used", raise it past the highest one and build again. Many builders derive the code from the version name (for example 1.2.3 becomes 10203), which keeps the two in step as long as the name only ever goes up.
The signature must match
Every update must be signed with the same upload key as before (with Play App Signing, Google re-signs for users; your upload key only proves the upload is yours). Build the update from the same place, with the same package name, so the same key is used. A different key produces "The APK or Android App Bundle was signed with the wrong key" and the upload is refused. If you really have lost the upload key, Play Console lets you request an upload key reset under Setup → App integrity; it takes a few days and is not a way to change the package name.
Shipping the release
- In Play Console open Test and release → Production (or a testing track first) and Create new release.
- Upload the new AAB. Play checks the version code and signature immediately; fix those before anything else.
- Write release notes: up to 500 characters per language. Say what changed for the user ("Faster checkout, dark mode"), not "bug fixes and improvements".
- Choose the rollout percentage (next section), review, and send for review.
Updates are reviewed like first releases, usually within hours to a few days. If you want an approved update to go live at a moment you choose (a launch date, an announcement), turn on Managed publishing before submitting: approved changes then wait until you press Publish.
Staged rollouts
A staged rollout gives the update to a percentage of your users first. Google picks them at random; the rest keep the old version until you widen it.
| Stage | Typical share | Watch for |
|---|---|---|
| 1 | 5-10% | Crashes and ANRs in Android vitals, one-star reviews mentioning the update |
| 2 | 20-50% | The same, plus support email |
| 3 | 100% | - |
Give each stage a day or two with enough users to mean something. For a small app, 20% and then 100% is fine. New installs during a staged rollout may get either version, so do not announce a new feature until you reach 100%.
When a release is bad: halt, then fix forward
Google Play has no rollback. Android refuses to install a lower version code over a higher one, so you cannot push the old build back. What you can do:
- Halt the rollout (Production → the release → Halt rollout). Nobody new receives the update. Users who already installed it keep it.
- Fix forward: build the previous, working state again with a higher version code and release that. For a website app this is usually quick: the old settings, a new number.
- Resume or replace: once the fixed build is approved, roll it out as normal.
This is the strongest argument for staged rollouts: a halt at 10% means 90% of your users never saw the problem.
A routine that avoids surprises
- Keep a note of every version name and code you upload, including test tracks.
- Install the new APK over the old one on your own phone before uploading. If it installs as an update, the signature and version code are right.
- Check the Pre-launch report Google generates for each upload: it runs your app on real devices and flags crashes and accessibility problems.
- Update the Data safety form in the same session if the release changes what data you collect.