[GekkePrutser]

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.

[kalleboo]

> 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/

[gregoriol]

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

[GekkePrutser]

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.

[gregoriol]

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...

[etaoins]

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.

[tobr]

What if next year is 12.0 and 10.17?

[torarnv]

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..?

[klodolph]

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

[steviedotboston]

Don't get me excited now...

[mattl]

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

[gregoriol]

Your comment made my day :-D

[samcat116]

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.

[GekkePrutser]

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.

[samcat116]

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.

[pixel16]

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

Source: Microsoft Employee

[klodolph]

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

[GekkePrutser]

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

[klodolph]

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.

[radlad]

The right decision may still be a complex mess.

[GekkePrutser]

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?

[zeroimpl]

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.

[coldtea]

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

[coldtea]

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

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