Repository navigation
gh-153631: Move to macos-26 runner for iOS - #153632
Merged
freakboy3742 merged 4 commits intoJul 13, 2026
Merged
freakboy3742 merged 4 commits into
freakboy3742 merged 4 commits into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
freakboy3742
marked this pull request as ready for review
July 13, 2026 08:38
freakboy3742
requested review from
AA-Turner,
JacobCoffee,
ezio-melotti,
hugovk,
itamaro and
webknjaz
as code owners
July 13, 2026 08:38
ned-deily
approved these changes
Jul 13, 2026
Copy link
Copy Markdown
|
Thanks @freakboy3742 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15. |
Sorry, something went wrong.
Copy link
Copy Markdown
|
Sorry, @freakboy3742, I could not cleanly backport this to 3.14 due to a conflict. cherry_picker 2dc1a91af801ea896e21f6c6e6cc41f57e8268d9 3.14 |
Sorry, something went wrong.
Copy link
Copy Markdown
|
GH-153673 is a backport of this pull request to the 3.15 branch. |
Sorry, something went wrong.
Copy link
Copy Markdown
|
Sorry, @freakboy3742, I could not cleanly backport this to 3.13 due to a conflict. cherry_picker 2dc1a91af801ea896e21f6c6e6cc41f57e8268d9 3.13 |
Sorry, something went wrong.
Copy link
Copy Markdown
|
GH-153674 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
Copy link
Copy Markdown
|
GH-153675 is a backport of this pull request to the 3.13 branch. |
Sorry, something went wrong.
freakboy3742
added a commit
that referenced
this pull request
Jul 13, 2026
) Switches iOS CI to use the macos-26 runner, and makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91) Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
hugovk
pushed a commit
that referenced
this pull request
Jul 14, 2026
) Switches iOS CI to use the macos-26 runner, and makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
freakboy3742
added a commit
that referenced
this pull request
Jul 14, 2026
…ld (GH-153632) (#153675) Makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this pull request
Oct 2, 2026
…ng build (pythonGH-153632) (python#153675) Makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this pull request
Oct 2, 2026
…ng build (pythonGH-153632) (python#153675) Makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this pull request
Oct 12, 2026
…ng build (pythonGH-153632) (python#153675) Makes a small change to the iOS build script to improve build stability. xcodebuild doesn't guarantee that the CoreSimulatorService is running before starting a simulator. If the service isn't running, xcodebuild reports that no simulators are available, and fails to start the test app. However, simctl blocks until the simulator is available, and simctl is used to evaluate the default simulator. So - the iOS build script now unconditionally determines the default simulator, even if a specific simulator is requested. (cherry picked from commit 2dc1a91)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
Assignees
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switches CI configuration to use macos-26 for iOS builds. macOS-14 is now in the deprecation window (with full deprecation by November); other Apple workflows are already on macOS-26.
This was previously proposed in #145099, but had to be rolled back due to a stability issue in the workflow. I've now identified the source of the stability problem.
The iOS simulator is managed by a daemon (CoreSimulatorService); and when the daemon is starting (or re-starting), xcodebuild will report that there are no simulators. It appears that Xcode doesn't block on the availability of CoreSimulatorService - it just returns an empty list if the service isn't running.
You can verify this manually by running python Platforms/Apple iOS ci --fast-ci to build the framework and create a testbed project; then run:
(substituting the testbed folder that was generated). In my testing (on an M5 MacBook), about 2 in 3 of those runs will fail, and only display the minimal iOS target list, not the full list of available devices.
However, if you run:
When running the Platforms/Apple script providing an explicit simulator, the first simulator call that is made is to xcodebuild with that specific simulator. However, if you fall back to the "default" behavior, the script calls simctl to determine the available simulators, which blocks until CoreSimulatorService is running.
As a side effect, it also means that the script is resilient to changes in simulator image. This will be a particular concern with the macOS-26 image, as Github has indicated that they're going to be more aggressive about updating the Xcode versions that are available, and more aggressive in pruning older versions. iOS 26.5 is the default today; it wasn't when the macOS-26 image was launched. Since there's no automated trigger for bumping Python's CI configuration, and there's a significant performance penalty to using a non-default simulator, using an automated discovery-based scheme seems prudent going forward.
I have now run the iOS CI step 15 times (on commit 078ed9a), and it has passed every time; see CI run history for details. Previously, it would always fail within at least 10 runs (see this comment)
I've also modified the testbed script to always determine the default simulator, even if that default isn't used; it's a cheap operation, but it should guarantee a simulator is available if someone does have an explicit simulator defined.