gh-153631: Move to macos-26 runner for iOS

[freakboy3742]

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:

sudo pkill -f CoreSimulatorService; xcodebuild -showdestinations -scheme iOSTestbed -project cross-build/iOS-testbed.1783905783081/iOSTestbed.xcodeproj

(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:

sudo pkill -f CoreSimulatorService; xcrun simctl list devices; xcodebuild -showdestinations -scheme iOSTestbed -project cross-build/iOS-testbed.1783905783081/iOSTestbed.xcodeproj

• that is, explicitly call simctl before calling xcodebuild - it may take several seconds for simctl to respond, but when it does, both simctl, and then and xcodebuild, will return a full list of devices.

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.

• Issue: Move iOS CI runners off macos-14 image #153631