GitHub Actions ending support for Intel runners

[colincornaby]

GitHub is deploying macOS 26 runners - but has only deployed ARM64 ones. There is some conflicting information on Intel support - but Intel support is exclusive to Teams and Enterprise customers for macOS 14. And no Intel runner support has been announced for macOS 26.

Xcode 26 will require at least a macOS 14 runner. Because we can't access macOS 14 Intel runners - the migration to Xcode 26 will end our ability to build on Intel. (And we're now discussing #1790 which may force this transition.)

I think we've now reached the point where we need to discuss either ending Intel build support through our Github, or working out the cross compilation issues so we can build the Intel client on an ARM64 Mac.

[colincornaby]

I'll add - one possibility we should look into is Rosetta to emulate a x86_64 build environment on an Apple Silicon runner. But I don't know if the Github runners have Rosetta installed and that might only buy us another year.

[dpogue]

As it currently stands, we use macos-13 for x86_64 builds and macos-14 for arm64 builds. In the short term, we should be able to move the arm64 builds to macos-26 and all will be good.

Longer term, I'm hoping we can sort out the cross-compile issues because that would make it a lot easier to do universal builds with lipo, but at some point x86_64 just isn't going to be supported by Apple's tools anymore (like how i386 support was dropped from the tooling in Xcode 10+)

[Hoikas]

Xcode 26 will require at least a macOS 14 runner. Because we can't access macOS 14 Intel runners - the migration to Xcode 26 will end our ability to build on Intel. (And we're now discussing #1790 which may force this transition.)

A pull request to add an icon should not and cannot cause us to trash support for an entire toolset. I would consider such a bump unacceptable. We can't help what GitHub does, so if they trash the Intel runner that's one thing. In that case, we can hunt down alternatives, like AppVeyor.

[patmauro]

