hoakley July 2, 2020 Macs, Technology

What’s in a number: how Big Sur could break code

Much that we do in scripts, tools and apps has to take into account the many changes that have happened in macOS. We normally manage these with conditional statements, in pseudo-code
if (macOS.minorVersion = 15) then …
These make assumptions about how Apple numbers versions of macOS, and could be about to break with the release of macOS 11 Big Sur.

Look at any of the images showing Big Sur running in WWDC, and you’ll see that it’s officially branded as macOS 11. If rumours are true, this seems to have been a fairly late decision, and for much of its development it has been known instead as macOS 10.16. Indeed, it seems that this first beta-release, while proclaiming itself as macOS 11, actually calls itself 10.16 internally.

Numbering versions of macOS follows a standard set of rules. The version consists of three distinct integer components:

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 much. In recent Mac OS X, though, there’s been a new version each year, such as Catalina 10.15 and Mojave 10.14. It’s this version which is most commonly used when deciding which features are available.
The third is the patch number. In recent macOS, this has risen to x.x.6 at the end of each release cycle. Although some features depend on patch numbers, that’s less common.

According to that, Big Sur is either 10.16.0 or 11.0.0, depending on where you look. If your conditional code has only been checking for minor version numbers, then it would see Catalina as 15, but Big Sur could be either 16 or 0 depending on how Apple numbers it. If the major version has indeed incremented for the first time in the last 20 years or so, and Big Sur turns out to be 11.0.0, then anything which assumes that this minor version number will be greater than 15 will break. If the major version number hasn’t incremented, then the minor version number will be 16, as at present.

I’m a great believer in covering all outcomes whenever possible. In my code, where I need to test for Big Sur, I now use code like
if (macOS.minorVersion > 15) or (macOS.minorVersion < 10) then …
which is good for code which can’t or won’t run on anything before Yosemite.

No matter what Apple may eventually settle on, I shouldn’t have to change that again for many years. If your code reads
if (macOS.minorVersion > 15) then …
it will break if Apple settles on Big Sur as being 11.0.0. If it instead reads
if (macOS.majorVersion = 11) then …
it won’t work on the current beta, but might work if Apple changes the version numbering.

12Comments

Add yours

1

Iljitsch van Beijnum on July 2, 2020 at 9:34 am

if (macOS.minorVersion > 15) or (macOS.minorVersion = 14) or major >= 11) then …

Or probably more robust:

if ((major * 100 + minor) >= 1014) then …

This is all terrible stuff because such conditions will very likely go untested and then bad things happen with newer versions at some later time if there was a mistake formulating the condition. Also see the web where useragent strings are completely out of control.

Wouldn’t it be better to specifically test for capabilities that are required rather than test for version numbers?

IMO this also shows the major/minor version number thing is just a bad idea. Just use a non-user-visible strictly increasing single number (and certainly not a string). Also avoids problems going from Windows 2000 to Windows 10 or having to skip 9 because it looks too much like 95.

LikeLiked by 1 person
- 2
  
  hoakley on July 2, 2020 at 9:07 pm
  
  Thank you.
  The best way of handling this varies greatly. Some languages may not have ready access to the version numbers as integers, or this may be embedded in a case statement which you don’t want to completely rewrite. That’s up to the coder – what’s important I think is that we’re not lulled into a sense of false security by what currently appears to be 10.16. It may remain that, but if it does change to 11.0, it’s much better to have anticipated than to have procrastinated.
  Howard.
  
  LikeLike
- 3
  
  hoakley on July 2, 2020 at 9:10 pm
  
  Oh – and it’s worth pointing that Apple’s numbering has worked very well for many years. It’s only really with OS X that the minor version number has become all-important. In Classic days, it was the major version number which was the more important much of the time. So although this now appears less than ideal, it’s the first time that this scheme has had a problem AFAIK.
  Howard.
  
  LikeLike
4

Pico on July 2, 2020 at 4:51 pm

