# Dropping Intel Mac to Tier 2
**URL:** https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100
**Category:** Core Development
**Created:** [August 12, 2025, 11:01am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100 "2025-08-12T11:01:44Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@encukou](https://discuss.python.org/u/encukou)
#### Post date: [August 12, 2025, 11:01am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/1 "2025-08-12T11:01:44Z")
Hello,
As @webknjaz [reported](https://github.com/python/cpython/issues/137638), GitHub will be [dropping](https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down) their last Intel Mac image. Brownouts will begin September 1, so we need to make the job non-blocking by then.
Cirrus and Circle CI already dropped Intel Mac.
This means that we’ll likely need to move Intel Mac to Tier 2 in [PEP 11](https://peps.python.org/pep-0011/).
Another option would be to run the tests with Rosetta, but setting that up would probably be too much work for the benefit.
See [the issue](https://github.com/python/cpython/issues/137638) for more details.
What makes me a bit worried is that Tier 2 requires 2 core dev contacts. How many core devs still use an Intel Mac?
We do have buildbots, thanks to Matt Billenstein and @itamaro.
---
### Author:  [@da-woods](https://discuss.python.org/u/da-woods)
#### Post date: [August 12, 2025, 11:31am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/2 "2025-08-12T11:31:59Z")
I don’t have a stake in this (and I don’t own a Mac) but I wonder if “x64 Python running on ARM hardware on OSX with Rosetta” might actually be a more important platform than “x64 Python running on x64 on OSX”. Just because people will be using it to run outdated libraries. So the suggestion of using GitHub’s more recent images and Rosetta might not be terrible.
---
### Author:  [@webknjaz](https://discuss.python.org/u/webknjaz)
#### Post date: [August 12, 2025, 12:23pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/3 "2025-08-12T12:23:27Z")
I’m only worried that native vs. virtualized macOS envs might have different surrounding ecosystems.
Though, I see your point. Ever since macOS 12.3 dropped system-provided Python (2.7), the end-users always end up relying on CPython provided by non-Apple vendors. Be it [python.org](http://python.org), Homebrew, uv, or pyenv. So with this in mind, whatever the upstream Python decides would match whatever runtime the users will get.
I can imagine, however, that dropping x86\_64 may force certain frameworks to prolong having older CPythons in their text matrixes, past their respective upstream EOL dates.
Thinking of the real-world use-cases possibly connected to using x86\_64 Macs, one such case might be the Ansible ecosystem, where the community maintaining shareable automations might want to support managing older machines for longer, past their expiration date. Another use of the old Macs I can think of is dual-boot — Boot Camp only supports Intel hardware.
That said, if Rosetta2 provides a sufficiently equivalent environment (I don’t have any experience with it), that’s probably the way to go.
---
### Author:  [@colesbury](https://discuss.python.org/u/colesbury)
#### Post date: [August 12, 2025, 1:38pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/4 "2025-08-12T13:38:37Z")
I have an Intel mac. Tier 2 makes sense to me.
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [August 12, 2025, 1:40pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/5 "2025-08-12T13:40:29Z")
> [@webknjaz](#):
>
> I can imagine, however, that dropping x86\_64 may force certain frameworks to prolong having older CPythons in their text matrixes, past their respective upstream EOL dates.
Right now, we’re not considering dropping x86\_64 altogether, but dropping it from [tier 1 to tier 2](https://peps.python.org/pep-0011/#tier-1). It’s still supported.
This mainly affects how quickly we find errors in our CI:
- tier 1 is before merge in GitHub Actions during PR builds
- tier 2 is in buildbots after PR merge (and pre-merge during PR builds on request)
---
### Author:  [@barry](https://discuss.python.org/u/barry)
#### Post date: [August 12, 2025, 3:24pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/6 "2025-08-12T15:24:41Z")
> [@colesbury](#):
>
> I have an Intel mac. Tier 2 makes sense to me.
I also still have a 2018 Intel mac mini, but recently made the upgrade to an M4 because of the rumors (confirmed?) that macOS 26 will not support this machine. Dropping to Tier 2 makes sense to me too.
---
### Author:  [@ronaldoussoren](https://discuss.python.org/u/ronaldoussoren)
#### Post date: [August 12, 2025, 5:43pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/7 "2025-08-12T17:43:20Z")
I have an 2018 mini, and will keep that running for testing other projects anyway.
The more annoying cutoff will be when Apple stops shipping x86\_64 target support in their compilers and SDKs, although that might be years out at the moment (macOS 26 will be the last version that runs on some Intel Macs, macOS 28 will drop support for Rosetta\[1\])
Building/testing with Rossetta shouldn’t be too hard if Rossetta is installed in GitHub’s runners, but is more complexity that would need handholding at times. So +1 for dropping Intel macOS to tier 2.
* * *
1. except for some special cases that are not relevant for this discussion.
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [August 14, 2025, 10:30am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/8 "2025-08-14T10:30:15Z")
Anaconda is dropping Intel macOS tomorrow:
> Starting August 15, 2025, Anaconda will stop building new packages for Intel Mac computers (osx-64). This change affects users who are currently using Intel Mac packages, whether on actual Intel hardware or Apple Silicon Macs running in emulation mode.
> **[Intel Mac Package Support: End of an Era | Anaconda](https://www.anaconda.com/blog/intel-mac-package-support-deprecation)**
>
> Anaconda announcement of the deprecation of Intel Mac (osx-64) package builds, effective August 15, 2025.
---
### Author:  [@h-vetinari](https://discuss.python.org/u/h-vetinari)
#### Post date: [August 14, 2025, 11:50am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/10 "2025-08-14T11:50:53Z")
> [@hugovk](#):
>
> Anaconda is dropping Intel macOS tomorrow:
For completeness, conda-forge is still building for `osx-64` on macOS \>=10.13 at the moment. So far, we’ve been only [discussing](https://github.com/conda-forge/conda-forge.github.io/issues/2467) to bump the lower bound to 11.0, and I wouldn’t have expected an end of us building `osx-64` packages anytime soon, but if GHA / Azure Pipelines ends up dropping Intel Mac agents, we may be forced to.
Ironically, there are still no native `osx-arm64` runners, though they’re [scheduled](https://learn.microsoft.com/en-us/azure/devops/release-notes/features-timeline#azure-devops-services) for this Q3 apparently. It looks like it’ll be a very thin window to change our infrastructure over from `osx-64` to `osx-arm64` runners. In principle, we should be able to cross-compile `osx-arm64` from `osx-64`, just as we’ve been doing it the other way around for several years now since the first M1. I’m pretty sure this will be attempted; whether we keep `osx-64` will depend on how much friction that change causes, and whether people put up with the required effort to keep it going or not.
---
### Author:  [@gpshead](https://discuss.python.org/u/gpshead)
#### Post date: [August 15, 2025, 10:03pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/11 "2025-08-15T22:03:45Z")
[Demote macOS x86\_64 to tier 2 by gpshead · Pull Request #4548 · python/peps · GitHub](https://github.com/python/peps/pull/4548) proposed to demote it to tier 2.
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [August 20, 2025, 12:52pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/12 "2025-08-20T12:52:07Z")
Update: the PR has been merged, and Intel macOS (aka `x86_64-apple-darwin`) is now tier 2:
> **[PEP 11 – CPython platform support | peps.python.org](https://peps.python.org/pep-0011/#tier-2)**
>
> This PEP documents how an operating system (platform) becomes supported in CPython, what platforms are currently supported, and documents past support.
We’re still testing `macos-13` on the CI, and I suggest we keep it there until GH pulls the plug (some time between 1st September and 14th November), as it’ll help us surface failures earlier.
But when it does go away, here’s a PR that’s ready to merge and minimise the disruption:
>
>
> GitHub Actions will be removing \`macos-13\` between September and November, and b…ecause that was the Intel runner (\`macos-14\` and \`macos-15\` are Apple Silicon), we've dropped Intel macOS (x86\_64-apple-darwin) to tier 2 support:
>
> \* https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100
> \* https://github.com/python/peps/pull/4548
> \* https://peps.python.org/pep-0011/#tier-2
>
> I suggest we keep testing on \`macos-13\` whilst it's available, as it'll help surface failures sooner.
>
> But because the removal window is quite long ("This process will begin September 1, 2025, and the image will be fully retired on November 14, 2025"), here's a PR. Whenever \`macos-13\` is actually removed, this should be ready to merge, and minimise the disruption.
>
>
> \* Issue: gh-137638
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [September 10, 2025, 10:05am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/13 "2025-09-10T10:05:44Z")
I see GitHub has updated the [announcement](https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down) to delay the removal by a month:
> The macOS 13 hosted runner image is closing down, following our [N-1 OS support policy](https://github.com/actions/runner-images?tab=readme-ov-file#software-and-image-support). This process will begin **October 1, 2025** , and the image will be fully retired on **December 4, 2025**. We recommend updating workflows to use `macos-14` or `macos-15`.
[Previously](https://web.archive.org/web/20250711170841/https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down) it was September 1 to November 4.
---
### Author:  [@h-vetinari](https://discuss.python.org/u/h-vetinari)
#### Post date: [September 10, 2025, 11:23am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/14 "2025-09-10T11:23:20Z")
It’s perhaps worth noting that while both GHA and Azure Pipelines use the images from [GitHub - actions/runner-images: GitHub Actions runner images](https://github.com/actions/runner-images/), Azure Pipelines has not yet announced any end of support `macos-15` for osx-64. Since conda-forge CI is mostly run on AZP, this is what we ended up doing.
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [September 10, 2025, 12:20pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/15 "2025-09-10T12:20:24Z")
> [@h-vetinari](#):
>
> Azure Pipelines has not yet announced any end of support `macos-15` for osx-64
`macos-15` is the new Sequoia image, do you mean `macos-13`?
Azure Pipelines [announced](https://devblogs.microsoft.com/devops/upcoming-updates-for-azure-pipelines-agents-images/#mac-os) end of support for `macos-13` on March 18th, 2025:
> ## mac-OS 13 Ventura
>
> In accordance with our policy to support the n-1 version of OS images, we will initiate the deprecation of macOS 13 Ventura starting 1st September 2025, with plans to retire it by 14th November 2025. Customers currently utilizing macOS-13 in their pipelines are encouraged to transition to macOS-14 or macOS-15 images.
>
> ### Key Dates:
>
> • **Deprecation Start Date** : 1st September 2025
> • **Full Retiral Date** : 14th November 2025
Note these are the same as the original GHA retirement dates, so I expect they’ll also be delayed a month to match.
---
### Author:  [@h-vetinari](https://discuss.python.org/u/h-vetinari)
#### Post date: [September 10, 2025, 12:48pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/16 "2025-09-10T12:48:32Z")
> [@hugovk](#):
>
> `macos-15` is the new Sequoia image, do you mean `macos-13`?
No, I meant `macos-15`. On azure pipelines, it is still capable of `osx-64`.
---
### Author:  [@oscarbenjamin](https://discuss.python.org/u/oscarbenjamin)
#### Post date: [October 2, 2025, 9:37pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/17 "2025-10-02T21:37:56Z")
> [@encukou](#):
>
> GitHub will be [dropping](https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down) their last Intel Mac image.
I got an email from GitHub about this today and it says that there is a new `macos-15-intel` runner that is supported for another 2 years (“until fall 2027”).
I just [tested](https://github.com/flintlib/python-flint/pull/332) it and it seems to work fine.
---
### Author:  [@webknjaz](https://discuss.python.org/u/webknjaz)
#### Post date: [October 2, 2025, 9:47pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/18 "2025-10-02T21:47:45Z")
+1 I was just about to post the same 😂
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [October 3, 2025, 6:09am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/19 "2025-10-03T06:09:23Z")
For reference: [GitHub Actions: macOS 13 runner image is closing down - GitHub Changelog](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/)
And we’re switching to `macos-15-intel` in [#139154](https://github.com/python/cpython/pull/139154).
We _could_ bump this back to tier 1, but we can also leave it at tier 2 to indicate it’s on the way out.
---
### Author:  [@webknjaz](https://discuss.python.org/u/webknjaz)
#### Post date: [October 3, 2025, 11:14am UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/20 "2025-10-03T11:14:03Z")
I think that tier 1 makes sense. Keeping tier 2 would encourage the ecosystem to do the same. The impact of this might be wide.
---
### Author:  [@hugovk](https://discuss.python.org/u/hugovk)
#### Post date: [October 3, 2025, 12:47pm UTC](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/21 "2025-10-03T12:47:37Z")
Tier 2 is still a high level of support: failures need fixing or reverting within 24 hours, and also block releases.
[Next page](https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100.md?page=2)