Xcode 14.3 Rosetta Simulators

[kaulex99]

New Issue Checklist

• Updated fastlane to the latest version
• I read the Contribution Guidelines
• I read docs.fastlane.tools
• I searched for existing GitHub issues

Issue Description

Xcode 14.3 partly dropped the Rosetta 2 support for Xcode (Release Notes). Nevertheless, there is still an option to run on Rosetta Simulators (See Tutorial). I tried to force the simulator with the devices parameter which does not work:

:lane test
     scan(scheme: scheme, devices: ["iPhone 14 Pro (Rosetta)"])
end

Command executed

fastlane test

OR

arch -x86_64 fastlane test

Both are not working.

Complete output when running fastlane, including the stack trace and command used

Runs normally, but on Apple Silicon and not on Rosetta

Environment

For legal reasons, I can not provide the environment here. If necessary I can set up an example project causing that error.

[fastlane-bot]

It seems like you have not included the output of fastlane env
To make it easier for us help you resolve this issue, please update the issue to include the output of fastlane env 👍

[imfractured]

also looking for a solution here, can't seem to find anything related with the xcodebuild command that allows us to determine the destination architecture of the simulator that is used when running build / test lanes. here is my fastlane env even though its not super relevant to the question :P

`swift-driver version: 1.75.2

✅ fastlane environment ✅

Stack

Key	Value
OS	13.3
Ruby	3.2.1
Bundler?	false
Git	git version 2.39.2 (Apple Git-143)
Installation Source	/opt/homebrew/lib/ruby/gems/3.2.0/bin/fastlane
Host	macOS 13.3 (22E252)
Ruby Lib Dir	/opt/homebrew/Cellar/ruby/3.2.1/lib
OpenSSL Version	OpenSSL 1.1.1t 7 Feb 2023
Is contained	false
Is homebrew	false
Is installed via Fabric.app	false
Xcode Path	/Applications/Xcode.app/Contents/Developer/
Xcode Version	14.3
Swift Version	5.8

System Locale

Variable	Value
LANG	en_CA.UTF-8	✅
LC_ALL
LANGUAGE

fastlane files:

No Fastfile found

No Appfile found

fastlane gems

Gem	Version	Update-Status
fastlane	2.212.1	✅ Up-To-Date

Loaded fastlane plugins:

No plugins Loaded

Loaded gems

Gem	Version
error_highlight	0.5.1
did_you_mean	1.6.3
syntax_suggest	1.0.2
atomos	0.1.3
rexml	3.2.5
CFPropertyList	3.0.6
claide	1.1.0
colored2	3.1.2
nanaimo	0.3.0
xcodeproj	1.22.0
rouge	2.0.7
xcpretty	0.3.0
terminal-notifier	2.0.0
unicode-display_width	1.8.0
terminal-table	1.8.0
plist	3.7.0
multipart-post	2.0.0
word_wrap	1.0.0
optparse	0.1.1
tty-screen	0.8.1
tty-cursor	0.7.1
tty-spinner	0.9.3
artifactory	3.0.15
babosa	1.0.4
colored	1.2
highline	2.0.3
commander	4.6.0
excon	0.99.0
faraday-em_http	1.0.0
faraday-em_synchrony	1.0.0
faraday-excon	1.1.0
faraday-httpclient	1.0.1
faraday-multipart	1.0.4
faraday-net_http	1.0.1
faraday-net_http_persistent	1.2.0
faraday-patron	1.0.0
faraday-rack	1.0.0
faraday-retry	1.0.3
ruby2_keywords	0.0.5
faraday	1.10.3
unf_ext	0.0.8.2
unf	0.1.4
domain_name	0.5.20190701
http-cookie	1.0.5
faraday-cookie_jar	0.0.7
faraday_middleware	1.2.0
fastimage	2.2.6
gh_inspector	1.1.3
json	2.6.3
mini_magick	4.12.0
naturally	2.2.1
rubyzip	2.3.2
security	0.1.3
xcpretty-travis-formatter	1.0.1
dotenv	2.8.1
simctl	1.6.10
jwt	2.7.0
uber	0.1.0
declarative	0.0.20
trailblazer-option	0.1.2
representable	3.2.0
retriable	3.1.2
mini_mime	1.1.2
httpclient	2.8.3
webrick	1.8.1
google-apis-core	0.11.0
google-apis-playcustomapp_v1	0.13.0
google-cloud-env	1.6.0
google-cloud-errors	1.3.1
google-cloud-core	1.6.0
google-apis-iamcredentials_v1	0.17.0
google-apis-storage_v1	0.19.0
rake	13.0.6
digest-crc	0.6.4
google-cloud-storage	1.44.0
emoji_regex	3.2.3
set	1.0.3
public_suffix	5.0.1
addressable	2.8.4
bundler	2.4.6
multi_json	1.15.0
signet	0.17.0
os	1.1.4
memoist	0.16.2
googleauth	1.5.1
google-apis-androidpublisher_v3	0.38.0
aws-eventstream	1.2.0
aws-sigv4	1.5.2
aws-partitions	1.746.0
jmespath	1.6.2
aws-sdk-core	3.171.0
aws-sdk-kms	1.63.0
aws-sdk-s3	1.120.1
forwardable	1.3.3
logger	1.5.3
pathname	0.2.1
shellwords	0.1.0
cgi	0.3.6
date	3.3.3
timeout	0.3.1
securerandom	0.2.2
uri	0.12.0
openssl	3.1.0
digest	3.1.1
ipaddr	1.2.5
resolv	0.2.2
time	0.2.1
stringio	3.0.4
open-uri	0.3.0
mutex_m	0.1.2
net-http	0.3.2
net-protocol	0.2.1
ostruct	0.5.5
english	0.7.2
erb	4.0.2
abbrev	0.1.1
tempfile	0.1.3
delegate	0.3.0
fileutils	1.7.0
tmpdir	0.1.3
base64	0.1.1
singleton	0.1.1
open3	0.1.2
nkf	0.1.2
racc	1.6.2
nokogiri	1.14.3
prettyprint	0.1.1
pp	0.4.0
find	0.1.1
yaml	0.2.1
psych	5.0.1

generated on: 2023-04-13

`

