InsightSoftwareConsortium
Proposal for macOS Intel Support deprecation timeline in ITK 6 (Retained in ITK 5)
Proposal
Deprecate macOS Intel (x86_64) support in ITK 6, while maintaining it in ITK 5 as a long-term support (LTS) release. This aligns with Apple’s phased sunsetting of Intel Macs and industry-wide shifts toward Apple Silicon optimization.
Rationale
1. Apple’s Official Transition Timeline
- Apple completed its transition to Apple Silicon in June 2023 with the Intel Mac Pro’s discontinuation^4.
- macOS 17 (2026) is projected to be Apple Silicon–only, ending major OS updates for Intel Macs^2.
- Security updates for Intel Macs will continue until ~2027 for newer models (e.g., 2019 iMac, Mac Pro) but lack feature parity^2.
2. Third-Party Software Trends
- Major developers (e.g., Adobe, Microsoft) now prioritize Apple Silicon optimizations, with some dropping Intel support entirely^2.
- ARM64 macOS now dominates developer toolchains, with Xcode and CI/CD pipelines increasingly excluding Intel^5.
3. ITK Maintenance Burden
- Supporting legacy Intel macOS complicates builds, testing, and CI/CD for ARM64-specific optimizations.
- macOS Intel GitHub Action Runners (
macos-13) are slower than the ARM counterparts. - Deprecating Intel in ITK 6 allows focused resources on Apple Silicon performance.
Proposed Implementation
-
ITK 6:
- Remove Intel macOS from build matrices.
- Document deprecation in release notes, directing users to ITK 5 for legacy workflows.
-
ITK 5:
- Maintain Intel macOS support as an LTS branch until 2027 (aligned with Apple’s security update window).
- Backport critical fixes only.
Community Impact Considerations
- Affected Users: Researchers/clinicians relying on older Intel Macs for specialized hardware (e.g., GPUs, PCIe devices).
- Mitigation: Provide migration guides for Apple Silicon or Linux/Windows alternatives.
- Timeline: Target deprecation for ITK 6.0 (Q1 2026), coinciding with macOS 17’s expected release^3.
Supporting Data
| Key Fact | Source |
|---|---|
| macOS 17 (2026) likely Apple Silicon–only | ^2 |
| Final Intel Mac (Mac Pro) discontinued June 2023 | ^4 |
| Security updates until ~2027 for newer Intel Macs | ^2 |
| Average 2-year security update window post-OS EOL | ^2^5 |
Request for Feedback
Please share:
- Use cases requiring Intel macOS support beyond 2026.
- Concerns about legacy hardware/software dependencies.
- Preferences for LTS backport policies in ITK 5.
References inline via linked sources. Data current as of April 2025.
xref Discourse thread:
https://discourse.itk.org/t/proposal-to-deprecate-macos-intel-support-in-itk-6-retain-in-itk-5/7510
Big huge thumbs down from me.
Apple is infamous for dropping support for things quickly, it's not something we should aspire to follow IMNSHO.
ITK does not have much Apple-specific code, it's mostly cross-platform C++. I don't imagine there being many issues specific to the combination of macOS + Intel, especially since (presumably) macOS will be supported in general, and Intel will be supported in general.
Our customers tend to use their hardware for many many years. Our current oldest supported macOS is 10.13, and ITK master is working fine there today.
As a counter-proposal, I think it makes more sense to have a discussion about what minimum version of macOS ITK should support. The CPU architecture doesn't much matter with ITK being in C++, that's nicely abstracted by the compiler. For example, we've had discussions in the recent past about using std::filesystem; that would require upping our minimum macOS from 10.13 to 10.15, which I could get behind at this point. i.e. dropping old OSes to support new C++ is a more compelling argument that dropping a whole CPU architecture because 'others are doing it'.
As for CI, I already have macOS Intel bots submitting builds and tests, and can continue to do so. If GitHub drops macOS Intel, then finding issues only after merge the day after is not so bad.
I agree with @seanm it does seem a bit premature to drop intel support. However, if we are not able to build and run intel CI on GHA or Azure, then we can't really support them.
So, can the GHA arm Macs build and run intel ITK with rosetta with the allotted resources? If yes, we are capable of continued support if, no our support is subject to GHA/AZP still running intel systems.
I was surprised with the proposal to drop Intel Mac support, mostly because to keep supporting it does not really require any action in the near future. I don't have use cases for Intel Macs, so I don't care much about it. But having a wider platform support is generally better. So we should probably postpone this consideration for the time when there is some identifiable effort required to keep supporting Intel Macs.
Thanks for the elaborate proposal, Matt!
The good news: it appears that on GitHub Actions macos-14 is already amd64, as I understand from https://github.com/actions/runner-images/blob/0e37973a015a27a4a410a4ae37c0aa99bdd63ea8/README.md#available-images
However, on Azure Pipelines, macOS-14 is still Intel. Right? Looking at https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software which says:
macOS 14 Sonoma macOS-14
macOS-latestORmacOS-14Link
Which links to macos-14-Readme.md, not to macos-14-arm64-Readme.md! 🤷
Related issues:
- https://github.com/actions/runner-images/issues/8971
- https://github.com/actions/runner-images/issues/11834
I remember that there was some MacOS image generation that had "Large" variant with a different ISA (AMD64/ARM64) from regular variant. Maybe MacOS-14?
I remember that there was some MacOS image generation that had "Large" variant with a different ISA (AMD64/ARM64) from regular variant. Maybe
MacOS-14?
I think that's right, for Github Team / Enterprise subscribers. There are 'large' Intel-based runners for Mac OS 14 and 15. Free tier users only have the standard macos-13 runner.
However, if we are not able to build and run intel CI on GHA or Azure, then we can't really support them.
Thinking about it, that's a sad state of affairs when an open source project like ITK is so captured by the Microsoft juggernaut that, even when we have cdash and community CI submissions like mine, such a statement could be made. :(
I was surprised with the proposal to drop Intel Mac support, mostly because to keep supporting it does not really require any action in the near future. I don't have use cases for Intel Macs, so I don't care much about it. But having a wider platform support is generally better. So we should probably postpone this consideration for the time when there is some identifiable effort required to keep supporting Intel Macs.
There are still Intel mac users around me and I would also prefer to keep its support. However, we have already dropped support for remote modules due to maintenance issues in InsightSoftwareConsortium/ITKRemoteModuleBuildTestPackageAction#109. It would be great if those were also maintained... but having spent some time maintaining the remote module infrastructure, I understand the choice.
@seanm Do you use any of the itk python remote modules to have noticed there hasn’t been macOS x86_64 whls available? I haven’t seen any GitHub user reports about the drop of support for the following:
itk-elastix with ~11000 monthly downloads itk-ants with ~2200 monthly downloads
I have pretty much dropped macOS x86_64 support because starting with PyTorch 2.3.0 (released April 24th 2024) there are no more macOS x86_64 whls.
I just ran the following query on bigquery to see the SimpleITK PyPI downloads for a year in the past (starting today):
SELECT
details.system.name as system_name,
details.cpu as cpu,
REGEXP_EXTRACT(details.python, r"^([^\.]+\.[^\.]+)") as python_version,
country_code as country,
details.ci as ci,
COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -366 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
AND file.project = "simpleitk"
GROUP BY
system_name, cpu, python_version, country, ci
ORDER BY
download_count DESC
The numbers I see for Darwin are:
| x86_64 | arm64 | |
|---|---|---|
| Excluding CI | 16754 | 46253 |
| Including CI | 63427 | 71165 |
Not sure why so many CIs are intel.
Based on these numbers, we would like to keep the intel Mac platform support for a bit longer.
I did the same for ANTsPy:
arm64 CI: 2807 arm64 not CI: 4250
x86_64 CI: 196 x86_64 not CI: 1973
Our product DREAM3D depends on ITK and we still support macOS Intel since Apple still supports it. Our own policy is to keep supporting MacOS Intel as long as Apple keeps supporting it with security updates. Considering Apple usually goes back 2 major operating systems with their security system support if Apple releases MacOS 16 this fall (2025) and they keep on their pace of a major version each year you are looking at fall of 2027 into probably Q2 2028 when Apple drops Intel support.
I also undestand that if GitHub or Azure officially drops support for MacOS Intel then a lot of us are probably going to have to also drop support as we will no longer have any reasonable way to do CI builds.
And as far as build times go, at least for us, the Windows MSVC builds take the longest to run (longer than Intel MacOS Builds) so I would be suprised if the macOS builds are actually the slowest builds.
Thank you all for the thoughtful feedback and detailed input on this proposal. I genuinely appreciate the time everyone took to share their perspectives, usage data, and concerns. The community input has been invaluable in shaping our path forward.
Updated Decision
Based on the feedback received, Intel macOS support will be retained in both ITK 5 and ITK 6 until macos-13 GitHub Runners are no longer available. However, Intel macOS ITK Python packages for ITK 6 will not be generated due to the significant build time and resource constraints detailed below.
Related Issues Created
Several excellent points were raised that deserve dedicated discussion:
macOS Deployment Target: @seanm's suggestion about updating the minimum macOS version for better C++17 support (e.g., std::filesystem) is spot-on. I've created Issue #5369 to discuss updating ITK's minimum macOS deployment target to 10.15 (Catalina), which would enable full C++17 features while maintaining reasonable platform support.
Self-Hosted Runners: @seanm's point about community CI contributions having better visibility than dashboard builds is excellent. I've created Issue #5370 to document how to contribute self-hosted GitHub Action runners, which will have broader impact and better integration with our CI workflows.
Technical Considerations
GitHub Runner Limitations: While it may be theoretically possible to build Intel binaries on ARM GitHub runners using Rosetta, we already encounter limits on the number of available runners. This approach would effectively double our runner usage, creating resource constraints for the entire project.
Maintenance Burden: Supporting Intel macOS does add measurable maintenance overhead. Issues need resolution before releases, and platform-specific bugs can be time-consuming. For example, we recently encountered a segfault in remote modules that occurred exclusively on Intel macOS: https://github.com/InsightSoftwareConsortium/ITKBSplineGradient/actions/runs/13750040392/job/38449841245#step:14:327
Build Performance: Apple discontinued Intel Mac production years ago, and the processors are significantly underpowered for modern builds. ITK Python package builds on Intel macOS take literally a full day—many times longer than other platforms. This creates bottlenecks in our release pipeline and consumes disproportionate CI resources.
Acknowledgments
Special thanks to:
- @seanm for offering continued community CI support and the excellent suggestion about deployment targets
- @zivy for providing concrete SimpleITK download statistics showing continued Intel usage
- @cookpa for ANTsPy data and the practical timeline based on Apple's support windows
- @blowekamp for the pragmatic perspective on CI capabilities
- @dzenanz for the measured approach to timing this decision
- @SimonRit for highlighting the remote module maintenance challenges
- @jamesobutler for the real-world data on PyTorch's Intel deprecation impact
Your collective input has resulted in a much more balanced and informed decision. The community's commitment to supporting diverse use cases while being realistic about resource constraints is exactly what makes ITK strong.
macOS 17 (2026) is projected to be Apple Silicon–only, ending major OS updates for Intel Macs23.
[!NOTE]
What would have typically been called macOS 16 will now be called macOS 26 referring to the upcoming year. This is macOS Tahoe. The subsequent release which would have been called macOS 17 is now expected to be called macOS 27.
The version of macOS releasing in fall 2026 dropping intel support appears to no longer be a projection, but the stated plan. https://9to5mac.com/2025/06/09/apple-will-end-support-for-intel-macs/
During the Platforms State of the Union at WWDC, Apple just announced that macOS 26 Tahoe will be the last release of macOS that supports Intel. That means from next year, major new versions of Apple’s desktop operating system will only run on Apple Silicon Macs (that is, 2020 M1 models and newer).
Of course, Intel Macs will continue to get critical security updates for some time thereafter. But users should not expect to be able to update to get new features from macOS 27 onwards, as no Intel Mac will be supported on macOS 27.
@seanm @thewtex
Please see PR: #5497 which sets CMAKE_OSX_ARCHITECTURES=x86_64 on Mac-15, this enables cross compiling and testing with rosetta emulation for the intel architecture on the Mac arm hardware. This will enable easier support for intel past Github's drop of the Intel Mac-13 runners.
GitHub is retiring the macos-13 runner in December:
https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/
They will have a macos-15-intel image, but note:
Apple has discontinued support for the x86_64 (Intel) architecture. 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.
Apple has discontinued support for the x86_64 (Intel) architecture.
That's not even a true statement. Last week's macOS 26 still supports x86_64, and, if the pattern holds, there will be security updates for a couple of years more.
Anyway, just because github/microsoft does a thing, does not mean that ITK must do the same thing... :)
Sharing announcement from GitHub, new runner label, macos-15-intel, that replaces the current macos-13, and will be supported till 8/2027. Testing macOS+intel can continue by switching to this label.