hoakley July 6, 2020 Macs, Technology

Why Big Sur won’t stumble over version numbers

The surprise announcement of WWDC this year wasn’t the new Apple Silicon Macs, which had been widely expected, but the decision to number the next major version of macOS 11.0 rather than 10.16. That’s one choice Apple could have come to regret, and this article explains how it’s having to engineer its way out of breaking features in existing apps.

Ever since anyone can remember, Apple has identified Mac operating system versions using three version numbers:

The first is the major version number, which ran up to 9 in Classic Mac OS, and has been 10 ever since the first release of Mac OS X.
The second is the minor version number, which in Classic days seldom rose far. In recent Mac OS X, though, there’s been a new version each year, such as Mojave 10.14 and Catalina 10.15.
The third is the patch number. In recent macOS, this has risen to x.x.6 at the end of each release cycle.

In the five years from the release of Mac System Software 1.0 in 1986, the major version rose to 7. When you developed software for Classic Mac OS, it was usually that number which counted most in determining features and compatibility. Then, when Apple released Mac OS X 10.0 in 2001, version numbering changed completely. Over those 19 years, the major version has remained fixed at 10, and the minor version has steadily climbed to 15.

We’re all well aware of the multitude of changes that come with each new ‘minor’ version. My apps that offer log extracts but run on El Capitan and later require code to disable their log feature for 10.11, as the unified log wasn’t introduced until 10.12. Commands using softwareupdate have also changed with different versions of macOS.

To cater for all these differences, many apps use conditional statements. In effect, they might say ‘if I’m running on Sierra, do this; if it’s High Sierra or later, do that.’ One of the most widely used methods of checking which version of macOS is running is to inspect the Operating System version; in Swift, a call such as ProcessInfo.processInfo.operatingSystemVersion returns complete information ready for use in the conditional.

So a typical code fragment in Swift might be
let osVersion = ProcessInfo.processInfo.operatingSystemVersion.minorVersion if (osVersion > 13) {
// we’re on Mojave or later
} else if (osVersion == 13) {
// we’re on High Sierra
} else {
// we’re on Sierra or earlier
}

Most of us had assumed that the next major release of macOS, now dubbed Big Sur, was going to continue the number sequence as 10.16. Apparently not long before it was announced at WWDC, this was changed to become 11.0, with the major version number incremented from 10 to 11, and the minor version number reset to 0 from 15. If you step your way through the example code above, you’ll notice that it could now break. If Big Sur were to be numbered 10.16, the first if condition would be satisfied, and it would be treated the same as Mojave and later. If Big Sur were to be 11.0, then the app would fall through to the last of the conditionals, and be treated the same as Sierra and earlier, clearly the wrong choice.

The only solution which wouldn’t break a great deal of existing software would be for Big Sur to return a major version of 10 and a minor version of 16. But at the same time, it has to return a major version of 11 and a minor version of 0, or it wouldn’t really be macOS 11 after all. And Big Sur actually does both, depending on how it’s asked.

Apps which have been developed with Xcode 11 and earlier use the 10.15 SDK and its antecedents; when they check ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identifies itself as macOS 10.16. This is the most compatible solution, and should, for instance, allow you to run your existing Intel apps on Apple Silicon without them acting as if they were running on OS X 10.0.

Apps which are being ported to Xcode 12 use the 11.0 SDK; when they check ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identifies itself as macOS 11.0. This has been confirmed for the DTK by @yiningkarlli.

There’s one temporary issue: the initial developer beta for Intel Macs doesn’t yet work like that, but seems to return a version number of 10.16 to everything. Apple mentions this in its macOS Big Sur 11 Beta Release Notes:
“The system ProductVersion is reported as 11.0 only on the Developer Transition Kit at this time. Existing Mac systems will temporarily report the value as 10.16.”