[elyahk]

The same issue happened to me as well, I couldn't build and run after updating Xcode14.3. All command mentioned above doesn't work for me as well. But when I build the project without Fastlane just using xcodebuild it is working perfectly. I hope the Fastlane team will resolve this issue soon.

[kaulex99]

@elyahk Are you using any special parameters for the command?

[elyahk]

@kaulex99 I am using this command: xcodebuild -workspace App.xcworkspace -scheme App -destination "platform=iOS Simulator,name=iPhone 13" build

[AlexandreHauber]

I am in the same boat.

[omerturhan]

Any update about this?

[Jride]

Experiencing the same issue in my team. We are using Bitrise as our CI provider and they are deprecating their intel based machines in favour of the M1's so I really need to find a solution quick.

@elyahk are you currently using this as a replacement for "run_tests" in your fastlane pipeline?

I am using this command: xcodebuild -workspace App.xcworkspace -scheme App -destination "platform=iOS Simulator,name=iPhone 13" build

[atmamont]

@Jride if the issue is fastlane then you can easily switch to the Bitrise "Xcode unit tests" step which just fires an xcodebuild cli
Try it first on your local machine? there is a chance the issue is not on the fastlane side and in general your builds are failing on m1

[bartlomiejswierad-vodeno]

@atmamont Our team has the problem with Bitrise too. The problem is not building on M1, but targeting arm64-simulator. The feature would help a lot.

[atmamont]

@bartlomiejswierad-vodeno good to know, but also you always have a fallback option no not use fastlane for tests targeting simulators, right?
all other builds should be fine I suppose?

[mattilindell]

