OWC (a popular 3rd party supplier of macOS hardware) publishes a matrix of hardware supported by different macOS versions. In going through all of these any hardware made in 2010 or later can run at least 10.13 (or later). In some cases machines from the latter half of 2009 can also upgrade to 10.13. IOW this would cover 13-14 year old hardware, which is pretty good support.
Also this is more in line with recent Xcode versions. For example in the Xcode 14 release notes, it says:
Building for deployment to OS releases older than macOS 10.13, iOS 11, tvOS 11, and watchOS 4 is no longer supported. (92834476)
It should also better support libraries that already require some newer macOS version. Here’s a list a colleague put together of feedstocks in conda-forge that already need to opt-in to a newer macOS to build (would think this is the same story for wheels as it is due to the system symbols/features used).
Anyways wanted to kick this discussion off and see what others think about bumping the macOS version used in the Python ecosystem. Please share your thoughts
On macOS, the deployment target is the minimum supported version but it’s not mandatory that all components be built to that same minimum version. That is, even if the Python interpreter is built to support macOS 10.9, generally packages can be built to a minimum deployment target newer than 10.9 if support of the older systems is not needed or too difficult. If needed, specifying the environment variable of, say, MACOSX_DEPLOYMENT_TARGET=10.13 in the build environment of the package should handle that. That said, we will likely move python.org installer builds to a newer minimum version sometime in the not too distant future along with other enhancements.
I’d prefer to have a consistent set of macOS releases supported throughout the ecosystem. As Ned noticed it is possible to install wheels supporting macOS 11 or later in a Python installation with deployment target of 10.9, but it would IMHO be a bad experience when you can install Python but not common packages (except for hardware/software features that make it impossible to support, such as software using the Metal framework needing at least macOS 10.11).
Looking at the OCW hardware list it might even be possible to move up to supporting macOS 11 as the deployment target. Compared to a deployment target of 10.9 this excludes hardware released between 2009 and 2012, getting support for “only” 10 year old hardware which is still quite good and hopefully reduces the risk of Apple dropping support for the deployment target in a future Xcode/SDK update during the support window for a Python release. MacOS 11 is also the first release with Apple Silicon support, giving us a consistent deployment target for both architectures until Apple drops support for Intel hardware in their developer tools.
Looking at some other software:
Firefox supports macOS 10.15 or later in regular releases (didn’t look as ESR)
Chrome supports macOS 10.13 or later
Dropbox supports macOS 10.13 or later
VSCode supports “macOS versions still receiving security updates” (generally last 2 releases)
Finally, it would be nice if we could write down the deployment target considerations in PEP 11, similarly to how support for windows releases is documented. The annoying part is that we cannot refer to Apple documentation for this, AFAIK they don’t have a documented support policy for macOS although we can infer that their support policy is general security updates for the last major release.
A separate discussion is what versions of macOS we want to support in the CPython source tree. Moving the minimum version for the deployment target there as well allows us to drop parts of the weak linking in support in a number of extension modules, including posix which is a maze of preprocessor code even without macOS weak linking support.
I don’t have a strong opinion in either discussion at the moment, for my own needs I only need support for the latest two macOS versions.
I’ve only added support for a deployment target of 10.9 to the source tree to allow for building Universal 2 binaries without changing the matrix of supported macOS versions, but haven’t ran a system with 10.9 in a long while (other than a test VM that I sometimes use to test stuff).
Major versions of macOS are released once a year now, and usually maintained for three years. Apple usually provides security updates for the latest 3 releases, but this isn’t consistently applied and some security fixes aren’t available for the non-latest releases.
For Pillow, we nominally only support upstream supported OS releases, but for macOS we set MACOSX_DEPLOYMENT_TARGET=10.10 for Intel because we had quite a few people asking for older versions at some point, and it’s not too much extra effort (and MACOSX_DEPLOYMENT_TARGET=11.0 for Apple Silicon, the earliest).
Looking at pip installs for the newest Pillow 10.0.0 for the last 28 days (via pypinfo --days 28 --percent --limit 1000 --json "pillow==10.0.0" system distro-version using pypinfo, and summarising with macos-versions.py):
