`platform.mac_ver()` returns macOS version of 16.0 instead of 26.0 on Tahoe

[bwoodsend]

Bug report

Bug description:

macOS have switched their versioning scheme to calendar based so we're going 14 -> 15 -> 26 -> 27. Python is reporting the old versioning scheme.

> python -c 'import platform; print(platform.mac_ver())'
('16.0', ('', '', ''), 'arm64')
# Or
> python -m platform
macOS-16.0-arm64-arm-64bit

Apple appear to be pulling the same stunt with /System/Library/CoreServices/SystemVersion.plist (the file used to identify the macOS version) as they did with the 10.x -> 11 transition where, in order to avoid breaking code that made invalid assumptions about what the next macOS version would be, they instead broke it for everyone by making the file dynamically mislead any program which tries to read it which isn't compiled with SDK >=26.

Dynamic file contents!

> cat /System/Library/CoreServices/SystemVersion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildID</key>
	<string>B41EBE0C-41CA-11F0-B36A-391502BEE5D6</string>
	<key>ProductBuildVersion</key>
	<string>25A5279m</string>
	<key>ProductCopyright</key>
	<string>1983-2025 Apple Inc.</string>
	<key>ProductName</key>
	<string>macOS</string>
	<key>ProductUserVisibleVersion</key>
	<string>26.0</string>  # <--- Good
	<key>ProductVersion</key>
	<string>26.0</string>
	<key>iOSSupportVersion</key>
	<string>26.0</string>
</dict>
</plist>

> python -c 'print(open("/System/Library/CoreServices/SystemVersion.plist").read())'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildID</key>
	<string>B41EBE0C-41CA-11F0-B36A-391502BEE5D6</string>
	<key>ProductBuildVersion</key>
	<string>25A5279m</string>
	<key>ProductCopyright</key>
	<string>1983-2025 Apple Inc.</string>
	<key>ProductName</key>
	<string>macOS</string>
	<key>ProductUserVisibleVersion</key>
	<string>16.0</string>  # <--- Bad
	<key>ProductVersion</key>
	<string>16.0</string>
	<key>iOSSupportVersion</key>
	<string>26.0</string>
</dict>
</plist>

> otool -l /bin/cat | grep sdk
      sdk 26.0
> otool -l (pyenv which python) | grep sdk
      sdk 13.3

The behaviour is tied to the SDK version that Python is compiled with so this affects any existing builds of Python (including the official installers) and any builds done in the future not on SDK 26. It doesn't affect the (deprecated) system installation of Python which is compiled with the latest SDK. It is possible to get around this by installing the experimental Xcode command line tools for 26 then rebuilding Python from source.

Would it make sense for platform.mac_ver() to correct versions [16, 26) to their actual version?

CPython versions tested on:

3.15

Operating systems tested on:

macOS

[StanFromIreland]

cc @malemburg

[malemburg]

It would definitely make sense to have mac_ver() return the correct version number.

If the file no longer provides a reliable way of doing this, is there some other file or perhaps a command line tool which could be used for this ?

@ronaldoussoren or @ned-deily : Any suggestions ? Thanks.

[bwoodsend]

If CLI commands are on the table then sw_vers --productVersion behaves itself. It adds about 20-40 milliseconds to startup time.

[ronaldoussoren]

Is the python version you're using build with the macOS Tahoe SDK?

If not, this is expected behaviour. As with the transition from macOS 10.15 to macOS 11.0 the system lies about the version to binaries compiled with an older compiler to avoid backward compatibility issues.

I'm not a fan of this feature, but IMHO it is not worth it to work around this. In due time we'll distribute binaries compiled with the next production release of Xcode and the issue will go away.

See also: https://eclecticlight.co/2025/06/13/is-tahoe-really-macos-26-or-16/. This also mentions a workaround if this feature bothers you: set SYSTEM_VERSION_COMPAT=1 in the environment before starting Python.

[ned-deily]

As @ronaldoussoren notes, if your application needs to know the "real" version number, the solution is to set SYSTEM_VERSION_COMPAT=0 (not 1!). This is the same solution that Apple provided for the transition from macOS 10.15 to Big Sur 11.0 and which still works on macOS systems since 11.0. For example, using older (end-of-life) versions of python.org installers (that were built with pre-11 SDKs) on current macOS 15.x systems:

$ sw_vers
ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
$ python3.7 -VV
Python 3.7.9 (v3.7.9:13c94747c7, Aug 15 2020, 01:31:08)
[Clang 6.0 (clang-600.0.57)]
$ python3.7 -c 'import platform;print(platform.mac_ver())'
('10.16', ('', '', ''), 'x86_64')
$ SYSTEM_VERSION_COMPAT=1 python3.7 -c 'import platform;print(platform.mac_ver())'
('10.16', ('', '', ''), 'x86_64')
$ SYSTEM_VERSION_COMPAT=0 python3.7 -c 'import platform;print(platform.mac_ver())'
('15.5', ('', '', ''), 'x86_64')

There should be no harm in leaving that env variable set even when no longer needed. If necessary, it could be included in a launch shell script or, if embedding a pre-built Python in an macOS app bundle, it might be possible to set the environment variable in a LSEnvironment key in the app's Information Property List.

I am also no fan of this behavior but I can only suppose that Apple found too many third-party apps and command line tools (not necessarily Python-based ones) that did have problems with the version leap from 10.15 to 11.0. That said, it would seem that the leap between 15.x and 26.0 should be less problematic for the macOS ecosphere.

We also need to keep in mind that macOS Tahoe 26, its SDK, and Xcode 26 are in the early stages of public exposure with only one developer beta released so far so this behavior could change and we won't be releasing any builds of Python built with the Tahoe SDK until all are officially released by Apple.

More importantly, there is nothing we can do for the many versions of Python binaries that are already out there and that will continue to be used for years other than to suggest either using SYSTEM_VERSION_COMPAT=0 or modify user application code to expect either version if this distinction is important. The experience with the 10.15 to 11.0 transition suggests that the distinction was not important for the vast majority of uses and users. (There were other, more important issues with that earlier transition not related to this version number behavior.)

In short, I don't we should do anything in platform.mac_ver() for this. But there might be some edge cases elsewhere that could use some refinement as there are still a few open issues that remain from the earlier transition. We should find some time to review those.

[ned-deily]

An afterthought: I certainly wouldn't be opposed to adding something to the platform.mac_ver() documentation about this behavior at some point. PRs welcome.

[bwoodsend]

Fair enough. I figured that since we didn't do anything about 10.16 vs 11.0 it was unlikely that we'd do anything this time.

[ned-deily]

I figured that since we didn't do anything about 10.16 vs 11.0 it was unlikely that we'd do anything this time.

ISTM that the biggest problem is that, in general, we can't (and couldn't) do much about this short of rebuilding and rereleasing older Python binaries and forcing everyone to upgrade to them :) We can update the documentation, though, and suggest using the SYSTEM_VERSION_COMPAT=0 if it is a problem for a particular use case. As Ronald notes, eventually this issue should go away with newer releases of Python after Tahoe is released.

[malemburg]

Agreed. Let's document the behavior of the OS and the work-around @ned-deily posted.