react-native-community/cli#1934 reveals the necessary change, append arch=x86_64 to build with a Rosetta simulator.

e.g:
xcodebuild -workspace App.xcworkspace -scheme App -destination "platform=iOS Simulator,name=iPhone 13,arch=x86_64" build

[kaulex99]

@joshdholtz could you please assign this to someone 🙏🏻 this would be a pretty urgent change for us

[joshdholtz]

Looking into right now!

[joshdholtz]

@kaulex99 Can you run Etc.uname through irb for me like below and send me what it outputs for you? 😇 I don't know where my Intel MacBook is at the moment and can assume the value but I want to make sure 🤷‍♂️

[kaulex99]

@joshdholtz Have the same output as you on my MacBook M1. Just with :release=>"22.4.0". I assume you need someone with an Intel Mac to check that right?

[joshdholtz]

Ahhh yeah yeah! Need for intel 🤷‍♂️ I guess I could just SSH into a CircleCI job so I'll do that 😛

[joshdholtz]

✨ PR is ready for review and testing!

There is a new run_rosetta_simulator option on scan now 🤷‍♂️

Instructions for testing are in PR description 👉 #21284
If you are able to run this and let me know if this works for you that would be great!

[kaulex99]

@joshdholtz Can confirm it works like a charm! 🎉

[elyahk]

react-native-community/cli#1934 reveals the necessary change, append arch=x86_64 to build with a Rosetta simulator.

e.g: xcodebuild -workspace App.xcworkspace -scheme App -destination "platform=iOS Simulator,name=iPhone 13,arch=x86_64" build

@mattilindell It fix the issue, but it always chooses first random simulators, event though I explicitly said iPhone version, it chose random simulator

[nevil]

@elyahk

Yeah, I see the same with xcodebuild even though I specify the exact id of the destination...
So doesn't seem to be an issue with fastlane scan...

I have the below simulators:

		{ platform:iOS Simulator, id:909BB2A5-8565-4CD9-83D8-4EEE55265C00, OS:14.5, name:iPhone 12 }
		{ platform:iOS Simulator, id:F5E604EC-BDD1-4AF3-BC7A-46B62A758232, OS:15.5, name:iPhone 12 }
		{ platform:iOS Simulator, id:E7EF1AD3-7627-4B06-B530-E117BA672D95, OS:16.4, name:iPhone 12 }

Running as below will always select the first (14.5) destination:
xcodebuild test -destination 'id=E7EF1AD3-7627-4B06-B530-E117BA672D95,arch=x86_64'

But when I instead specify ARCHS it correctly selects the iOS 16.4 destination.
xcodebuild ARCHS=x86_64 test -destination 'id=E7EF1AD3-7627-4B06-B530-E117BA672D95'

Reported issue:
#21293

[martin-friedli]

Can anyone confirm that providing the architecture in the destination is required ?
Not providing the exact simulator name or simulator id causes Xcode to select the first simulator from the list of available simulators, as mentioned several times.

In my setup (forcing the architecture to x86_64 for the iOS simulator platform via build setting), I can simply provide the exact simulator name (e.g. "iPhone 14 Pro") as destination argument to xcodebuild and the tests build and execute successfully. In Xcode 14.3 the simulators show up with the Rosetta suffix in the name, like "iPhone 14 Pro (Rosetta)" and I can also execute the tests in Xcode.

Xcode 14.3 also is clever enough to show only the Rosetta iOS Simulators in the dropdown list as the standard arm64 Simulators cannot be used for my target with forced, exclusive x86_64 architecture.

So in short, xcodebuild of Xcode 14.3 selects the correct rosetta simulator automatically if the target architecture is set to x86_64.

[kaulex99]

@martin-friedli yes, but this does not apply for the CLI. Therefore, regardless of what I've set, fastlane scan command always used a non-Rosetta simulator.

[elyahk]

@martin-friedli Yes, as @kaulex99 said it works pretty well on local laptop, but CI, it is not, even though i installed local runner on my laptop it does not work properly.