Big Sur is both 10.16 and 11.0 | Hacker News Reader

Big Sur is both 10.16 and 11.0

eclecticlight.co

221 pointsmiles204 comments

I don't understand why -- and do educate me on why I'm wrong -- software don't just use an internal and external version number. Version numbers may have started as a technical label with precise meanings, but they've been a part of branding and marketing for a while now. It's futile to fight it[0].

Let the former be a monotonically increasing (say 64-bt) integer, and the latter be a free-form string. This way, marketing folks are free to call one version "macOS 10.16 Big Sur", followed by "macOS 11.0 Big Sur Pro Max", "macOS 10.32 Pro SE", etc. w/o developers pondering over whether "Pro SE" > "Pro Max". As for API, maybe something like getProductVersion() for the internal version, and getProductName() for the external version. Heck, be facetious and let the latter return a string like "!!! DO NOT USE FOR VERSION COMPARISON USE getProductVersion() INSTEAD !!!\07\07\07macOS 10.16 Big Sur".

Yes, lazy developers will get it wrong, similar to how they use gettimeofday()[1] instead of clock_gettime(CLOCK_MONOTONIC, ...)[2]. In their defense, often software switch between versioning conventions such that what's the "right" thing to do is unclear.

[0] Such appropriation is everywhere. Don't get me started on how Porsche Taycan, an electric car, has a "Turbo" model. It probably doesn't even come with blinker fluid standard.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...

