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.
> 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/
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 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.
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.
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.
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.
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.
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*")
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.
