Skip to content
Tech News
← Back to articles

PaceVer (an alternative to SemVer, for mobile apps)

read original more articles

Where does the OTA number physically live?

Not in the binary's store version. An OTA update can't rewrite that, and that's fine. The app composes its version at runtime: it reads MARKETING and NATIVE from the binary and OTA from the applied update's manifest (e.g. Updates.manifest / extra in Expo). A fresh install with no update applied reports OTA 0 .

Does a higher OTA number mean a bigger change?

No. OTA counts over-the-air releases, not their size. A typo fix and a new screen both bump OTA by one. If you care about magnitude, spend the MARKETING number on it.

Does bumping MARKETING reset NATIVE and OTA to zero?

By default, yes. A MARKETING bump goes to X.0.0 , exactly as a NATIVE bump resets OTA, so a redesign from 1.6.2 lands on 2.0.0 . This is the recommended convention, but resetting on a MARKETING bump is not mandatory; see the next question.

Can I skip the reset and let the numbers keep climbing?

Yes. Instead of resetting, you may let MARKETING float as a pure label while NATIVE and OTA keep climbing, so 1.6.2 becomes 2.6.2 rather than 2.0.0 . The tradeoff: you give up the clean X.0.0 era boundary, but you keep a single monotonic native and OTA count across the whole life of the app, which some teams find easier to reason about. Precedence still works either way, since versions compare left to right. Whichever you pick, apply it consistently. (A new NATIVE build always resets OTA regardless; that part is not optional, because a new binary starts a fresh OTA lineage.)

Can I bump MARKETING or NATIVE with an over-the-air update?

No. MARKETING and NATIVE live in the installed binary (rule 8), so changing either one means shipping a new native build. Only OTA moves without a new binary, which is why a MARKETING or NATIVE change always lands with OTA back at 0 .

... continue reading