[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...

I think that a lot of projects already do this. In particular windows : Windows 95, 98, 2000, XP, Vista, 7,8,9,10 are all external version numbers.

Additionally, they have all of GP's suggested functions.

What’s win 9? I thought 9 was the internal version of 10.

Some software used to check that the version name string started with "Windows 9" to determine if it was running on a "Windows 98" or "Windows 95" system as opposed to 3.x, NT, XP, etc. Yes, there are internal major and minor version numbers available, however that didn't stop people. Ergo, jumping straight to "Windows 10" which would cause software that did this to find "Windows 1" in the string triggering a message like "This program requires at least Windows 95..." or whatever instead of immediately crashing because it made a system call to an API that hasn't existed for 10 years. Or worse, silently corrupting data because of other OS API changes.

Windows doesn't provide API to get OS product name IIRC but Java provides "os.name" property that returns like "Windows 95". That's bad api to check version but some Java apps use it.

https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/7b9323b1...

That's probably what I was remembering.

AFAIK it was Windows 8.2. I came across some early SDK that used both "Threshold" (Win10 codename) and Windows 8.2

This is somewhat true, but Windows is a perfect example of this not working. There was no Windows 9, because of fear of people using the Windows string name to detect Windows 95/98 (or at least that is the prominent theory).

Ah, that makes sense.

I thought it was because they wanted to go to 10, like Mac OS X. Same as the Xbox 360 was called that because they didn’t want to bring out the Xbox 2 when Sony was bringing out the PS3.

That doesn’t explain the naming of Xbox One though.

That name was chosen for the console’s original (if largely abandoned) vision of being a single hub for gaming, live TV, and streaming: https://www.vg247.com/2013/05/28/xbox-one-microsoft-exec-exp...

It also ties in with Microsoft's "One" line of names: OneDrive, OneNote, OneCore etc

I also thought it was because of TenVer! "Windows 9x" makes more sense.

https://github.com/cube-drone/tenver

Like Spinal Tap, now it's time that this one goes to 11.

Yes, Microsoft skips windows 9 because some code use "Windows 9" for windows 95/98:

https://www.reddit.com/r/technology/comments/2hwlrk/new_wind...

When safari 2.0.4 was first released huge numbers of websites broke simply because they detected Netscape 4 by doing navigator.useragent.indexif(“4”)>0

Never underestimate the ability of developer hacks to screw things for years.

Many releases after had a lot of paranoia about including the character 4 in the version number

This is also why the Windows 10 May 2020 update is v2004 instead of v2003 to avoid issues with old software thinking it is running on Windows Server 2003. [1]

[1] https://www.theregister.com/2019/11/27/windows_10_2004/

My manager at work came across this version number on a document properties screen (possibly in Word?), thinking it referred to the version of software the document was written in. We bullshitted a bit about how we're still iterating on 16-yo documents, until I googled and found that it was a new MS version.

(I often find that a document I am editing at work was created by "Valued Gateway 2000 Customer")

You got the answer right. Software typically does work this way but then people inevitably make the mistake of using the wrong version and then hacks are needed to not break those apps.

While I generally agree with your comment, I also find it ironic that one of the POSIX APIs you chose to use as an example of API misusage (clock_gettime) is ... not available on macOS.

It's been added since macOS 10.12 (Sierra). According to my man page. Couldn't find any authoritative sources online on that, though. However, there are several secondary references[0][1].

[0] https://github.com/zeromq/libzmq/issues/2175

[1] https://github.com/rust-lang/libc/issues/776

It was added in Libc-1158.1.2, which shipped with Sierra: https://github.com/apple-open-source-mirror/Libc/blame/maste...

macOS/iOS have this concept already:

CFBundleVersion: The version of the build that identifies an iteration of the bundle. This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods.

https://developer.apple.com/documentation/bundleresources/in...

CFBundleShortVersionString: The release or version number of the bundle. This key is a user-visible string for the version of the bundle. The required format is three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods.

https://developer.apple.com/documentation/bundleresources/in...

Android similarly has versionName and versionCode.

The problem is that no matter what, someone somewhere is going to parse something that was never intended for non-human consumption. Or code ends up making assumptions that it shouldn't about a machine-readable version.

I have code which parses CFBundleVersion. It assumes the version follows Apple's docs. But guess what? CFBundleVersion is just a string and nothing enforces Apple's guidance so I was surprised (I shouldn't have been) to have to deal with an internally distributed iOS app that had the word "debug" tacked on to the end of its CFBundleVersion.

Small side note:

Android's "versionCode" is an ever-increasing number, you must submit a higher versionCode than your previous build.

CFBundleVersion can be set back to 0 with each CFBundleShortVersionString change.

Normally I just set both to a build number on whatever CI I use (for something like a cordova cross-platform app) and then increase CFBundleShortVersionString & versionName using the tag name (or a custom version name I give a release).

CFBundleShortVersionString must increment too though. So if you join “${CFBundleShortVersionString}.${CFBundleVersion}” the whole thing must increment, and this explains why CFBundleVersion can revert when CFBundleShortVersionString increments.

Thanks for the references. I think Android's versionName / versionCode are closest to what I have in mind. The problem IMHO with CFBundleVersion, CFBundleShortVersionString, et al. is that they need to be parsed before making comparisons, and this is where developers make mistakes or take shortcuts. Whereas with plain integers, direct comparisons are simple and usually correct as well. Take the story in question: I can imagine being lazy and skip over the major version part of the version string. But with integers, I wouldn't go out of the way to mask out the MSBs, no?

Guess what happens with something as simple as versionCode?

Hacks like this, to allow a single "version" of an app to have multiple APKs, but wait, versionCode has to be unique. I know, we'll do this:

> In the following example, the APK for the x86 ABI would get a versionCode of 2004 and the x86_64 ABI would get 3004. Assigning version codes in large increments, such as 1000, allows you to later assign unique version codes if you need to update your app. For example, if defaultConfig.versionCode iterates to 5 in a subsequent update, Gradle would assign a versionCode of 2005 to the x86 APK and 3005 to the x86_64 APK.

https://developer.android.com/studio/build/configure-apk-spl...

Sigh. Nothing is ever easy. We make assumptions when we design our systems without realizing it and then paint ourselves into these silly corners to not break things.

Just got flashbacks of basic programming line numbering.

and then there's <number><letter><number>

About this mac -> click on the version number text and it will appear.

The format is really [major version][train][audience]?[build number][mastering version]?, where major version is numbers, train is a capital letter, audience is a digit, build number is numbers, and mastering version is a lowercase letter (and things with question marks are optional, and of course Apple does its own thing from time to time). So the current beta for Big Sur, which is 20A4300b, has

20: Major version (happens to match the XNU kernel version)

A: Train (First “point” release, although that is not how marketing does it)

4: Audience (Developer seed)

300: Build number (300 builds since the train started)

b: Mastering version (forked from mainline two builds ago for polishing)

At a previous company, for a very complicated web app with some offline caching aspects, we used the latest git commit hash of each build as a public-facing unique version id in the help menu. This made it dead simple to use proper semver versioning internally without needing to correct user expectations about version numbers, while still having easily tracked unique IDs in bug reports.

I think Apple's "marketing folks" already do a reasonable job of this with macos - most non-dev people and most (all?) of Apple's consumer facing marketing refer to the OS as "Catalina" or "High Sierra" or "Big Sur". Outside of the sort of people who visit HN, I wonder how many Mac users could tell you what the version number "High Sierra" was?

The problem with this is most tech people and mere mortals alike can’t keep the sequence straight. I gave up on trying to even map names to versions and just go to “about” every week or three and provide whichever detail is most useful.

Marketing has ruined version numbers with their nonsense. Take it away from them.

That's what Windows has. The internal version is the build number:

Windows 3.1 - Build 103

Windows 95 - Build 950

Windows NT - Build 1381

Windows 98 - Build 2222A

Windows 2000 - Build 2195

Windows XP - Build 2600

Windows Vista - Build 6002

Windows 7 - Build 7601

Windows 8 - Build 9200

Windows 10 (1909) - Build 18363

Windows 10 (2004) - Build 19041

Source: https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...

macOS used the build number this way too.

Yet Windows plays the same game of pretending to be an older version to older software.

That's because developers have written and still write incorrect software that relies on the external version number. It's also the reason Windows lies about its build number unless you add magic (read: not deterministic) GUIDs to your apps' manifest. Raymond Chen's blog[0] has tons of stories about this kind of bugs.

[0]: https://devblogs.microsoft.com/oldnewthing/

It is how you want it to be. The marketing name is Big Sur. The version is 11.0.0.

There is meaning to the separate numbers in the version, there’s a guarantee they aren’t going to remove api if the third number increases but they might if the second one increases. The first one only increases with truly big changes such as this move to ARM.

Using an integer doesn’t work because point releases where the third number increases are not monotonous, 10.15.20 might be released while 11.0.0 is already out. Apple does maintain the previous release with security updates while there already is a newer current release.

Note that Windows is a big mess with Windows 10 build 2004 (because they want to avoid confusion with Server 2003) which is version 19041.329, or perhaps 10.0.19041.329. It’s almost the same scheme but with large numbers you can’t remember and are hard to find in the documentation.

A couple of decades back, our product was always internally <codename>.<buildnumber>, where parallel codenames would exist when multiple versions were supported or in development (think "1.x" and "2.x").

What was displayed to the user was hex-edited into the CD image after it passed QA, according to the whims of marketing, and we treated it as pure text.

Note that this is how Windows has worked since 2013.

If you ask what version of Windows you are running, for example with GetVersionEx, Windows will report Windows 8.0. This is true unless your application marks compatibility with a newer version in its manifest, at which point Windows will report whatever the newest version in your manifest is, or whatever version Windows actually is, whichever of the two is older.

It's kind of annoying from an analytics perspective, because you need to upgrade the manifest (and thus the compatibility) to find out how widely adopted a version is, so you can find out if how much effort it's worth putting into validating it as a platform.

True that this is annoying, but there is a solution. https://stackoverflow.com/a/25986612/82294

Now we just have to wait until that method gets abused enough by devs and microsoft ends up spoofing that too.

There's an ultimate future-proof solution, though: just generate, in a loop, a series of assemblies that each purport compatibility with Windows ABI vX.Y.Z; spawn those in a separate process; and get them to return what version of Windows they perceive. Once the number stops going up, that's the version you're on.

No real way to get around that without misinforming fresh, valid applications.

> just generate, in a loop, a series of assemblies that each purport compatibility with Windows ABI vX.Y.Z

The Microsoft developers already thought of that trick. What you declare is not compatibility with "Windows ABI vX.Y.Z"; you declare compatibility with an UUID which represents that Windows version. That is, if you're compatible with Windows 8 you say "I'm compatible with 4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38", if you're compatible with Windows 8.1 you say "I'm compatible with 1f676c76-80e1-4239-95bb-83d0f6d0da78", and so on. Since you cannot predict the UUID for future Windows versions, you cannot pretend to be compatible with them.

> Since you cannot predict the UUID for future Windows versions, you cannot pretend to be compatible with them.

Until a clueless product manager tells you to just iterate through all possible UUIDs to check :)

If I had a dollar every time I had to explain this to a PM or a CISO (!!)...

Is there any API you can go through to get the UUID of the current ABI, all the ones seen by the system, or all of the ones for each windows ABI without network access?

Trivially, you grab the UUIDs from a server somewhere. A smarter trick is to get these UUIDs from the system you're running on.

There used to be some configurations that had kernelbase.dll but not kernel32. (Windows phone used to be like that, maybe windows on arm?) I would consider checking for ntdll instead of kernel32. (Or kernelbase if kernel32 gets file not found.)

> so you can find out if how much effort it's worth putting into validating it as a platform.

I don't understand the logic here. We're talking about the new version of your target OS. You will presumably always need to support it eventually.

IMO if you're large enough to have a testing and validation process at all, you should be including at least the public beta builds in those tests.. By the time it hits RTM if you don't at least know if your software works you're doing it wrong.

Also, if your software is regularly breaking with OS releases and you're not doing something that requires you to be deep in the internals, you're almost certainly doing something significantly wrong and should figure out what that is. The only software I consistently experience breakage with on updates is also the one where their tech support insists that we're being paranoid for refusing to give their users local admin privileges just to run it. I don't think for a second that's a coincidence.

It’s nice to be able to choose schedules and prioritize work based on metrics. There’s also the fact that you could e.g. drop support for Windows 8.0 if you find out that only 0.1% of your users were using it.

> I don't understand the logic here. We're talking about the new version of your target OS. You will presumably always need to support it eventually.

Maybe not, you might be able to skip a version that had poor adoption. Windows ME, Windows Vista, IE7 and TLS 1.1 never had a very high market share, because people put off updating so long that better things came along.

Usually the backwards compatibility is good enough, that updating to declare support for it has almost no positive gain.

(Even more so where updating to explicitly support the new version means dropping old versions.)

Can’t you use build number for Windows?

This one hit met pretty good a while ago. I had to know if we are running on Windows 8 or Windows 10 and it turned out to be very difficult finding that out.

The User-Agent string for Big Sur's Safari running on Apple Silicon (ARM) still says "Mac OS X 10_16" and, curiously, claims to be "Intel":

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"

User agents have been garbage for decades. Keeping Safari’s one like it is is probably a good idea, who knows which websites could break if changed.

Not sure why you're being downvoted, but this is exactly the reason. Chrome on Windows includes "Safari" in the user agent and Chrome on Android includes "Mobile Safari" because if they don't add it, tons of websites will break.

Everyone does this, which is kinda why we need to get rid of user agents and replace it with feature detection (and css that works everywhere for people who don't want to run Javascript).

Browsers have bugs so it's not really possible to do that and maintain a reliable web.

Bugs should be fixed by who produces the browser and not by the website administrator by looking at the user agent and using workarounds.

When someone asks me to build I site for them I say, look I will guarantee that the site that I make is compliant with the W3C specification. If there is something that it doesn't work because some browser don't implement the standard correctly, you go to Microsoft to complain, or you install a decent browser like Firefox.

I admire your idealism, but here on planet Earth engineers are paid to make things work.

Lol, I don’t know who your clientele are but producing websites that don’t work on popular browsers “because the browser is not following spec” is a non-starter. A bank wants a banking website its customers can use, not a website 60% of its customers can use and a link to a 7 year old bug report.

Disagree. You can't just tell your customers "my product doesn't work because of Microsoft, go complain to them; even though it's possible for me to work around it, I'm choosing not to".

Have you tried?

> Bugs should be fixed by who produces the browser and not by the website administrator by looking at the user agent and using workarounds.

IE 6 had such a history where it held back other browsers and developers were held hostage to it for several years. Now we have Chrome to fill that gap and some Google platforms won’t work well or work the same on Firefox.

Then part of feature detection could be detecting bugs and working around them. This wouldn't have to be done by every web developer, but bundled into a commonly used library so cruft can be taken out when browsers fix bugs.

How would that library be any better than using user agent strings? I think it would likely be worse.

If a browser updates with a new feature that Chrome already has and other sites already use, the users get to use the new feature with no update from the developers due to feature detection.

I don't disagree with you on feature detection, but there is no feasible way to encode all browser bugs that require workarounds into a library. By nature, these are usually extremely niche.

Javascript feature detection is much too late when you need to send headers with the HTML and browser vendors can't agree on the header values or change their mind on what things mean. Like the samesite cookie nonsense: https://www.chromium.org/updates/same-site/incompatible-clie...

Assuming things like that continue to happen, what are web developers supposed to do?

I propose a Real-Agent header that includes browser name and version, os name and version, cpu type (maybe) and desktop/mobile flag (maybe). Or separate headers for each name/version data, I don't care, I just know I need real data sometimes, and some new weird server request pattern isn't going to work well. Then continue to send shakespearean sonnets in user-agent for all I care.

This makes sense since it should avoid two issues:

- Sites that try to detect mobile by looking at "ARM" in user-agent string

- Sites that try to parse the macOS minor version for some reason and would be confused to see something like "11_0"

BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...

Also, whether a system is ARM or Intel could be used as another bit of entropy for fingerprinting.

You can probably get the same information by looking at the webgl fingerprint, since the iGPU inside the A12Z is different than the ones used in Intel macs.

It's more complex and requires to use JavaScript that you can block in the browser, while the user agent is always sent to the server on every request, and thus is much easier to fingerprint the user with that.

And doing this encourages websites that actually need to detect this platform properly to introduce the next generation of horrible things.

Browsers will almost certainly begin to phase out user agent strings anyway: https://www.zdnet.com/article/google-to-phase-out-user-agent... .

In the vast majority of use cases, these values should not be used to detect platform features - actual feature detection should be used instead.

They should just make a gentleman's agreement that the four majors will change it to name and version without any of the cruft. Every broken site will be quickly shamed into fixing their shit.

“Every broken site” will be internal enterprise web-applications that haven’t been touched in 15 years where they’ve also lost the source code.

They can slap a proxy on the front to change it back to what they need.

That sounds like work. Which costs money.

They can just not update their browser - which is essentially doing "no work", and is free.

The replacement they're going with, "client hints", is weird in its own way. Suppose you render your website server-side, and suppose you use different templates for desktop and mobile. You then have to determine the kind you want before any response is sent, but the new method prevents you from doing that; you have to send a response to ask the browser to send the mobile flag in a subsequent request. You'd have to use ugly workarounds for that. One that comes to mind is to issue a redirect to the requested URL itself, but ask for the additional headers. Not optimal because it adds a round-trip and I'm not sure it'll work at all. User agent strings aren't pretty but they make this kind of detection extremely easy and straightforward.

And "actual feature detection" doesn't work with SSR, like, at all.

A good observation, but why do you need to serve a mobile and a desktop version of your site in the first place? You can with modern HTML and CSS make a website that works perfectly on mobile and desktop, without having to serve a different version for the different platform.

It doesn't make sense to make the choice of what to render on the user agent: for example if it says Android, what does it mean? It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!

An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile, since it usually work one way and thus if you share on a chat the link to the mobile version of the site and the other one opens it on a desktop there is no easy way to get back to the desktop site (most of the times I have to modify the URL!)

I might be a minority, but I don't like modern adaptive websites. They try really hard to work on both touch and non-touch devices with the same underlying markup, and more often than not end up being terrible on both. You end up with these giant, touch-friendly buttons on desktops. Making all your paddings and layouts and font sizes dynamically adapt to the interaction paradigm is hard and almost no one's doing it. Then there are some interactions that are only possible on desktops — like hovering things to reveal menus or tooltips; these websites rarely make use of the unique properties of the mouse. Or sometimes they do but then you happened to open it on your phone and you have to tap and hold the thing to trigger the hover. And so on.

> It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!

That's what the "request desktop website" setting is for.

> An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile

Yes, I wholeheartedly agree with you on this one.

Either the sites you’re visiting are doing it wrong, or you’re expecting a density of pixels that never worked well for most mouse users already.

I'm using either a 27" 1440p monitor or the built-in screen of my 15" macbook. Either way, modern web makes fonts and UI elements a tad bigger than they have to be, and there's usually too much area wasted on whitespace between them.

Desktop UIs are meant to be compact because mice and trackpads allow nearly pixel-level positioning. Mobile UIs, on the other hand, have to have large elements and ample spacing between them because tapping stuff with your fingers is inherently imprecise. You can't really have both these things at the same time.

Out of websites that are currently live and have good desktop versions, I'd point out HN and reddit (the old design).

And then there's Facebook who has separate mobile and desktop websites but recently chose to redesign its desktop one to look very mobile... I can't imagine the justification behind this one.

You're certainly welcome to prefer more compact UIs on your very large screens, but it's only that: a preference. There are many reasons why other people either prefer or need (i.e. accessibility, touch) larger text and UI elements to be able to use these websites.

I personally prefer (and may well someday need) larger text and UI elements, because my vision and motor skills have gradually declined. I also prefer (and soft-need) lower information density because higher density is a cognitive challenge (ADHD).

> An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile, since it usually work one way and thus if you share on a chat the link to the mobile version of the site and the other one opens it on a desktop there is no easy way to get back to the desktop site (most of the times I have to modify the URL!)

Absolutetly this - the number of people sharing m. links for Wikipedia when is just annoying. And there is absolutely no excuse for having different HTML for today's smartphones and Desktops. For text sites like Wikipedia you shouldn't even need media queries or any fancy stuff - just avoid fixed (minimum) widths and use <meta name="viewport" content="width=device-width, initial-scale=1"> to tell broken-by-design mobile browsers that your website is not broken and can be rendered normally instead of in a giant viewport.

It is true that trying to make a website Javascript and CSS free is becoming a very limited proposition. The problem with pure HTML sites using SSR is that they have to assume the user-agent defines some sort of contract around features when absolutely none has ever existed. And browsers have to assume SSR sites will update behavior correctly when the user agent string changes, which also has seldom been the case. This is why all user agents still include Navigator, Gecko, KTML, WebKit, etc in their strings for regex to chew on.

The latest iPadOS, for example, purposely reports itself as a Mac desktop because too many sites saw 'MobileSafari' and returned a sub-par site experience based on a small mobile phone screen. But it actually goes beyond that:

1. It lets the user toggle the user agent themselves between mobile and desktop (iPhone and Mac Desktop style agents)

2. The browser will by default use a mobile user agent when rendering in a small form, such as a browser in a smaller modal window or a side-bar.

Client hints might provide a way to actually formalize a contract for SSR apps, if people participate and indicate what they need.

Good thing there won't be any more browser/version specific bugs to work around!

If there is a constant in the universe it's that developers will always be trying to detect X by querying for Y and then have their code break when those assumptions become wrong.

Oh my god can we please kill the user agent string already? Every time any new combination of browser/os/platform is created it claims that it's as some other user agent from an established browser because sites are lazy and abuse user agent string to determine capability. Meaning they have long lost all meaning and we should just dump them.

Right? I mean we can’t kill it because everything currently exists would die.

But the many attempts to freeze the existing UA are for the purpose of stopping people testing through the UA

> Oh my god can we please kill the user agent string already?

Browser makers tried to do that by providing feature detection, but the weight of legacy code and developers already used to using the user agent strings has made killing it impossible.

Edit: As pointed out in another comment here, it seems like Google is killing it (or planning to). [1]

[1]: https://www.zdnet.com/article/google-to-phase-out-user-agent...

It is hell, but it is only way to workaround the hell tons of safari graphic bug.

Because it only affect graphic, you can't really detect whether you are affected by it or not from js.

The best thing you can do it guess the browser from user-agent and apply the workaround anyway. Or you can pray for the apple to fix their sh*t (given what they have done in the past, it is unlikely).

I’m curious what is this graphic bug?

Something like the safari failed to draw some elements suddenly. JS reported it is there. Query the size with js do work. Select it with devtool works. The only thing not work is... the element is invisible. Hide and show the element again makes it show correctly. But how do I know whether it is bugged now without guest the browser from user-agent?

> BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...

This is why we have some more developers spending time on creating FOSS libraries that parse user agent strings and tell you exactly what the browser claims to be, with attributes like browser name, OS, version, browser engine, etc. All these libraries need updates (or at least a cursory look) whenever a new browser version is released so that they can continue identifying browsers correctly. All those people, bless them for this work, could be doing something else in an alternate universe.

Notwithstanding feature detection and graceful downgrades, browser user agent strings seem to be very commonly used to decide the behavior of many websites.

This is because iPadOS also claims to be a Mac

Technically it and iOS are MacOS.

And all three are NextStep.

And Mach.

iOS≠macOS≠NeXTSTEP, but all three run Mach kernels.

iPadOS Safari does the same:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15"

Notice it also identifies as "Mozilla", because User-Agent strings are more about not breaking shit than actually reporting what's going on.

This was originally done by IE way back in the day, for a variety of reasons - one being to not block IE. So, they just masqueraded the IE browser as Netscape. It's been a mess every since.

Yeah, it's one of those pernicious things that highlights that a powerful player like Microsoft can essentially lie or disregard standards for their own benefit and thus cheapen the entire purpose of the rule.

Always good for a laugh: https://webaim.org/blog/user-agent-string-history/

I don't know whether to laugh, or to instead be triggered by the traumatic memories which were buried deep within the recesses of my mind until now and assume the fetal position.

> The User-Agent string

Allow me stop you there. The User-Agent string is semantically meaningless.

UA strings are NOTORIOUS liars, see the rest of the UA strings you quoted

Got to admit - that's a simple yet clever solution.

Quite the opposite, it is a complex mess.

Yes. Caring about backwards compatibility is a whole universe of compromises.

There is speculation the reason Windows jumped from version Windows 8 to Windows 10 is that too many things were string matching (version ~= "Windows 9\d*")

or just .startsWith("Windows 9")

At some future point the frameworks that are getting the backwards-compat version number will be dropped, all those apps will cease to function on macOS 11.n+1, and it won’t matter any more. I think it’s a great solution.

I agree, this is not good. I manage Macs in MDM and I already saw that in some actions they show up as 11 and in others as 10.16. sw_vers tends to report 10.16 but UIviews tend to report 11.0. MDMs are complex machines and they don't always do every operation the same way.

Why is this bad? Well for one example, because sometimes you use version numbers not exactly. Consider the statement: "Applies to 11.0 and higher". Depending on how the OS identifies itself this will be valid or not. On the same OS.

Or consider reporting, if under some conditions the Mac identifies itself as 10.16 and in others as 11, you're going to have them in 2 different buckets even though they're the same thing.

Really, they should have made a choice, one or the other. If software wasn't compatible because of this it should just be updated. Apple never said it would always be 10.x.

I don't really understand why they're doing this as Apple normally has no issue telling developers to fix it or stuff it. They never cared about backwards compatibility before. If having 11.x was not that important to them to upset a lot of stuff, they should have just stuck with 10.16.

This is exactly how Windows has done it since 8.1, back in 2013. Apple’s strategy isn’t new or unusual.

If others do a bad thing too, doesn't make it right :)

The reason why both Microsoft and Apple are doing this is because there is too much software in the wild which will break if it detects a major version bump. So, that is why both are doing it, and that is why it is the right decision.

The right decision may still be a complex mess.

Exactly, and what I'm trying to point out is, is this really worth it when the only advantage of having the "11.0" is just marketing?

Yes. The alternative is how we have legacy things with no meaning 30 years down the line...

Marketable version numbers are quite useful. If somebody says they are running 10.12.3, the first thing I do is check which version I am running to see how that compares. On the other hand, if somebody says they are running iOS 12.1.2, I immediately know that is a patch of the preceding year's major version.

The reason is that Apple actually applies marketing to their iOS version numbers, but doesn't do the same for macOS, because incrementing the minor version isn't marketable. Their crack marketing team does come up with funny names for macOS releases, but few people remember the mapping between those and the actual version numbers.

Saying it's bad doesn't make it bad.

And it surely doesn't make it worse than the alternatives...

Wouldn't "10.16 and higher" work for both 10.16 and 11?

Yes it would. But there is no guarantee that every package vendor does it that way. And this is only one example I can think of. It will mess up reports as well. Data from Macs is used outside of the Mac itself as well. I'll add that to my post, I'm only just now thinking of the implications. So far I hadn't thought of this as I assumed it would be fixed before release.

In fact most Enterprise software for Mac (think Palo Alto GlobalProtect, Zscaler, antivirus packages) are horribly badly packaged and I expect many issues here.

PS: Good point from tobr below too.. These things are not as simple as they seem.

Well, they'll anyway need to "do" something about the new arm macs, so it'll probably not be an issue to fix version checks at the same time if broken...

Existing Intel software (with potentially broken version checks) will work on ARM Macs under emulation. Once they rebuild with the new SDK they'll get the receive the correct version.

What if next year is 12.0 and 10.17?

Your comment made my day :-D

I don’t think this is a plausible scenario. You might also ask, “What if next year Apple releases Mac OS 9.3?”

They should. And they should release a new version of Rhapsody. The Rhapsody community (and it is a community) would love that.

Don't get me excited now...

The more plausible scenario would be 11.1 and 10.17

The trick of checking version >= 10.16 to cover both 10.16 and 11.0 would not work then, as version >= 10.17 would cover 11.0 (10.16) too.

Then what..?

What MDM specifically? It would be up to the MDM version to be consistent with how they display and handle the SW version. Stuff like AutoPKG and Munki should be able to handle it just fine.

AutoPKG and Munki aren't MDMs.

I use both AirWatch (now VMWare Workspace ONE) and MS Intune (now Microsoft Endpoint Manager) right now.

The problem is that they incorporate different technologies. For example, Workspace ONE includes Munki for its app distribution but MS does a different thing. Also many run scripts in the background to check things, which may or may not do things differently.

I haven't really tested Big Sur much with the MDMs because there isn't much point until all our antivirus software etc is updated to support it. But I'm pretty sure this will cause additional issues, and Macs in enterprise are already very difficult. Mainly because of Apple's consumer focus, enterprise manageability is always second place unfortunately.

FYI it's still microsoft intune. Endpoint manager is the just portal for unifying sccm and intune.

Source: Microsoft Employee

I'm aware those aren't MDMs, however they still will have to deal with this. I was also under the impression that Intune didn't really support software management for macOS. I think Jamf and WS1 will be just fine. I think the Kernel extensions are going to be a much bigger problem for those of us managing Macs at scale with things such as Antivirus software like you said.

> They never cared about backwards compatibility before

This is not true. While they may not have the slavish devotion to backwards compatibility that Microsoft has, even Apple implements app-specific hacks to keep non-compliant software compatible with newer versions of macOS https://worthdoingbadly.com/appkitcompat/

Makes sense, 16 is 1 in Base 16, so 10.16 = 11.0 :)

So, there was A.F, then it incremented bu 0.1 to B.0. Checks out, except for their weird insistence to use a decimal representation for what is now obviously a hexadecimal scheme. ;)

