I am one of the apparently large majority of macOS Nix users now who run on Apple Silicon. However, I still use x86_64 builds to run Wine. With the new WoW64 implementation, Wine works on the latest macOS without any 32-bit system libraries. However, as far as I can tell, this still requires Wine be built for x86_64-darwin, running the whole thing under Rosetta 2. Today, this is easy: just import a second nixpkgs instance with system = "x86_64-darwin" and include Wine from it in one’s configuration.
While I imagine Wine will eventually support being built for aarch64-darwin and running AArch64, x86_64, and x86 Windows binaries, using Rosetta 2 internally as needed, as far as I can find there’s no timeline for when this might happen. (It seems effort in this direction is more focused on Linux at the moment.)
The announcement to drop support for x86-64 specifically calls out the Intel Macs will no longer be supported by Apple, with the current macOS 26 being the last to support Intel Macs. In that light, I can see the reasoning for phasing out being able to install on those machines along with building and caching the whole package set. That said, I wonder if it might be worthwhile to keep building just the specific packages (and their deps), such as Wine, that are useful to run on Rosetta 2 on Apple Silicon Macs, or at least not ripping out the ability to build them locally for the time being.
To me this sounds similar to the precedent with i686-linux and wine, steam, etc. But it will still be some tradeoff, both on infra costs but also maintainer time to keep stuff building successfully.
I use Wine for my FFXIV derivation. It’s one of the main reasons for my contributing to Darwin in Nixpkgs. Alas, things don’t look good for that. My plan is to use 26.05 for that indefinitely unless the situation changes.
Unfortunately, Wine won’t work natively on aarch64-darwin until Apple makes changes to macOS. If that ends up requiring an entitlement, we probably won’t be able to use it unless Apple allows it for ad hoc signed binaries.
This isn’t completely out of the question, but we’d need to be careful about the impact on maintenance and builders. Dropping x86_64-darwin lets us use that capacity to build more aarch64-darwin. I also expect users will try to use x86_64-darwin for other things then complain when it builds from source.
Long term, x86_64 support will go the way of PPC. I expect the 28.0 SDK won’t include stubs for it. It’s possible that could happen sooner (e.g., in the 27.4 SDK). We could maintain an old SDK for x86_64-darwin support like we did before, but I’d rather not (because I expect the ecosystem to drop support for it quickly).
I wonder if there could be a compromise solution to help keep such packages buildable without using as many resources. E.g., have a less frequent builder that just checks whether the key packages of interest still build. Of course, that would mean either not having a binary cache or having a separate channel that lags unstable. I would be fine with the former (the system in question builds everything from source anyway for other reasons), but I imagine others might prefer having access to a binary cache for those packages.
As far as complaining when other packages have to build from source, well, if you have to explicitly opt-in to it being a lower tier of support to use it, hopefully there’s not too much room to complain.
CodeWeavers posted about CrossOver 27. One of the big changes coming is running ARM64 on macOS and Intel applications without using Rosetta 2.
I’m looking forward to the source drop to see what they did. I assume it’s a combination of entitlements (e.g., those discussed here plus maybe this one) and loader changes. If the patches are easy to extract, it looks like aarch64-darwin Wine in Nixpkgs is a possibility.