It seems like it’s about that time of year when people try to impute meaning to Apple’s marketing version numbers and use them to form conclusions of internal development processes. Here’s a thread to demystify them to the best of my knowledge (would be glad to hear corrections!)
First, a couple of clarifications so we can talk about this consistently: if x is the major version, y the minor and z the patch, then for iOS/watchOS/tvOS, the marketing version number is of the form x.y.z. For macOS pre-Big Sur, it’s 10.x.y; it now seems to be x.y.z.
Myth #1: marketing minor versions and patch versions match internal development or have some other useful meaning.
AFAIK, these are mostly decided arbitrarily, hence why I call them “marketing”. The major version matters (updated yearly) but the others just increment on chance.
Myth #2: Apple follows semver.
The minor and patch versions don’t mean much, so no. They usually try to keep APIs stable across minor versions, but aside from that there isn’t really any relation. Hotfixes seem to get patch releases, but this isn’t guaranteed.
Myth #3: macOS Big Sur is such a large change internally that they had to make it macOS 11.
There’s a lot of new stuff, but nothing fundamental has really changed for this to be required. I mean, it shipped as 10.16 for a little while, until engineering caught up with marketing.
TL;DR: the version numbers that you usually see are pretty useless; don’t try to read anything into them. If you want to track development, watch the build number instead, which we will go into now.
Here are some sample build numbers:
20E5229a (macOS Big Sur 11.3 beta 7)
18D70 (iOS 14.4.2)
12A8158a (Xcode 12.0 for Universal Apps beta 1)
They’re strings of letters and numbers of varying length but a fixed format.
The first part is the numbers before the letter; this is the major version that updates yearly. For macOS pre-Big Sur, it’s marketing version+4 (post Big Sur, likely marketing version+9). iOS/watchOS/tvOS share the same number (iOS marketing version+4 as well). Xcode is easy.
Then there is a capital letter; *this* is the real minor version number. Apple runs on a schedule of ~6 of these yearly, and this is what you should be using to track progress. For macOS/iOS/Xcode this starts at “A”, while for watchOS it starts at “R” and for tvOS, “J”.
On extra tidbit about the minor version number: since ~2015 Apple has been using the fifth minor version of the year to drop medium-sized changes around springtime. This year it will be iOS 14.5/macOS 11.3; in past years features have included Night Shift and the iPadOS cursor.
The next field is a bit enigmatic because it doesn’t always exist, and when it does it is not very consistent. In “20E5229a” it’s the “5” and in “12A8158a” it’s “8”; “18D70” doesn’t have it at all. My best guess is that it is some sort of “audience” or internal build category.
Usually developer OS seeds get a “5”, and shipping software has nothing here. Some leaked builds have things like “2” (carrier-destined?) or perhaps even multiple digits–it’s not entirely clear, because this field runs into the next one, the build sequence number.
Whenever Apple runs builds, they stick the sequence number in the build number. Usually this number starts at 1, and runs daily (but it really depends on the release cycle). This number can give you some idea of how long a certain release has been worked on.
First releases have usually been building for a year and have a number in the several hundreds; minor releases usually have about 50-100 builds. The special 5th minor release might have a couple hundred, often seeing development even before the 3rd or 4th one.
The final part of a build number is an optional lowercase letter suffix: this indicates that the build was branched off of the main build and polished separately. It’s alphabetically increasing as you’d expect; it can give a rough idea of how stable the main train is.
Usually see that the WWDC betas have later letters here as they get a lot of fixes to make them shippable as betas, while the main train continues forward with development work with less regard to these details. Ideally this letter will go down until these fixes aren’t needed.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
iOS 14 gives users the ability to control which photos they would like to share with apps, even when they request blanket permissions. @googlephotos specifically detects this and locks the user out until they give full access. I am surprised and outraged that this shipped.
I didn’t even know the API to detect this even *existed* before I noticed Google Photos using it (it’s developer.apple.com/documentation/…). It’s so easy to abuse that I can’t comprehend how it was added alongside the other photos changes, which were designed to be transparent to apps.
Perhaps the designers felt that @AppStore Review would catch misuse; Google is certainly violating section 5.1.1 clause (iv):