Why did they even go with 11 instead of just dropping the 10, making Big Sur macOS 16?

Would've made a lot more sense to jump to MacOS 20, that makes a nice jump from 10 and puts them in line with the years going forward. Plenty of companies in my industry just do Y.0,Y.1,Y.2. Makes it a hell of a lot of sense.

Yup, year based would have made even more sense indeed considering their release cycle.

I suggest to jump to macOS 30 to win competition for YYMM version scheme like Windows 10 2004.

To the people downvoting this comment: By saying that 11 is what 10 was to Mac OS 9 implies the same substantial changes made to the whole system which is not the case here, at all. Mac OS 10 / OS X / macOS was a completely new system based on NeXTSTEP (or at least, completely different from Mac OS 9). It is still the same operating system, just in the usual upgraded fashion (although this time with more visual changes). By dropping the 10, Apple would have stated that macOS is just considered the successor to Mac OS (9) and the previous major "10" is already implied by the name. The 11 just makes no sense considering there has already been an 11th OS X.

I think the 11 is being justified as "supporting ARM64", but given 10.0 supported PowerPC, it does seem dubious.

I think it makes sense, considering arm macs will run iOS apps as more-or-less first class native citizens, it's a whole new native subsystem (and not just a catalyst shim)

Then again how does this differ from the mostly incremental updates 2 through 9? They had a naming strategy, changed it, and now seemingly reverted to the old one. I don't understand your reasoning.

