Fix simulator runtime OS version mapping for mismatched version strings by owurman · Pull Request #29737 · fastlane/fastlane

owurman · 2025-10-31T05:31:24Z

Checklist

I've run bundle exec rspec from the root directory to see all new and existing tests pass
I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)
I've read the Contribution Guidelines
I've updated the documentation if necessary.
I've added or updated relevant unit tests.

Motivation and Context

Fixes an issue where simulator runtime versions reported by xcrun simctl list devices section headers don't match the actual runtime versions, causing incorrect OS version detection.

This also likely fixes #29481 which seems similar if not identical to the issue I was having.

Description

When running xcrun simctl list devices, the section headers may show versions like "iOS 26.0", but the actual runtime version (as reported by xcrun simctl list -j runtimes) is "26.0.1". This mismatch causes fastlane to incorrectly identify simulator OS versions, which causes snapshot to fail.

Modified DeviceManager.simulators to query xcrun simctl list -j runtimes for accurate runtime version mapping
Added runtime_name_to_version method that creates a mapping from runtime names (e.g., "iOS 26.0") to actual versions (e.g., "26.0.1")
Updated device creation to use the actual runtime version instead of the section header version

Testing Steps

Added new test fixtures:
- DeviceManagerSimctlOutputWithVersionMismatch - simulated device list output with version mismatch
- XcrunSimctlListRuntimesOutputWithVersionMismatch - JSON runtime output showing actual versions
Added test case properly maps runtime names to actual versions for version mismatch fix that validates the mapping as a unit test
Added test case fixes iOS version mismatch by using actual runtime versions instead of section header versions that verifies devices get the correct OS version (26.0.1) instead of the section header version (26.0)
Existing tests continue to pass
My snapshot failure no longer fails (end-to-end verification)

🤖 Generated with Claude Code

markusfassbender-lb

Great fix! Thank you

piro49 · 2025-11-07T16:03:25Z

Looking forward for this fix!

owurman · 2025-11-07T16:19:33Z

All I need is an approval by a reviewer with write access ;-)

iBotPeaches · 2025-11-20T17:04:16Z

Taking a look. Mind rebasing so we can have a recent pipeline to see if green/red?

owurman · 2025-11-20T17:05:25Z

Can do! Stand by...

There is a bug where fastlane was using the inferred OS from the runtime name which wasn't always right. For example, OS 26.0.1 runtime was name "iOS 26.0". This was causing xcodebuild to use the wrong devices. This commit maps to the actual version number, falling back on the inferred one.

owurman · 2025-11-20T17:40:00Z

That fail looks potentially legit. I'm investigating.

owurman · 2025-11-20T17:56:53Z

The Ubuntu tests need a mock for xcrun with capture2. Working on it.

owurman · 2025-11-20T18:09:02Z

@iBotPeaches I'm getting bundler issues locally because it seems the latest Gemfile was created with bundler 2.5.23 and requires Ruby 3, and I'm still on 2.7.8. Before I go through the process, can you please confirm that fastlane now requires ruby 3 and I'm not misinterpretting the issue?

…2 for tests

iBotPeaches · 2025-11-20T18:38:47Z

@iBotPeaches I'm getting bundler issues locally because it seems the latest Gemfile was created with bundler 2.5.23 and requires Ruby 3, and I'm still on 2.7.8. Before I go through the process, can you please confirm that fastlane now requires ruby 3 and I'm not misinterpretting the issue?

Hmm guess I did on that CI fix bump to Bundler 2.5 (which is min 3.0). While I do have a goal to officially drop Ruby 2.x - that was not my intent on that PR. I'll see if I can quickly fix that (#29762), but to be blunt that is like 3 years old in terms of versions. It was getting extremely difficult to have a pipeline to work on Ruby 2.6 to Ruby 3.4.

owurman · 2025-11-20T18:40:36Z

It's fine, I'm not judging. I agree it's probably time to drop Ruby 2, I just wanted to make sure we were on the same page before I did that.

owurman · 2025-11-20T19:03:49Z

@iBotPeaches FWIW, the tests for this stuff are a bit of a mess. They are mocking stuff that gets cached and leaks into other tests. I'm trying to clean that up too, rather than leave it alone (even though that would be easier).

iBotPeaches · 2025-11-20T20:25:26Z

It's fine, I'm not judging. I agree it's probably time to drop Ruby 2, I just wanted to make sure we were on the same page before I did that.

thanks for this catch. Restored bundler 2.4 - 9338753

owurman · 2025-11-20T20:28:25Z

So there's a potential real issue here. My code assumed what appears to be Xcode 26 behavior, which is that dot-releases of SDKs do not co-exist. That is, downloading iOS 26.0.1 simulator removed iOS 26.0. That was likely not the case in the past, and one of the tests catches this situation where we (hypothetically, anyway) have both 17.0 and 17.0.1 simulators downloaded. The fact of the matter is that this code changes behavior, and could negatively affect someone still on an old version of Xcode or who otherwise has somehow downloaded coexisting dot releases of the simulators.

I'm trying to think of a solution which would maintain backwards compatibility.

iBotPeaches · 2025-11-20T20:39:00Z

I'm trying to think of a solution which would maintain backwards compatibility.