(And we're now discussing #1790 which may force this transition.)

A pull request to add an icon should not and cannot cause us to trash support for an entire toolset. I would consider such a bump unacceptable.

For the record, I'm with Hoikas here... Obviously I get that this is a much bigger conversation about the transition to XCode26, and this is mainly just semantics due to where this observation originated, but I would ask that we be careful to avoid the framing of #1790 being the deciding factor in whether a transition needs to be forced - the icon is definitely not a priority here, and even if it was, there is currently no real rush to adopt the new .icon standard (Apple has not deprecated asset libraries for icons afaik). I would really hate to be indirectly responsible for this project having to drop any support here prematurely. 😬

[Hoikas]

I am hopeful that this is not an "either-or" situation. If older Xcodes cannot cope with the .icon file being present, we can probably ensure it does not get added via CMake.

[dpogue]

Worst case, CMake has an XCODE_VERSION variable that we could use to only add the resource if building with the Xcode generator on Xcode >=26.

I don't know if there's a way to support .icon files outside of Xcode projects (i.e. Ninja or Makefile builds) right now.

[colincornaby]

Older Xcode doesn't know anything about the .icon files because it's a new file format. That may or may not matter - our output is still different than the output I'm seeing for Apple apps and I need to dig into why. If it is a zero touch process and Xcode just needs to copy a file where it needs to go we should be fine with older versions of Xcode.

Following up on the general discussion, it looks like Github commented on this yesterday:
actions/runner-images#13027 (comment)

Was re-iterated that the macOS 13 runners will be going away but something will be done for Intel runners. Hoping we can get macOS 15 runners.

Python is doing universal builds for their framework builds. I'm wondering if there is something we can pull from that to do static universal builds. That would sidestep this whole mess.

[patmauro]

If older Xcodes cannot cope with the .icon file being present, we can probably ensure it does not get added via CMake.

I don't know if there's a way to support .icon files outside of Xcode projects (i.e. Ninja or Makefile builds) right now.

Older Xcode doesn't know anything about the .icon files because it's a new file format.

So, just to touch on this for a second... we've been focusing a lot on the .icon files specifically here, but just to clarify: more broadly, it's not just the .icon files themselves, but the new macOS/iOS 26 icon standards as a whole, right? (And presumably any other quirks the new OS may have introduced, with this just being one of the more immediately visible ones) For instance - even if we didn't include an .icon file at all and just generated new set of flat PNGs to the asset library instead (which is still a supported method), presumably that still wouldn't do us much good, since:

• Tahoe generates its icons at full-size 1024px, but Sequoia assumes there is a 100px "safe zone" around the edge of the png. This scaling difference would result in completely different output.
• Tahoe has a dark mode variant and a "Tinted Dark" variant; Sequoia does not.
• Tahoe & iOS26 support Clear Light, Clear Dark and Tinted Light variants; Sequoia & iOS18 do not.
• XCode 26 would know what to do with these extra assets, and could probably even back-convert the icon scaling so it works for Sequoia - but the reverse is not true since XCode 16 would obviously have no frame of reference for this.
• Tahoe does adapt Sequoia-era icons on the OS level, but these converted icons miss out on these additional features.

Does that all sound accurate? This might not be the right thread to bring this up in (perhaps the draft PR might have been more appropriate) but just figued this was worth clarifying, to make sure we were all on the same page here - I just fear focusing specifically on the .icon format may be missing the forest for the trees a bit here, with regards to this XCode 26 situation. 🤔

[colincornaby]

For context - I've replied in #1790 about the icons. Proper packaging of the icon will require the new SDK. There is a build step required that the existing toolchain does not support. We need the Xcode 26 toolchain to build the icon. The short version is that .icon is the format for editing the icon, not the format we ship. The toolchain needs to "compile" the icon into the asset catalog. So that is one change that will be gated here.

More relevant to the thread, Github issued more guidance on Intel runners today: actions/runner-images#13045

Basically:

• There will be a macOS 15 Intel runner
• But it will be the last Intel runner

Xcode and the macOS SDK will drop support for being hosted on macOS 15 sometime next year. I'm guessing GitHub will drop support for the runner in two years. So that gives us 1-2 to figure out what we're doing with Intel support.

That does mean the icon issue will be addressable and we will be able to adopt the macOS 26 SDK.

I think I mentioned this elsewhere - but Python does support cross compilation by default for Python. I'd like to dig into why our build configuration does not support cross compilation.

[colincornaby]

I spent some time looking at the Python cross compilation issue.

It looks they have the same concerns about the dwindling number of Mac x86_64 build agents that we do. There is a patch that was merged for doing cross compilation of Mac CPython. It looks like that change will come in 3.14.

python/cpython#128385

I would recommend that when we update to 3.14 that we begin cross compiling CPython. I would suggest that we look at narrowing our Mac build agents to just the ARM ones so we can get on a single SDK and single configuration.

Beyond that - I would expect at some point Apple will remove cross compilation support completely from their SDKs. PowerPC support was removed from the SDK one year after they dropped PowerPC support from the operating system. So I would expect in two years we might be having a different version of this conversation where Apple is no longer supplying new SDKs that support Intel compilation or provide Intel headers or system link targets.

[Hoikas]

It looks like that change will come in 3.14.

That's good news - I intend to start looking at Python 3.14 sooner than later. Mostly because Python build stuff is still fresh in my mind.

[colincornaby]

I received an email update from Github. There will be a new macos-15-intel runner type.

Notably:

Notice of macOS x86_64 (Intel) architecture deprecation
Apple has discontinued support for the x86_64 (Intel) architecture going forward. GitHub will no longer support this architecture on macOS after the macOS 15 runner image is retired in Fall 2027. You should begin migrating your workloads to arm64-based (Apple Silicon) runners as soon as possible to prepare for this eventual deprecation.

Hopefully by Fall 2027 we are able to cross compile for Intel.

[dpogue]

We are currently using macos-15 (arm64) and macos-15-intel (x86_64) as our runners, as of #1798