https://twitter.com/peternlewis/status/1276777600027750400?s...

On the other hand, MacOS 7.6 to MacOS 8 was not much more than a rebadging and a few bundled widgets. 9->X was a once-in-a-lifetime architectural change and not historically typical of Mac system software major versions.

> By saying that 11 is what 10 was to Mac OS 9 implies the same substantial changes made to the whole system which is not the case here, at all.

This is not a rational metric for what a "full version tick" should look like. OS X was arguably a different operating system than Mac OS 9. If that was the bar to cross, Linux would still be 1.xx.xx and Windows would be Windows 3.xxx.

Considering they had a major break in backwards compatibility last year when they dropped 32 bit support, that was arguably the better year to do a major version tick.

Or 20.20 if the problem is apps checking for (minorVersion >= 12)

Oh, Linux can do this too!

  $ uname -a
  Linux h0nk 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
  $ setarch --uname-2.6
  $ uname -a
  Linux h0nk 2.6.79-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
  $ _

Of course, I shudder to think about the situations this would actually be used in.

The difference here is that the default behavior is to report the actual version and it is up to the user to enable the compatibility hack for broken software.

> Big Sur will identify itself as both version 10.16 and 11.0 according to context. This should put the minds of many at rest

Not mine. It's an extra piece of cognitive burden and another opportunity for misconfiguration.

