App version numbers
Every build ships with a version like 2.4.5, worked out from what you changed
in the builder since your last build. You do not set it and cannot edit it.
This page explains what moves each part, so a version number tells you something when you see it in App Store Connect six months from now.
What the three parts mean
Section titled “What the three parts mean”Read the number left to right. Each part answers a different question about the release.
| Part | Moves when |
|---|---|
Major — the 2 | You deleted a screen, a whole navigation zone appeared or disappeared, or you changed the app’s identifier |
Minor — the 4 | You added a screen, changed what a screen is, reordered your navigation, or moved a screen from one zone to another |
Patch — the 5 | Anything else that reaches the app: labels, icons, colours, per-screen settings, global settings, template content |
Only the highest part that applies moves, and the parts below it reset. A build
that adds one screen takes 2.4.5 to 2.5.0, not 2.5.5.
If a single build both adds a screen and deletes another, that is a major release. Someone already using your app has lost a screen, and that is the fact worth reporting.
When the number moves
Section titled “When the number moves”At the Build press, not when you save. The builder saves as you work, so a version that moved with every save would count keystrokes rather than releases. An app you edited fifty times and built once has had one release.
Every change you made since the last build is collected into that one press. Add three screens and recolour the whole app, and the next build is a single minor release.
Pressing Build with nothing changed keeps the version exactly where it is. The
number after the + still moves, which is what lets you upload the same version
twice.
The number after the plus
Section titled “The number after the plus”The full version stamped into a build looks like 2.4.5+1847. The part after
the + is the build number, and it goes up every single build.
The two are for different things:
- The version is what people see in the store listing, and what you use to tell releases apart.
- The build number is what Google Play and App Store Connect use to refuse a file they have already seen. It has to be unique, and it never goes backwards.
Both stores reject an upload whose build number they already hold, which is why it moves even when nothing else did.
Where you see it
Section titled “Where you see it”On each build row in your app’s build history, beside the platform. Older builds made before version numbers existed show no version — only the build number.
Inside the app, on the launch screen, if you turn on Show version on launch screen in the Launcher tab. That is off by default.
iOS and Android get the same version
Section titled “iOS and Android get the same version”One press of Build makes an Android build and, when your app is ready for it, an iOS build. Both carry the same version number, because one press is one release.
Their build numbers differ. iOS builds use a separate count, shown in brackets on the build row, because App Store Connect tracks its own sequence.
Where existing apps start
Section titled “Where existing apps start”Every app that existed before version numbers begins at 1.0.0 and stays there
for one more build. That first build has nothing to compare itself against, so it
records where your app is now and ships 1.0.0.
The build after that is the first that can move, and it compares against what that build shipped.
What this means for store updates
Section titled “What this means for store updates”Both stores require the version to go up with each release you publish. It only ever goes up here, so a build is always acceptable as an update to the one before it.
If you have already published a version by hand that is higher than the number
Memberside is at — say you uploaded 3.0 yourself before connecting the app —
the store will refuse builds until Memberside catches up. Get in touch rather
than working around it.
When it doesn’t work
Section titled “When it doesn’t work”| Symptom | Cause | Fix |
|---|---|---|
| The version did not change after a build | Nothing that reaches the app changed since the last build | Check you saved; the preview updating is not a save |
| A colour change bumped the patch, as expected, but so did a build where you only renamed a template | Template content is compiled into the app, so editing it is a real change | Nothing to fix — the version is correct |
| A minor bump you did not expect | Reordering navigation counts: the order is what your members see | Nothing to fix |
| A major bump you did not expect | A navigation zone emptied, or a background screen’s feature was removed, taking a screen with it | Check the zone you last edited still has screens in it |
| The version jumped by more than one release | Several builds’ worth of edits were collected into one press | Nothing to fix — each press is one release, however much it contains |
| You need a specific version number for a store deadline | Versions cannot be set by hand | Get in touch before you submit |
How builds work covers what runs during a build, and Submitting your app covers getting it into each store.