This is unfortunate, as it makes porting to Intel Macs too easy. Conflicts with Big Sur’s version number therefore won’t become readily apparent until Intel beta releases behave as does the DTK. But this only applies to those apps which have already been built with Xcode 12 on Intel Macs.

There’s also a sting in the tail for those who use development systems other than Xcode: they need to check how their SDK handles macOS versions on both Intel and Apple Silicon Macs. This is most critical for anyone using command tools to detect the version of macOS which is running. Among the most popular is
sw_vers -productVersion
which currently returns 10.16 when running in Big Sur on an Intel Mac, presumably changing soon to 11.0, and 11.0 on an Apple Silicon Mac, as stated by Apple.

As I wrote last week, this is going to prove one of the biggest headaches for developers, scripters and users when upgrading to Big Sur. There are lots of possible workarounds, but for those who don’t need to worry about macOS 10.9 or earlier, or macOS 11.10 or later, one quick fix is:
var osVersion = ProcessInfo.processInfo.operatingSystemVersion.minorVersion if osVersion < 10 { osVersion += 16 }

In the longer term, it would be much simpler if Apple were to provide a monotonically increasing positive integer which increased by 1 with every patch number. This would spare everyone from having to change code whenever a new major version appears.

When you upgrade to Big Sur, remember that some software may behave strangely, as if running on a much older version of macOS. If you come across any, ask its developer whether it detects the macOS version number correctly.

34Comments

Add yours

1

Michael on July 6, 2020 at 7:37 am

There is actually a monotonically increasing positive integer: the Darwin major version. You can get the Darwin version from “sysctl kern.osrelease”. That version has been monotonic since Mac OS X Server 1.0 (see https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history). Catalina is version 19, Big Sur is version 20.

LikeLiked by 1 person
- 2
  
  hoakley on July 6, 2020 at 8:39 am
  
  Thank you.
  No: that’s the kernel major version, which has changed with each macOS minor version, although there’s no rule that says that it has to. That reflects what happens with the kernel, which for the great majority of features (and bugs) in macOS isn’t the same as the macOS version. The kernel major version usually doesn’t change with macOS patch number changes, which can also be important, and the kernel minor version changes relatively independently of macOS version too.
  As I wrote above, we need a single integer which increments with each macOS patch number change. It’s not difficult, is it?
  Howard.
  
  LikeLike
  - 3
    
    Dave Jewell on September 16, 2020 at 12:51 pm
    
    There’s also kern.osversion which (as the name suggests) might hopefully reflect the OS version rather than the kernel version. This is what’s shown in brackets in the “About this Mac” dialog box. Currently “20A5364e” on Big Sur Beta 6. It looks reassuringly hex-like, so my inclination would be to grab that, convert it to decimal and use it as the coveted single integer you crave. Then again, maybe I just like to live dangerously? 😄 Dave
    
    LikeLiked by 1 person
    - 4
      
      hoakley on September 16, 2020 at 10:05 pm
      
      Thank you.
      I’ve settled for calculating my own version number now, which I can adapt as and when Apple lets us know how they’re numbering versions.
      Howard.
      
      LikeLiked by 1 person
5

Jon on July 6, 2020 at 12:11 pm

Bad programmers make bad assumptions, such as “it hasn’t changed in 15 years, so it will never change”.

The correct way to check for version numbers is to include the major number, too:

if major > 10 then Big Sur or later;
if minor > 15 then Big Sur or later;
if minor > 14 then Catalina or later;
if minor > 13 then …

It’s also Apple’s fault for needlessly changing the public API. First we had to use Gestalt() to get the OS version number, then parse a system .plist, now we are supposed to use ProcessInfo.processInfo.operatingSystemVersion.)

