darwin: set the minimum version to macOS 11.3; nixos/doc/rl-2505: announce macOS version support policy

[emilazy]

This changes the minimum macOS version to macOS Big Sur 11.3 for 25.05, as announced in #338695, and further proposes that future Nixpkgs releases are expected to only guarantee support for versions of macOS that are supported by Apple, starting with macOS Sonoma 14 for Nixpkgs 25.11.

Apple only provides security updates for the last three releases. The statistics I’ve found point towards the conclusion that use of unsupported macOS releases drops off very quickly, especially among technical users:

• PyPI download stats for Pillow show that 98.35% of downloads were for a supported macOS version (macOS ≥ 11) in July–August 2023.

• The author of Downie, a macOS video downloader application, shares statistics showing that 92.35% of users were on a supported macOS version (macOS ≥ 12) in September 2024. In April 2023, the middle of the macOS 13 release cycle, 98.17% of users were on a supported version (macOS ≥ 11); even in December 2022, only two months after the macOS 13 release and around the time a Nixpkgs release would leave support, 97% of users are listed as being on a supported version, although those numbers were from Setapp and so probably cannot be compared one‐to‐one with the later statistics.

• When I was discussing version statistics in the Nix on macOS Matrix room at the start of the month, grahamc posted some charts from Determinate Systems data. I believe that one reflected early user data for their downstream Determinate Nix distribution and one reflected ephemeral CI installations using their installer (though I am not sure whether it was for all installations or only Determinate Nix). These charts are naturally going to be skewed by multiple factors and can’t be used as directly indicative of ongoing Nix on macOS usage, but both indicated that essentially 100% of their users are on a supported OS release, with even macOS 12, the oldest supported release at the time, only showing up in the charts as a small slice of GitHub Actions CI runners. (GitHub themselves are removing that runner image on about the same schedule we would drop support for it if we were already following this policy.)

Given this data, the fact that users remaining on unsupported OS versions are unlikely to have too much overlap with those who update to the newest Nixpkgs releases in a timely manner, and the unsafety of using macOS releases that are out of security support, I conclude that it’s not a good use of resources for us to support unsupported macOS versions in new Nixpkgs releases, and we should simply bump our requirements on the same schedule as Apple, as Homebrew does. This doesn’t mean that every package will instantly break for users on old versions; just that we’ll build packages with the newer SDK release and deployment target, and accept that some of the resulting binaries may use new APIs that don’t work on unsupported OS releases.

Keeping our supported versions in sync with Apple will result in fewer build failures because of unsupported APIs, reduced need for manual SDK version overrides to address those failures, and more OS features being utilized out of the box. Some of the FOSS ecosystem is already ahead of us: Qt dropped support for macOS 11 in 6.8, so 25.05 will ship with a minimum supported OS version that hasn’t been able to run the latest Qt release for over half a year. QEMU only officially supports the last two macOS releases, although they mercifully avoided using any features beyond the macOS 12 SDK in the period where we weren’t able to use anything newer. There are always going to be packages that don’t support every macOS version we do, but continuing to lag significantly behind some of the most important software we ship would be counterproductive.

As Apple tends to release new versions (and drop support for the oldest) around September–October, users of the oldest supported macOS release will have two to three months with a supported Nixpkgs version after that macOS release goes out of security support. I think that’s a reasonable buffer given the dynamics of the macOS ecosystem; we’ll still be supporting macOS releases for three years when we only support NixOS releases for seven months. After that, users can install a supported OS (potentially using OpenCore Legacy Patcher for old hardware, or even switching to NixOS), upgrade to the new Nixpkgs release and accept that things may break, continue using the current Nixpkgs release (it won’t get security updates, but neither will their OS), or switch to MacPorts, which keeps support for much older versions.

As far as the 11.3 bump goes, there’s a lot of cruft lying around to deal with the fact that we’ve been stuck on the 10.12 SDK on x86_64-darwin for a long time. That can now be cleaned up, reducing the maintenance burden of Darwin support across the project. In this PR, I’ve focused on things required to keep eval working after old SDKs are removed and simple clean‐ups of the SDK and source release packages, the Darwin standard environment, and compiler toolchains. I threw in a Nix change just for kicks, since I introduced that workaround and kind of hate it, and dropped two compatibility hooks that are no longer required. There’s a lot more throughout the tree that can be removed after this – I have almost 100 commits pending in my local branch – but this is a good start.

cc @NixOS/darwin-maintainers

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
    • apple-sdk_{11,12,13,14,15}
    • darwin.IOKitTools
    • darwin.adv_cmds
    • darwin.copyfile
    • darwin.diskdev_cmds
    • darwin.file_cmds
    • darwin.libpcap
    • darwin.libresolv
    • darwin.mail_cmds
    • darwin.network_cmds
    • darwin.patch_cmds
    • darwin.removefile
    • darwin.shell_cmds
    • darwin.system_cmds
    • darwin.text_cmds
    • darwin.top
    • gcc{10,11,12,13,14}
    • gtk4
    • haskellPackages.network
    • hello
    • libsForQt5.{qtbase,qttools,qttranslations,qtimageformats,qtdeclarative,qtmultimedia}
    • llvmPackages_{13,14,15,16,17,18,19}.{compiler-rt,libcxx}
    • llvmPackages_{15,16,17,18,19}.lldb
    • nixVersions.{nix_2_24,git}
    • python3
    • qt6Packages.qtbase
    • tests.cc-wrapper.default
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[paparodeo]

LGTM

[emilazy]

Rebased for conflicts.

[emilazy]

Okay, I’ve confirmed that bootstrap continues to work after actually pushing the compiler-rt change that I had previously neglected to. I’ve tested builds pretty extensively on x86_64-darwin when I first put up the PR, and the LLVM 19 work that is based on this PR has resulted in a bunch more testing on aarch64-darwin. I’ve also tested the LLVM 19 branch on Linux, so this shouldn’t break eval or anything there. I haven’t heard any objections to aligning our support policy with Apple’s since putting this PR up, so I think it’s time to land this 🎉