June 6, 2026
Version numbers enter the group chat
PaceVer (an alternative to SemVer, for mobile apps)
A new app version system drops — and the comments instantly turn into a numbering war
TLDR: PaceVer proposes labeling mobile app updates by how they reach your phone: big app-store installs versus fast direct fixes. Commenters immediately split between practical concerns about Apple’s rules, people saying date-based labels already solve this, and the brutally honest view that users barely notice version numbers anyway.
A fresh proposal called PaceVer wants to reorganize how mobile app versions are labeled, and yes, people immediately made it about everything else. The idea is simple in plain English: one number for the big public-facing era of the app, one number for updates that need a full app store download, and one number for quick fixes that can be pushed straight to phones. In other words, it tries to reflect how an update arrives, not just how “big” it feels.
But the real show was in the comment section, where the community reacted like someone had tried to reorganize the family group chat. One early question lobbed straight into the chaos was whether Apple even truly allows these fast over-the-air updates, with one commenter asking if the rule is still a ban or just a ban nobody bothers enforcing. That instantly adds a delicious layer of drama: great system, sure, but does the app store gatekeeper agree?
Meanwhile, others were already dragging in rival systems. One commenter basically said, we already have this, pointing to calendar versioning as the less fussy answer. Another flexed their team’s own date-based setup and delivered the bluntest mood of the thread: regular users do not care what the version number is. That’s the hot take humming under the whole debate — is this a smart fix for real mobile app headaches, or just developers inventing a new way to argue over labels? Either way, the comments had the energy of a spreadsheet fight dressed as philosophy.
Key Points
- •PaceVer defines mobile app versions as MARKETING.NATIVE.OTA.
- •MARKETING is team-defined, carries no compatibility promise, and uses 0 to indicate pre-release status.
- •NATIVE increments for releases that require a new store-distributed binary, such as native code, dependency, SDK/runtime, or permission changes.
- •OTA increments for over-the-air updates delivered to an existing installed build, such as JavaScript, styling, content, or asset changes.
- •The article argues PaceVer fits mobile apps better than Semantic Versioning because it encodes release delivery path and pace rather than change magnitude.