Two numbers, two different jobs
Every Android app carries a versionName — the label people see, like "1.4.2" — and a versionCode, an integer nobody sees that decides everything. A phone installs an APK over an existing one only if its code is equal or higher; Google Play accepts an upload only if its code is higher than every previous upload. The name can say anything. The code is the law.
For a website app that updates itself through its URL, months can pass between builds. When you do rebuild — a new icon, a tab added, a permission — the code must go up, and it is easy to forget which number you used last. Pick a scheme once and the arithmetic does it for you.
The schemes
- Semantic — major × 10000 + minor × 100 + patch. "1.4.2" becomes 10402. The code is always higher when the name is higher, and anyone can read the name back out of it.
- Date — yyMMdd. Today's date as a number. Simple, obviously increasing, one release per day.
- Date + build — yyMMddBB. Date plus a two-digit build counter, for days with more than one build.
- Simple increment — 1, 2, 3. Never wrong, tells you nothing.
The ceiling is 2,100,000,000. Full date-times like 202609111430 exceed it on the first build and are the classic way to lock an app out of ever updating; the date schemes here stay well under it.
What makes an update an update
Same package name, higher version code, same signing key. Miss any one and it is not an update: a different package name is a second app, a lower code is refused, and a different key is refused with a signature error no version bump can fix. That is why Pro's own-signing-key feature exists — Play updates need the same key every time. Bump the code for every build you might hand to anyone, including testers; a tester on code 5 cannot install your fixed build if it is also code 5. The version guide →