There are some helpful helpers for like xcode_version, etc. If you need to invoke different logic on Xcode 26+

… one runtime available per iOS (e.g. 17.0 and 17.0.1 both can exist)

owurman · 2025-11-20T22:00:06Z

I ended up changing my approach to not assume it was one os version per platform, and add all available simulators in that case. I think it will fix the original bug while maintaining backwards compatibility. I tested locally (I think: it's honestly hard to tell if I'm doing it right) and my original version-during-snapshot bug is still fixed, but the scan tests are passing now, too.

Let's see what CI does.

owurman · 2025-11-20T22:15:09Z

@iBotPeaches Looks good to go! I don't seem able to request reviewers, but please do.

iBotPeaches · 2025-11-20T22:22:05Z

cool! If anyone chimes in and it works for them, that helps me a lot. Don't do too much simulator stuff to confidently have a strong understanding of day to day usage.

owurman · 2025-11-20T22:30:59Z

I pinged the reporters in #29481 to take a look, @piro49 does this fix it for you?

owurman · 2025-11-25T16:18:12Z

@iBotPeaches I don't know if we're going to get any other reviewers on this, unfortunately...

piro49 · 2025-11-26T08:33:10Z

@owurman @iBotPeaches Sorry for the late response! I did run this PR testwise with Xcode 26.0.1 and simulator defined as "iPhone 17 Pro" instead of "iPhone 17 Pro (26.0)" and got this message again:

[17:28:20]: Ignoring 'iPhone 17 Pro', couldn't find matching simulator
[17:28:20]: Couldn't find any matching simulators for '["iPhone 17 Pro"]' - falling back to default simulator
[17:28:20]: Found simulator "iPhone 16 Pro (18.4)"

owurman · 2025-11-26T18:56:09Z

I'm not sure where default simulator comes from. When I ran snapshot with a simulator name that's missing, it just fails. Either way, this change was about allowing you to specify iOS 26.0.1 instead of 26.0. For example, in Snapfile:

devices([
"iPhone 17 Pro"
])
ios_version("26.0.1")

But you'd still need an iPhone 17 Pro simulator. Is yours perhaps literally named "iPhone 17 Pro (26.0)" with the iOS version in the name?

piro49 · 2025-11-27T10:57:08Z

Yes, that’s probably the case. I assume Fastlane uses whichever simulator it finds first. We have multiple versions of Xcode installed on our CI, along with the simulators that come with each version.
I’m running the run_tests lane with a specific simulator defined, as mentioned above. Previously, this wasn’t an issue. Specifying a simulator without an OS version used to work fine. Fastlane would simply select the latest OS available for that simulator.

owurman · 2026-02-05T19:50:09Z

@iBotPeaches I'm not sure what else to do here. There are tests to validate behavior that are passing. @piro49 seems to have a slightly different issue, but it's not related to selecting the right simulator from ios_version. I would suggest that perhaps this can get merged, and if it breaks others' implementations, we can back it out and investigate further. But without other users chiming in, we have only my own workflow to judge against.

iBotPeaches · 2026-03-16T13:18:27Z

Yeah tough for me as I don't have full confidence in any change as not a user of this. I merged a change yesterday I felt a bit safer with which might help here - #29894

github-actions Bot added the tool: fastlane_core label Oct 31, 2025

owurman mentioned this pull request Oct 31, 2025

snapshot unnecessarily falls back to iOS 18.3 #29481

Closed

4 tasks

markusfassbender-lb approved these changes Nov 7, 2025

View reviewed changes

owurman added 3 commits November 20, 2025 09:25

add tests

8527de8

robucop cleanup

8779ef2

owurman force-pushed the fix/simulator_runtime_os_version branch from ff9f709 to 8779ef2 Compare November 20, 2025 17:27

Fix device_manager cache clearing from simulators, mock Open3.capture…

31dc83d

…2 for tests

owurman added 2 commits November 20, 2025 11:09

clean up test set up and cache clearing

3948900

clear cache only before all (but keep mock setup before each)

d1e1332

github-actions Bot added the tool: scan label Nov 20, 2025

owurman added 2 commits November 20, 2025 13:52

Switch to a list of valid simulators instead of assuming there's only…

1d37dc4

… one runtime available per iOS (e.g. 17.0 and 17.0.1 both can exist)

Fix config stubbing for local testing of scan

c7a9ef9

Uh oh!

Conversation

owurman commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Motivation and Context

Description

Testing Steps

Uh oh!

markusfassbender-lb left a comment

Choose a reason for hiding this comment

Uh oh!

piro49 commented Nov 7, 2025

Uh oh!

owurman commented Nov 7, 2025

Uh oh!

iBotPeaches commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

iBotPeaches commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

iBotPeaches commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

iBotPeaches commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

iBotPeaches commented Nov 20, 2025

Uh oh!

owurman commented Nov 20, 2025

Uh oh!

owurman commented Nov 25, 2025

Uh oh!

piro49 commented Nov 26, 2025

Uh oh!

owurman commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

piro49 commented Nov 27, 2025

Uh oh!

owurman commented Feb 5, 2026

Uh oh!

iBotPeaches commented Mar 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

owurman commented Oct 31, 2025 •

edited

Loading

owurman commented Nov 26, 2025 •

edited

Loading