Hi everyone, There’s been a lot of interest in this over the years, and I’m excited to announce that all the pieces are now present in macOS to natively run ARM64 Wine. Thanks to all the teams at Apple and CodeWeavers who have worked on this effort. For anyone who wants to test this out now, last week CodeWeavers released a CrossOver Preview for macOS that uses ARM64 Wine in combination with FEX for i386/x86_64 (ARM64EC) emulation: <https://www.codeweavers.com/blog/mjohnson/2026/7/31/crossover-preview-the-ri...> I’ll be sending MRs upstream soon to enable this, but here’s more details on what’s been added to macOS: **x18** Apple’s ARM64 ABI reserves x18 for use by the platform, and on recent OS versions it’s liable to be cleared at any time. The Windows ARM64 ABI uses x18 for the TEB, which conflicts with Apple’s ABI. In macOS 26.5, Apple has added a special “x18 custom ABI” mode that threads can switch into when running code that uses x18, and then switch out of when calling back into system frameworks. See <usr/include/os/arch/arm64.h> in a current SDK for more details. I’m working on patches to use this API in Wine. Alternately, older versions of macOS (11/12) did not clear x18, and current versions of macOS continue to maintain that behavior for binaries built against those older SDKs. Linking with `-Wl,-platform_version,macos,11.0,11.0` results in x18 not being cleared. This is a workaround that can be used until Wine is using the x18 custom ABI. **4K pages** macOS on ARM64 uses 16K pages, and Windows on all platforms uses 4K pages. Wine has some ability to work around this mismatch, but it’s not possible to fully emulate 4K page semantics. macOS 26.5 adds `posix_spawnattr_set_4k_page_size_np()`, a posix_spawn attribute that will spawn/exec a process with 4K pages. **PAGEZERO** macOS on ARM64 enforces a PAGEZERO of at least 4GB, preventing Wine from mapping USER_SHARED_DATA at 0x7ffe0000 (where Windows maps it on all platforms). Emulating i386/x86_64 Windows binaries also requires using the below-4GB address space. macOS/Xcode 26.4 have kernel and linker changes (the new `-Wl,-x86_64_layout_emulation` flag) which allow the PAGEZERO size to be changed, and also remapped. The best approach we’ve found is to actually increase PAGEZERO’s size to around 0x170000000, this reserves that entire address space for Wine. **TSO** Apple’s CPUs include support for the TSO memory model, to speed-up emulation of x86 code. macOS 26.5 allows this to be enabled per-thread with the `thread_set_x86_64_compat()` call. Note that newly-created threads do not inherit this state. **Entitlements** Unfortunately, restricted entitlements are required to run binaries using any of the above features. These entitlements require an Apple developer account to use: `com.apple.developer.cross-architecture-support` is available to paid developer accounts, `com.apple.developer.cross-architecture-support-unmanaged` is the same except that it’s available to free developer accounts. More detailed documentation will be coming along with Wine patches, but the rough process is: in your developer account, create an App ID for the Wine loader and enable the Cross-Process Architecture entitlement for it. Ensure your Mac’s provisioning UDID is added to your account. Create a provisioning profile for the app ID, and download it. The profile needs to be placed in a .app bundle along with the Wine loader. It is possible to bypass all this by disabling System Integrity Protection and setting kernel boot args to disable entitlement and code signing restrictions. We'll document that too, although SIP is a key part of the macOS security model and ultimately we can’t recommend disabling it. Again, I’ll be submitting Wine MRs soon to take advantage of these new features. Brendan