(ProcessInfo.processInfo.operatingSystemVersion is only available on macOS 10.10 and higher. On earlier versions — at least as far back as 10.3 — Gestalt() could be used, but Apple deprecated that in 10.8 and spit out annoying log messages if it was used. Since then, my code has been parsing /System/Library/CoreServices/SystemVersion.plist. It still does, in fact, since it supports all Intel versions of OS X and macOS, from 10.7.5 up.

LikeLiked by 1 person
- 6
  
  hoakley on July 6, 2020 at 12:27 pm
  
  Thank you. My rejoinder is that bad programmers write inefficient code!
  Besides, you’re making the assumption that you can always access that property list to parse it. Should Apple decide to alter that, that too would prove to be a bad assumption.
  Every line of code that you write makes assumptions, particularly about macOS. Normally Apple issues warnings in the form of deprecations long before anything changes, just as it did when Gestalt() was removed. In this case, it appears that its own engineers were caught on the hop – which is why the first beta of Big Sur on Intel still reports that it’s 10.16.
  Howard.
  
  LikeLike
  - 7
    
    Jon on July 6, 2020 at 4:59 pm
    
    My code doesn’t need to know that 10.16 and 11.0 are synonymous, only that it is running on “CatalinaOrLater”, “MavericksOrLater”, etc. “BigSurOrLater” works because both 11.0 and 10.16 are bigger than 10.15. (I do assume that each of major, minor, and patchVersion are monotonically increasing : )
    
    It works if Apple decides to have both a 10.16 and a 11.0, too, or if 10.16 is on Intel and 11.0 is on Apple Silicon. If 11.0 (for Apple Silicon?) is different in a way that affects my code and they don’t give it a separate name, I might have to make up my own name for it and create “BigArmOrLater” or something, which would test for major > 10.
    
    **Thanks very much for bringing up this situation, though and making me look at my code.** I’m revising it to use operatingSystemVersion if the method and its class are available and fall back on using ProductVersion in the .plist if not. That will work in all the OS versions I support, and I hope for a while into the future. (Back when the original code using the .plist was written, operatingSystemVersion didn’t exist.)
    
    LikeLiked by 1 person
- 8
  
  hoakley on July 6, 2020 at 1:52 pm
  
  I’ve been thinking about what you could do with the major version number when you don’t know how to interpret it, and I’d be fascinated to know how you used it before knowing that 10.16 and 11.0 were synonymous.
  Three months ago, you might have assumed (wrongly) that the next release of macOS would either be 10.16 or 11.0, but not both. So, when making any comparison between versions, you couldn’t have known which ranking order to place them, and placed 11.0 as being later than 10.16, indeed later than 10.anything. So your code would still have to be changed in the light of the new version numbering.
  This would have been even more complex had Apple decided to fork macOS, and left Intel builds on 10.x and Apple Silicon builds starting with 11.0 – another assumption which you would have had to make in interpreting the major version number.
  Or am I missing something?
  Howard.
  
  LikeLike
9

Pico on July 6, 2020 at 6:53 pm

Have you noticed that there is now a “/System/Library/CoreServices/SystemVersionCompat.plist” file alongside “/System/Library/CoreServices/SystemVersion.plist”?

Speculating, but this is likely part of how macOS will internally supply different versions based on which SDK is used or which program is performing a system call.

In fact, I can even see on Big Sur beta 1 on Intel that calling “sw_vers” in Terminal shows a ProductName of “macOS” (presumably supplied by “SystemVersion.plist”) and when I used an internal cross-platform Java app, calling System.getProperty(“os.name”) returns “Mac OS X” (presumably supplied by “SystemVersionCompat.plist”). Now, we could assume there is a special catch for Java code, or more likely it’s just because Java 14 was not build with the Big Sur SDK. Regardless, we can see that even Big Sur beta 1 on Intel has the foundations is in place to be able to supply different OS information based on how it’s being requested (or who is requesting it).

This seems pretty cool! Of course I’ve already made sure all my code can handle macOS 11 as a version, but it’s nice to know and cool to see how old code won’t be easily broken.

At this moment though, it seems like this won’t offer any help to bash/shell scripts which are calling “sw_vers” directly.

LikeLiked by 1 person
- 10
  
  hoakley on July 6, 2020 at 11:16 pm
  
  Thank you – that’s fascinating.
  However, be very careful about jumping to conclusions for the moment. The intention of macOS 11 is that, for existing builds using the 10.15 SDK and earlier, it pretends to be 10.16 for maximum compatibility, but for anything built with the 11 SDK it will report itself as 11.0. This first beta for Intel Macs isn’t yet following that, as it always reports as 10.16, but that will change in a future beta.
  So before you can draw any conclusions as to how this will work, you need at the least results from a DTK, and preferably from an Intel Mac running the next beta (assuming that does report its version ‘correctly’). All that I hear is that, on the DTK, sw_vers consistently reports the version as 11.0, but on Intel is always reports 10.16.
  Howard.
  
  LikeLike
  - 11
    
    Pico on July 7, 2020 at 12:57 am
    
    Definitely making a few assumptions without all the info, but it is still noteworthy that even on Big Sur beta 1 on Intel SystemVersion.plist contains the ProductName “macOS” (it has always been “Mac OS X” before, throughout all previous marketing name changes) even though it still reports the version as 10.16. And SystemVersionCompat.plist continues to report “Mac OS X” and also version 10.16.
    
    This is what makes me think that the foundation of that difference in version reporting you’re talking about is already set up in Big Sur beta 1.
    
    If I had to bet, I would guess that the DTK is a newer build than beta 1 and that in that build, SystemVersion.plist contains a version of 11.0 while SystemVersionCompat.plist contains 10.16. But, I don’t have a DTK myself to know for sure.
    
    LikeLiked by 1 person
12

Pico on July 6, 2020 at 7:47 pm

Thinking about your quick-fix of adding 16 to macOS’s minorVersion…

In the no-so-long-term, I think this may cause more problems than it solves.

While nobody knows for sure at this point, my gut tells me that macOS 11 is the end of long-lived major version numbers for macOS.

I think over the course of the year, we will get macOS 11.1, 11.2, 11.3 updates, like we do with iOS versions (rather than 11.0.1, 11.0.2, 11.0.3) and the next major version of macOS will be 12.0.

LikeLiked by 1 person
- 13
  
  Pico on July 6, 2020 at 8:04 pm
  
  This would also mean no more silly “Supplemental Updates” to macOS versions since they could actually use the Patch version number for, you know, patches.
  
  This really could be Apple just making the macOS versioning scheme make sense again. We got so used to the minorVersion being treated as the majorVersion that this seems like some big weird change, while in fact this is just a return to versioning normalcy.
  
  LikeLiked by 1 person
- 14
  
  hoakley on July 6, 2020 at 11:10 pm
  
  Thank you. We don’t know whether Apple intends to change that way. If it does, then the great majority of apps which have to run different code for different versions will need to be modified.
  The most important considerations at present are that existing apps run correctly, which is being handled by macOS, and that interim builds to work with betas and the DTK, work correctly. Modifying that code so that it caters for a completely different version system isn’t a big deal, and doesn’t need to be completed for a few months yet in any case.
  Howard.
  
  LikeLike
15

rogparish on July 8, 2020 at 12:37 am

A minor nit: “Classic” Mac OS (pre-OSX) went up to 9.2.2.

LikeLiked by 1 person
- 16
  
  hoakley on July 8, 2020 at 5:58 am
  
  Thank you. System 9.2.2 wasn’t released until the end of 2001. As I wrote above, the major version number in Classic Mac OS rose to 9.
  I wrote above: “In the five years from the release of Mac System Software 1.0 in 1986, the major version rose to 7.”
  System 1.0 was released in February 1986, and System 7.0 in May 1991. That’s a period of just over 5 years, which is what I wrote above. It took a further decade for it to rise from 7.0 to 9.2.2, over which period the major version number changed much more slowly. That’s why I quoted just those first five years.
  Howard.
  
  LikeLike
17

How to Decode Apple Version and Build Numbers - Apple's Hub on July 8, 2020 at 5:39 pm

[…] solely the minor model quantity. For sure, such sloppy code may break in Large Sur. Fortunately, as Howard Oakley explains, Apple has made some effort to mitigate this downside by having Large Sur return 10.16 slightly […]

LikeLike
18

How to Decode Apple Version and Build Numbers - TidBITS on July 9, 2020 at 9:45 pm

[…] only the minor version number. Needless to say, such sloppy code could break in Big Sur. Luckily, as Howard Oakley explains, Apple has made some effort to mitigate this problem by having Big Sur return 10.16 rather than […]

LikeLike
19

Gord on July 10, 2020 at 1:38 pm

If Apple was going to change the version number, and cause these headaches for developers, I think they should have designated Big Sur as version 17.0, since Big Sur will be the 17th major release, if you count from version 10.0, the first major release. A way to pay tribute to the longevity of the modern Mac OS… it’s the older brother of iOS, so by rights its version number should be larger.

The 10.x convention for major release version numbers was always kinda awkward and non-standard… I assume the reason they didn’t start Mac OS X with “version 1.0”, as one might expect them to, was so as not to break OS-version-checking routines for apps that were ported over from older Mac OS versions (“Carbonized”). But this legacy holdover was well past its due date. (The roman numeral ‘X’ was just cute branding, and a tip of the hat to its Unix underpinnings, but that usage, combined with the 10.x version numbering thing, seems to have lead a lot of folks to think that all twenty years of the modern Mac OS are just one big major version… and that Big Sur (“11.0”) represents some revolutionary next step beyond it. Nope.)

LikeLiked by 1 person
- 20
  
  hoakley on July 10, 2020 at 10:39 pm
  
  Thank you.
  Although it’s a long time ago, Mac OS X 10.0 was so different that hardly anything built for 9.x could so easily ported, I think. So moving from 9.x to 10.x wasn’t the same issue.
  Where 11.0 is a big step is its Apple Silicon support. Although Apple didn’t increment the major version number when moving to Intel, it perhaps should have done so.
  Howard.
  
  LikeLike
21

Allan Odgaard on July 12, 2020 at 1:45 pm

I would suggest revising the “quick fix” proposed in this article: Either use isOperatingSystemAtLeastVersion: from NSProcessInfo (since 10.10), or, if you need to support versions earlier than that, write out a proper check.

People who have been ignoring the major version, and whose code is now breaking, should take the opportunity to do a proper fix, not a “quick fix” that will last until Apple decides to call it macOS 12.0.

LikeLiked by 1 person
- 22
  
  hoakley on July 12, 2020 at 10:32 pm
  
  Thank you.
  It would also be helpful if Apple were to make clear whether it is now intending to change major version numbers more in the future, i.e. that the next version after 11 will be 12, rather than 11.1. I suspect that will become obvious with the first update to Big Sur.
  When each major release of macOS requires custom code, using a single integer for the version number is much simpler and more efficient, and calls such as isOperatingSystemAtLeastVersion aren’t generally helpful.
  Howard.
  
  LikeLike
23

Jonathan on July 15, 2020 at 9:35 pm

I’m an Applescript user. I don’t know if this helps “real” developers, but what I’ve always done in my Applescripts is:

set osver to system version of (system info)
considering numeric strings
if osver < "10.13" then
–do stuff
else if osver 10.9. I’m expecting it to work fine with osver = “11”.

Does Apple not have something like this in their other languages?

LikeLike
- 24
  
  hoakley on July 15, 2020 at 10:54 pm
  
  Thank you.
  String comparison in other languages is a tad complex, and the individual components are accessed as integers anyway. AppleScript has many neat features like this.
  Howard.
  
  LikeLike
- 25
  
  AppleScriptUser on July 23, 2020 at 1:18 am
  
  When running it on Intel Big Sur, do you know if AppleScript’s (system info) returns “11.0” or “10.16”?
  
  Either way, your script will work, but for my use case I’d like to know specifically which value it returns. (Also trying to anticipate if 11.1 will return that or 10.17, etc.)
  
  Thanks!
  
  LikeLiked by 1 person
  - 26
    
    hoakley on July 23, 2020 at 5:43 am
    
    As to whether Apple will now use the minor version number for minor updates to 11.0, then change the major version number for Big Sur’s successor, that is widely speculated. But I haven’t seen any confirmation of that from Apple.
    We may have to wait for 11.1 or 11.0.1 to see which it uses.
    Howard.
    
    LikeLike
  - 27
    
    hoakley on July 23, 2020 at 5:45 am
    
    I wouldn’t expect Big Sur’s successor to also identify as 10.17, though. We’ll all have had a year to update our software to work properly with changes in major version number. I think it’s worth doing that sooner rather than later.
    Howard.
    
    LikeLike
28

AppleScriptUser on July 23, 2020 at 12:29 am

Does anyone know if Big Sur on Intel will identify itself as 11.0 specifically with the “system info” AppleScript command? Thank you!

LikeLiked by 1 person
- 29
  
  hoakley on July 23, 2020 at 5:40 am
  
  Just tested: on a freshly compiled script, it returns 11.0, which is what I would have expected.
  I haven’t looked to see if an existing AppleScript app, built under a previous version of macOS, returns 11.0 or 10.16. If AppleScript is consistent with the SDK, such an older app should return 10.16. I’ll check that when I get a chance.
  Howard.
  
  LikeLike
  - 30
    
    AppleScriptUser on July 24, 2020 at 9:30 am
    
    Wow, seriously can’t thank you enough! I really appreciate your help. Great to know. Thanks also for checking the behavior when it’s compiled on a previous version—since I am compiling on Catalina and anticipating my end users using Big Sur, that’d also be really helpful.
    
    Personally, I’d have to guess that, even then, it’ll still return 11.0? But maybe the (system info) AppleScript command is smarter than I think. Hoping it still returns 11.0 for simplicity.
    
    LikeLiked by 1 person
    - 31
      
      hoakley on July 24, 2020 at 6:01 pm
      
      I can confirm that:
      – an AppleScript app built in 10.15 reports that Big Sur is 10.16
      – an AppleScript app built in 11.0 reports that Big Sur is 11.0
      – running a .scpt script of course always returns that Big Sur is 11.0, as it’s recompiled on 11.0.
      I hope that answers your questions.
      Howard.
      
      LikeLike
  - 32
    
    AppleScriptUser on July 24, 2020 at 8:40 pm
    
    Got it! Thank you so much again!!
    
    LikeLiked by 1 person
33

samiamsamiam on August 8, 2020 at 3:29 am

“In the longer term, it would be much simpler if Apple were to provide a monotonically increasing positive integer which increased by 1 with every patch number.”

It’s called NSAppKitVersion, and it’s actually a double. It’s been around since 2001. Just compare to the constant for the release you’re interested in.

“So a typical code fragment in Swift might be…”

Oh dear, I hope not! For as long as OperatingSystemVersion has existed, we’ve also had isOperatingSystemAtLeast(). There’s no reason to ever have ignored 2/3 of this structure and done a manual comparison on just the middle field.

LikeLiked by 1 person
- 34
  
  hoakley on August 8, 2020 at 6:32 am
  
  Thank you.
  Unfortunately, isOperatingSystemAtLeast() is a very clumsy tool for finding exactly which version you’re on, which several of my apps like SilentKnight have to do. And NSAppKitVersion tells you the version of AppKit, which isn’t what I need for control flow.
  Howard.
  
  LikeLike