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.

Can I roll back a native release?

No, and that's by design: like the app stores themselves, PaceVer has no concept of a native rollback. NATIVE only ever moves forward (rule 2's precedence), and an OTA release is scoped to the native build it was produced for (rule 9), so you can't drop users back onto a previous binary's OTA lineage. To recover from a bad native build you re-release the previous good build's content forward under a new NATIVE number, for example shipping what was NATIVE 5 again as NATIVE 7, and go from there. OTA, by contrast, can be rolled back within the same native build, as fast as it ships.

A native change only affects iOS. Do I have to release Android too?

Yes, and on purpose. A NATIVE bump ships a new binary to every platform, even one with no functional change, so all platforms stay on the same NATIVE build. This is for OTA's sake: OTA releases are scoped to a runtime, so keeping every platform on a common runtime lets one OTA release land everywhere under a single OTA number. The seemingly redundant Android build usually isn't empty anyway: bumping NATIVE bumps the runtime, so it's a real new binary, just without feature changes. The cost is one extra store submission; the payoff is one coherent version line for the whole app.

My app is also on the web. There's no native build there.

PaceVer doesn't cover web. Web (and PWAs) has effectively one channel (every deploy is over the air), so the native/OTA split doesn't apply. Version web on its own terms.

Can I use PaceVer for my library or backend API?

No. Use SemVer. PaceVer says nothing about API compatibility, which is the whole point of versioning a library. PaceVer is for shipping apps, not contracts.

Why isn't PaceVer versioned with PaceVer?

Because PaceVer is for apps, and this is a document. A spec has no native build and no over-the-air channel. It has a contract that other people rely on, which is exactly what the Scope rule says to version with SemVer. So PaceVer eats its own rule and ships as SemVer. SemVer versions itself; PaceVer versions itself with SemVer. Each tool to its job.

What about the very first release?

Start at 0.1.0. MARKETING 0 is the pre-release era, and you build through 0.x until the app is ready. When it's ready for the public, bump MARKETING to 1. With the recommended reset that lands you on 1.0.0; if you don't reset, you carry your running numbers to 1.y.z. The recommended path is simply 0.1.0 → 1.0.0 → onward. The exact moment doesn't really matter; it's a flag you raise when it feels true.

I already ship under SemVer. How do I migrate?

Don't reset downward. The App Store and Play Store reject a marketing version that decreases, so an app already at, say, 3.4.1 cannot adopt PaceVer by starting over at 1.0.0. Because MARKETING is a free, monotonically non-decreasing number, keep your current leading number as MARKETING and start applying PaceVer's NATIVE and OTA semantics from where you are. The 0.1.0 start and the reset rules are for new projects; an existing app carries its history forward.