Version numbers cannot actually be reliably compared in this “* 100” way. One current example would be that 11.0 = 110 and 10.15 = 1015, when comparing versions like this, 10.15 would be higher.

I’ve used NSAppKitVersionNumber for this kind of thing in the past: https://stackoverflow.com/questions/31958010/how-to-check-mac-os-x-version-at-runtime

The whole number of NSAppKitVersionNumber is always increasing and will not suffer from marketing version numbering changes like 10.16 vs 11.0.

That Stack Overflow link also shows options for using #available is Swift or @available in Obj-C. But not sure how Apple is gonna handle “#available(macOS 10.16, *)” vs “#available(macOS 11.0, *)”. If I had to guess, I think they will have some internal catch to accommodate both options for this case, but who knows.

Looks like you could also just compare version strings in Swift: https://stackoverflow.com/questions/27932408/compare-two-version-strings-in-swift

When using version string comparison, >= 10.16 will be reliable as it is for both 10.16 and 11.0 options.

LikeLiked by 1 person
5

Iljitsch van Beijnum on July 2, 2020 at 5:35 pm

major * 100 + minor will work for major >= 0 and minor between 0 and 99. 11.0 would be 11 * 100 + 0 = 1100.

String will NOT work because “10.15” 95.

LikeLiked by 1 person
- 6
  
  Pico on July 2, 2020 at 7:27 pm
  
  You’re right about the “* 100” method, my bad. Clearly wasn’t thinking clearly about that before. Was probably thinking about how version numbers can’t work like decimals.
  
  But, “version string” comparisons can work just fine because there are special comparison methods that know how to handle version strings.
  
  Regardless, I think Howard now has a variety of options to consider on top of the already working code he has in place 🙂
  
  LikeLiked by 1 person
  - 7
    
    hoakley on July 2, 2020 at 9:12 pm
    
    As you’ll see tomorrow, I’ve moved on to even greater things, I hope.
    Howard.
    
    LikeLike
8

Iljitsch van Beijnum on July 2, 2020 at 5:36 pm

I don’t know what’s going on here, but only half my text is making it through in my latest and earlier post. Maybe an issue with smaller than?

LikeLiked by 1 person
- 9
  
  hoakley on July 2, 2020 at 9:11 pm
  
  That’s because you’re not using the escape chars for ‘lesser than’ < or ‘greater than’ > – which have rather different uses in HTML, of course. WordPress does find them confusing, unfortunately.
  Howard.
  
  LikeLike
10

Iljitsch van Beijnum on July 3, 2020 at 9:35 am

So I have to write my comments in HTML?

Apparently Apple has found a solution: older apps see 10.16, ones built with the new Xcode 11.0…

LikeLiked by 1 person
- 11
  
  hoakley on July 3, 2020 at 11:14 am
  
  Thank you.
  No, I didn’t say that you had to write your comments in HTML. WordPress recognises certain markup characters in comments and blog content, among them < and > as they indicate HTML markup. This allows the writer to embed those markup characters. If you put the < symbol in a comment (or a blog article), then WordPress thinks you are embedding markup. So when you want to use that character, the safe way is to use its HTML escape character, in that case ampersand-l-t-semicolon. That’s not my decision – it’s a feature of WordPress.
  I think you’re right on the differences between SDKs. That’s fine (well, it’s not actually) if you’re using Xcode. But a great many people write scripts and other code which don’t use Xcode, and that’s bound to create problems for all. I will look at this in more detail elsewhere.
  Howard.
  
  LikeLike
12

Xsan Upgrade and Big Sur Prep. Hello Catalina! | DAM SAN on August 8, 2020 at 12:45 am

[…] Until now that meant macOS 10.14 (Mojave). With the imminent release of macOS Big Sur (is it 10.16 or macOS 11?) then it’s time to move from 10.14.6 Mojave to 10.15.6 Catalina. It must be safe now, […]

LikeLike

·Comments are closed.

Share this:

Related