Moving packaging and installers to macOS 10.13 as a minimum

In conda-forge, we are starting the work to bump the minimum macOS version to 10.13 ( DISCUSS: Raise MacOS minimum target from 10.9 to 10.13? · Issue #1844 · conda-forge/ · GitHub ). While we have managed to keep macOS 10.9 working for a long time (and occasionally bump the minimum of some package as needed), this is starting to get impractical to maintain.

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)

Looks like this issue has been encountered before

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 :slight_smile:

1 Like

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 installer builds to a newer minimum version sometime in the not too distant future along with other enhancements.

1 Like

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.

1 Like

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).

Third-party sites such as Apple macOS | say the last three main releases are usually supported:

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.

(The three latest being macOS 11, 12 and 13.)

macOS version history - Wikipedia has something similar.

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

system_name distro_version download_count percent summed_percent
Darwin 10.7 2 0.00% 100.00%
Darwin 10.9 16 0.00% 100.00%
Darwin 10.10 54 0.01% 100.00%
Darwin 10.11 134 0.01% 99.99%
Darwin 10.12 292 0.03% 99.98%
Darwin 10.13 1,664 0.17% 99.95%
Darwin 10.14 2,066 0.22% 99.78%
Darwin 10.15 11,597 1.21% 99.56%
Darwin 11 195,519 20.38% 98.35%
Darwin 12 426,878 44.49% 77.97%
Darwin 13 312,566 32.57% 33.48%
Darwin 14 8,715 0.91% 0.91%
Darwin 15 7 0.00% 0.00%
Darwin 16 19 0.00% 0.00%
Darwin None 31 0.00% 0.00%

This shows 98.35% is 11+, and 99.95% is 10.13+.


Firefox dropped 10.12-10.14 in this month’s version 116. Some more background:

Chrome will also drop 10.13-10.14 and only support 10.15 or later, starting in next month’s version 117:

1 Like

From the perspective of distributing CPython extensions that use C++, a transition to 10.13 is much needed to support language features.