Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
I've been using calendar versioning quite happily with my mobile apps for a while now. It reduces the amount of angst and bike-shedding that comes along with otherwise rev'ing a major version number.
For our mobile app we ended up doing YEAR.WEEK_NUMBER.BUILD. It makes it much easier for our team to know how old a version is (support, analytics, engineering). And regular users don't care about the version
Officially, they are allowed if they consist of interpreted code and don't significantly change the functionality of the app as reviewed. Unofficially, they probably don't have a robust enforcement mechanism.
>MARKETING.NATIVE.OTA
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
https://www.jetbrains.com/idea/whatsnew/2025-3/
In the article they call out that MARKETING can be date based
I've been using calendar versioning quite happily with my mobile apps for a while now. It reduces the amount of angst and bike-shedding that comes along with otherwise rev'ing a major version number.
For our mobile app we ended up doing YEAR.WEEK_NUMBER.BUILD. It makes it much easier for our team to know how old a version is (support, analytics, engineering). And regular users don't care about the version
What’s the state of OTA updates, does Apple still prohibit them, or is it just not enforced?
Officially, they are allowed if they consist of interpreted code and don't significantly change the functionality of the app as reviewed. Unofficially, they probably don't have a robust enforcement mechanism.