Map version for Tahoe compatibility.

[vcsjones]

macOS Tahoe returns a compatibility version, 16, for macOS 26 unless it is built with Xcode 26's SDK. As we did with Big Sur, this maps the compatibility version 16 to 26.

The intention is that we will be on the new SDK by the time macOS 27 rolls out. If not, then we will need to add another compatibility map, most likely. It does not appear that iOS, tvOS, or Catalyst return compatibility numbers, so they are excluded from doing any mapping.

Fixes #116503

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

Adds mapping for macOS Tahoe’s compatibility version (16.x) to the correct major version (26.x) under the TARGET_OSX build flag, replacing the old 10.16→11.0 mapping.

• Wrapped the version check in #if TARGET_OSX to exclude iOS/tvOS/Catalyst
• Changed the condition from (major == 10 && minor == 16) to (major == 16)
• Updated comments to describe 16.x→26.x mapping

Comments suppressed due to low confidence (2)

src/libraries/Common/src/Interop/OSX/Interop.libobjc.cs:50

• Add unit tests for GetOperatingSystemVersion to verify that inputs of Version(16, n, p) are correctly mapped to Version(26, n, p) for various minor and patch values.

if (major == 16)

src/libraries/Common/src/Interop/OSX/Interop.libobjc.cs:52

• Consider updating the XML documentation for GetOperatingSystemVersion to mention the special mapping of compatibility version 16.x → 26.x on macOS Tahoe.

// MacOS Tahoe returns a compatibility version unless it is built with a new SDK. Map the compatibility

[akoeplinger]

/ba-g android is timing out to due an infrastructure issue, ios failure is unrelated

[akoeplinger]

I wonder if we need to backport this. We're not aware of anything that's broken by the compatibility version number right now correct?

On the other hand it might be unexpected if 8.0/9.0 silently gets this fix once the Azure Pipelines macOS images are bumped to the new SDK...

[vcsjones]

I wonder if we need to backport this. We're not aware of anything that's broken by the compatibility version number right now correct?

It affects IsMacOSVersionAtLeast so if someone is targeting .NET 8/9 and expects IsMacOSVersionAtLeast(26) to do the right thing, it won't. It'll also probably affect things like telemetry and dotnet --info

And yes, it might jump from 16 to 26 if servicing bumps the SDK.

[akoeplinger]

yeah, probably safer to backport.

I wonder if they'll really report 17.0 on macOS 27 or just continue to report 16.0 if you still built with on an older SDK. The latter is how they did it with the Big Sur transition, e.g. SYSTEM_VERSION_COMPAT=1 cat /System/Library/CoreServices/SystemVersion.plist claims 10.16 on my macOS 15.5 machine 😄

[akoeplinger]

/backport to release/9.0-staging

[akoeplinger]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/15640235698

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/15640237731

[vcsjones]

latter is how they did it with the Big Sur transition

Ah, yeah, I didn't know that. If they totally freeze the version number for compat then we should probably back port, otherwise 26 and 27 will be the same version.