Welcome to all technical migrations ever.

The ease of mind of the current developer is far less important than software not breakly widely for users because previous developers made bad assumptions about version strings.

Making policy to avoid the consequences of prior bad practices does not sound like a recipe for encouraging good practices moving forward. In terms of technical debt, it's like taking out a loan to pay off a credit card. I worry this will just lead to baking in more bad assumptions as developers hurry to get this off their plate.

I wonder why they don't announce a deprecation of the old versioning schema, and give developers time before switching, instead of just doing both at the same time with little to no warning. They've done that with lots of other technical migrations and even then, there is still plenty of controversy–see Catalina 32-bit support. Is there any reason to believe that doing a migration outright is safer, when the stepped approach has already proven difficult?

The least charitable guess I can come up with is that this was a mistake that they can't walk back for technical reasons, so are just fixing forward.

If it were up to me, I'd announce that a future version of macOS will increment the major version and that  will be moving to semver/calver/whatever-other-protocol, and do it when the current place name marketing strategy runs its course, as did the cat name marketing strategy. That would also give a few more years to get any major UI/system changes ready to drop for macOS 11. Just my 2¢.

The issue is old software continuing to work without having to be updated.

Giving more "time" solves nothing for all the programs out there that cannot or will not be updated for whatever reason.

This wasn't a mistake on Apple's part, it's just working around bad programming practice by developers. But there's no reason why users should suffer for it.

