{"id":29536,"date":"2020-07-21T16:06:10","date_gmt":"2020-07-21T20:06:10","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=29536"},"modified":"2021-05-03T12:14:05","modified_gmt":"2021-05-03T16:14:05","slug":"big-sur-is-both-10-16-and-11-0","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/07\/21\/big-sur-is-both-10-16-and-11-0\/","title":{"rendered":"Big Sur Is Both 10.16 and 11.0"},"content":{"rendered":"

Howard Oakley<\/a> (Hacker News<\/a>):<\/p>\n

\n

For apps built with Xcode, the version returned depends on which version of its SDK they were built with. SDK 10.15 and earlier will consistently respond that Big Sur is major version 10 and minor version 16. This ensures that all existing apps should see Big Sur as simply an incremented minor version, as we had expected before WWDC this year.<\/p>\n

Build an app with a new release of Xcode which features the macOS 11 SDK, and the major version will be 11 and the minor version 0.<\/p>\n<\/blockquote>\n\n

Update (2020-08-19): Howard Oakley<\/a>:<\/p>\n

\n

One method commonly used to look up the macOS version number is to obtain the string value for the ProductVersion<\/code> key in \/System\/Library\/CoreServices\/SystemVersion.plist<\/tt>. However, depending on the environment of the caller, Big Sur plays tricks with that file, which should return a version of 11.0. If the caller has set SYSTEM_VERSION_COMPAT=1<\/code>, then the version number returned isn’t obtained from that property list at all, but its companion SystemVersionCompat.plist<\/tt>, which is 10.16.<\/p>\n<\/blockquote>\n

He says that reading the contents of that file actually returns different results depending on the value of the environment variable. That’s wild. So, if you clone your drive using a backup app that hasn’t been recompiled, the SystemVersion.plist<\/tt> in the backup will have the wrong version number.<\/p>\n\n

Update (2020-09-11): See also: Armin Briegel<\/a>.<\/p>\n\n

Previously:<\/p>\n