Hi, my Mac from 2018 is unsupported as of Nix 25.11. Is there any way to update packages to the newest versions, or do I have to start installing software manually instead?
Like how you can be on an old version of npm or the App Store, but they still let you get the latest versions of packages/apps.
For context, I just use the Nix package manager
Nixpkgs packages target 14.0 at its oldest now: https://nixos.org/manual/nixpkgs/stable/#sec-darwin-troubleshooting-using-deployment-targets
Nix 25.11 doesn’t exist, this is strictly about the oldest stable nixpkgs version. You can use nix itself to build arbitrary software, but up-to-date packages from nixpkgs aren’t built targeting older MacOS anymore. You can of course always continue to use an older nixpkgs, but that will be potentially insecure starting end of this month.
Unfortunately you’ll have to migrate away from Nix to Macports, or from macOS to NixOS (which likely would work well on your hardware), as has been mentioned in the release notes:
Nixpkgs 25.11 will require macOS Sonoma 14 or newer. Users on old macOS versions should consider upgrading to a supported version (potentially using OpenCore Legacy Patcher for old hardware) or installing NixOS. If neither of those options are viable and you require new versions of software, MacPorts supports versions back to Mac OS X Snow Leopard 10.6.
macOS 14 is also the oldest version that is still getting security updates from Apple. It looks like OpenCore Legacy Patcher should let you run macOS 14 on any Mac from 2018 (and macOS 15 on many of them); I’d recommend that if you don’t want to install NixOS.
Edit: It also looks like macOS 14 supports many models from 2018 out of the box without patching; it may be that you just need to update your OS, but it’d depend on what exact hardware you have.
Thanks for the replies! Sucks that it’s like this, these days computers from 2018 work very well. Wish Nix didn’t follow Apple’s stupidly short support time.
Switching to Linux isn’t an option for me. I could do OpenCore, but I assume Nix will just drop support for x64 in a year
Is there anywhere I can advocate for longer support?
My Mac model was available until 2019, so some people got support for only 6 years (which especially says a lot about Apple, barely doing the legally required 5 years)
The plan is to drop support for 26.11, but in practice it will be less than a year for unstable because the necessary changes will have to happen before the release. 26.05 will be the last stable release with x86_64-darwin support.
Edit: Better wording and clarity.
Consulting company maybe. It doesn’t make sense for the core (volunteer) project to support.
Just out of curiosity: why?
The deal-breaker is that I animate PSD files in After Effects with various plugins. AE is already slow and unstable enough running natively so I’m skeptical about using a compatibility layer.
Aside from that, these are the things that are important to me but which I don’t know how Linux compares (sorry for the wall of text):
Why does it not make sense? Is it more work than other volunteer projects that provide longer support?
The only package ecosystems providing longer support are MacPorts, Fink, and pkgsrc. I used MacPorts for years and would still be using it if not for Nix.
Homebrew has similar support tiers. Technically, you can try using 25.11 (and unstable) on an older release of macOS (like you can on an unsupported platform with Homebrew), but it’s likely you’ll run into problems because of packages being built to expect newer APIs to be available.
Other package ecosystems for macOS have at least a magnitude more maintainers compared to the number working on Darwin support in Nixpkgs. Being able to assume a recent release simplifies maintenance considerably. If Linux maintainers can enable support for Darwin without having to do anything, that results in more packages building for Darwin.
Historically, Nixpkgs appears to have followed a similar update schedule. The minimum version was bumped to 10.10 in 2016 and to 10.12 in 2019. If we had continued bumping at the rate we were before, the minimum version would be 13.0 for 25.11. We chose 14.0 to align with Apple’s (unofficial, AFAIK) policy to provide (some) security updates to the previous two major releases.
One might notice that minimum version updates were less frequent in the past. That was due to the difficulty of updating the SDK framework packages. That was resolved for the 24.11 release with a new SDK pattern that is easier to update and support newer SDKs. It should be expected that the default SDK and minimum supported version will be updated regularly going forward.
3-9 are quite doable, 2 I’ve no idea, and 1 is pretty much impossible - but you’re already writing code for nix so I don’t see the objection, and reboots are mostly rqeuired for updates of core system components irrespective of OS.
Thanks for the explanation
Being able to assume a recent release simplifies maintenance considerably. If Linux maintainers can enable support for Darwin without having to do anything, that results in more packages building for Darwin.
Are you referring to package maintainers or core maintainers themselves? I don’t really see this as a problem for package maintainers because programs decide what OS versions they support, so the package would just support what the program supports. And these days it’s so easy for programs to support old macOS versions - The vast majority of programs don’t need to do much, if anything, to support macOS 10.13. If there were big changes in OS versions (like there used to be up until the early 2010s) I’d understand this more
Both. The Darwin core team has three people, but only two are active currently (me and @emily). There is a larger group of people who work on Darwin stuff, but they usually don’t work on the core packages (SDK, source releases, tooling, etc). Making the core packages easy to maintain helps manage our load. Making Darwin easy to support helps Linux-based maintainers support Darwin without having to put in much effort. It also helps the wider group of Darwin maintainers contribute if they don’t have to deal with backporting (or writing) support for older releases.
It’s not unusual for packages to be maintained by maintainers who have no access to macOS or Mac hardware. It has also been a point of contention in the past that supporting Darwin is burdensome, so making things easy for the Linux-based maintainers also reduces friction in the project itself.
MoltenVK requires 11.0. Qt requires 13.0. QEMU requires 13.0. libuv, which is a CMake dependency, requires 11.0 (and actively rejects patches to support older versions). psutil, which is needed to run LLVM’s tests, requires 11.0. We build our toolchains from source, which means that when Swift dropped the concurrency backdeploy, any package using Swift Concurrency effectively requires 12.0. We also link against the system libc++. Packages that use newer C++ features will require newer versions (e.g., Nix is using an API that requires 13.3 IIRC). Anything that wants to use the Accelerate framework for BLAS needs 13.0 or (preferably) 14.0. We want to make KosmicKrisp the default Vulkan implementation once it is part of a stable Mesa release. The current development branch requires 15.0, but they may increase it to 26.0.
(Nevermind the amount of patching it took to build the Apple source releases on older versions. Being able to assume 14.0 let me drop a lot of workarounds and simplify patches in our derivations.)
That’s just off the top of my head. We used to carry patches for many of these packages to support older releases, but they were a maintenance burden. Some of these just aren’t possible to backport because they depend on newer functionality that just isn’t available. It may not seem like it, but Apple has been steadily adding new APIs (both POSIX, BSD, and other like the futex APIs added in 14.3). We do support allowing packages to require a newer version, but that starts to become problematic when core packages require a newer version. Ideally, users on supported versions should be able to do a full source build of their system.
I see, thanks. Sad that the situation is this bad