If they instead didn't move to 11 at all, what would stop working? What is the thing they are rushing to solve before things stop working? I think I'm missing something there.

I agree with users not needing to suffer, I'm not advocating for a hard break here.

Edit to add: is it necessarily a bad thing for unmaintained software to die? Keeping them around sounds like a great way to accumulate security vulnerabilities.

Damned if they do, damned if they don't…if Apple broke all the old software here, people would be up in arms about how they should have added a "legacy mode" for these applications.

This is not correct. It is being reported as 10.16 only on x86 and only temporarily. It is noted as such in the release notes. Final build will be 11.0.

It’s correct AND you’re currently correct. Both are true.

It is reported as 10.16 on Intel, and the final build will present itself as 11.0 unless the application is linked with an older SDK or you set the right environment variable.

I recommend reading the article, it is correct and the reasons why – for compatibility with legacy software – are interesting and well thought out.

I don't really understand why they add this complexity. Supposedly it's to avoid breaking backwards compatibility, but they break all kinds of backwards compatibility on every release anyway.

Is there context for this? Are apps breaking when the major version of the OS changes?

Lazy developers assuming majorVersion is always 10, so they do an "if minorVersion < 14 then error 'requires at least macOS 10.14'"

I suspect the larger problem is code that checks the minor version is > n and either refuses to run or disables capabilities that weren't available in the OS before 10.n.

Windows 95 (4.0) tells 16 bit apps that it is “3.95” because enough old apps had problems because of broken version checks. So it’s not without precedent for an OS to lie to old apps about version numbers, and in this case the version has been 10 for 20 years, so there are probably a fair few that assume the major part must be 10.

Windows 8.1 onwards also do in Windows land, with it returning the Windows 8.0 version number (NT 6.2, build 9200) for apps that aren't enlightened for newer versions.

Legend has it this is why Windows skipped version 9 - too many apps broke when they checked the version string just for “Windows 9” to capture both “95” and “98”.

I wonder if wanting to one-up Microsoft also came up somewhere once they both had an OS major version 10 :)

Opera 10 faced the same issue:

> The user agent for Opera 10 (eg Mac platform, English locale) will be as follows: Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00

> When we released the Opera 10 alpha in December last year, we gave it a Opera/10.00 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.0 user agent string. [...] It appears that a considerable amount of browser sniffing scripts are not quite ready for this change to double digits, as they detect only the first digit of the user agent string: in such a scenario, Opera 10 is interpreted as Opera 1.

https://maqentaer.com/devopera-static-backup/http/dev.opera....

I remember some softwares were broken when macOS 10.10 came out. Because they all assumed that the minor version is a single digit.

Since TLS 1.3, the version number in Client Hello package has been permanently frozen as TLS 1.0 to prevent breakage.

There is also a story that the copyright string in some old software by microsoft is permanently frozen for the same purpose.

> Client Hello package has been permanently frozen as TLS 1.0 to prevent breakage.

Which is actually reported as SSL 3.1 "to prevent breakage".

It's the first time in the 20 year history of Mac OS X that the major version number has changed. They're simply protecting against the likely possibility that some apps don't bother to check the major version.

Going forward, expect the major version number to change each year, like iOS. But for apps built against older versions of the SDK, the major version will always be 10.

How is Mac OS X two decades old? It feels like just yesterday I started my first real job, developing websites on a computer running Mac OS 10.1.

It’s because the fundamentals of the macOS user-experience haven’t changed much since OS X’s introduction of the dock and their fancy GUI effects: the “genie” window minimise is still there! And generally speaking, macOS’s aesthetics have been consistent too - we only saw Dark Mode added very recently, for example. Apple has also been very conservative about adding major user-visible features to macOS lately - but that’s more attributable to them devoting their resources to iOS instead of macOS.

Windows, on the other hand, updates its appearance (and adds (or removes) gimmicks) with each major release - even completely upending the UX fundamentals in Windows 8.

Also consider that we used to have to reformat/reinstall computer OSs more regularly in the past - and having to do reinstalls makes you think about your computer UX as you spend time changing the settings from the defaults to your custom preferences. I remember having to reinstall Windows 95-98 every 6-9 months, and Windows XP once every year or so. Since Windows 7 things have been a lot more stable - my current Windows 10 install would have been ~4 years old now if it weren’t for me losing all my documents in the October 2018 update... (all I got was $400 from MS, ugh)

That makes sense. Thank you for clarifying.

It's kind of a pain in the ass with regards to homebrew at the moment, yeah.

(Minor site feedback, if the authors/owners are here: please consider adding pointer-events: none to the "drop cap" decorative first letter so it doesnt obscure text selection of the actual article.)

Is there any confirmation if next year we should see macOS 12 or 11.1?

I hope it’s the former, as that will make yearly updates to macOS more consistent with iOS, iPadOS, tvOS, and watchOS.

It's likely that it will be macOS 12: https://github.com/WebKit/webkit/commit/805c4f790d01d8579a2a...

Ew, I do not like that!

I couldn't tell you why but it greatly bothers me.

Perhaps it’ll improve the security patch situation we have now where they differ by just build numbers, though.

They could fix that if they wanted by just adding another decimal.

I wonder if the real reason that Windows skipped version 9 was to "catch up" to Mac OS "Ten", and whether Microsoft will jump to 11 too now.

AFAIK Windows skipped 9 to avoid issues with bad version testing mistaking it for 9x (95, 98).

I don’t believe that for one moment.

If you ask Win32 for its version number you get a VERSION structure with Major/Minor/Build fields - not a string.

Windows faked its reported version information to software for compatibility purposes since Windows XP (opt-in) and since Windows 8 (opt-out, using application manifests) - so any program that doesn’t claim support for Windows 8, 10, etc is stuck in “Windows Vista mode” - so even if software was doing an osMarketingName.StartsWith(“Windows 9”) check it would be straightforward to make it work.

Reading https://www.gaijin.at/en/infos/windows-version-numbers, major.minor.build doesn’t uniquely identify a Windows version.

Windows 7 and Windows Server 2008 R2 both are 6.1 build 7600, for example.

Also, suppose you check the version for compatibility checking, what do you do if you get a version that you don’t know about, say “6.4, build 7709”? You can give up and declare your program doesn’t work with this version, but that may lead to lots of support calls when Microsoft rolls out a service pack. So, instead, programs try to guess from the version string what OS they run on.

And yes, ideally, programs check for features (https://docs.microsoft.com/en-us/windows/win32/sysinfo/opera...). Unfortunately the world isn’t perfect.

Internet Explorer 5.5 on Windows 95 looked like this:

> Windows 95 browser agent string: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95; BCD2000)

Back then browser agent checking was used a lot more.

So a good reason to name it "10" instead of "9" is to differentiate it from Windows 95/98 for code that did things like:

> browser.contains("Windows 9")

I think that was the official reason but I wonder... Not even the old bad GetVersion API’s in Win32 had anything to do with branding. 95 is Windows 4.00, 98 is Windows 4.10.

But sure, I believe them. If they could give a few product examples.

That is kind of crafty. I wonder if they intend to continue this with macOS 12 or to return to single version numbers?

I found that my iPad PRO lies about its user agent and will pretend to be MacOS by default. They don't even provide you with a hint to detect that it's a lie.

Yes, user agents are a mess (see this comment for non-Apple examples: https://news.ycombinator.com/item?id=23910637). They're not a good way to detect features as a web developer.

Yes, because Google Docs would throw a fit if it didn't.

In fairness, the user agent string isn't, and wasn't ever, intended to be a user-facing feature. It shouldn't matter to you what the user agent string reports.

Im on the beta and it takes a lot to boot it gets semi-stuck on like 80% for almost a minute..

Need to backup and do a clean install I guess

what can it be?

Do you have full drive encryption on? On my MacBook 12 2016 that seems like it gets stuck on initially.

If it's filevault. i've it disabled. didn't happen before big sur fwiw

Even Apple says it's a terrible idea to install beta versions on computers you actually use. Or like the data that's in them.

Reply on news.ycombinator.com