watchOS 9.1 simulator unavailable despite of existence of runtime

Hi,

I am working for the iOS CI build environment dev/maint.

Since Xcode 14.2 has released, our CI users started claiming that their builds often fail because watchOS 9.1 simulators are not found.

ex1)

xcodebuild: error: Failed to build workspace YWeatherApp with scheme YWeatherApp.
	Reason: This scheme builds an embedded Apple Watch app. watchOS 9.1 must be installed in order to archive the scheme
	Recovery suggestion: watchOS 9.1 is not installed. To use with Xcode, first download and install the platform

ex2)

xcodebuild: error: Unable to find a destination matching the provided destination specifier:
		{ platform:watchOS Simulator, id:CF9011C4-9FD7-40F3-A2A9-46B8D593B2FD }

	Ineligible destinations for the "Swinject-watchOS" scheme:
		{ platform:watchOS, id:dvtdevice-DVTiOSDevicePlaceholder-watchos:placeholder, name:Any watchOS Device, error:watchOS 9.1 is not installed. To use with Xcode, first download and install the platform }

But when I execute simctl list command to see if there is watchOS 9.1 simruntime and simulator devices, sometimes it shows as available but sometimes it doesn't.

the result of xcrun simctl list when watchOS 9.1 simulators are unavailable

the result of xcrun simctl list when watchOS 9.1 simulators are available

Same machine (Mac mini Intel Late 2018), 30 minutes term between command executions.

What is weird when error: the runtime profile of watchOS 9.1 apparently exist at the top, but the devices of watchOS 9.1 shows on and off as available... and the reason of unavailability is: (unavailable, runtime profile not found).

What we do for Xcode 14.x installation with watchOS/tvOS simulators is: sudo xcodebuild -runFirstLaunch and sudo xcodebuild -downloadAllPlatforms after each installation of Xcode 14.x.

What we do after each build job ends is: pkill -9 Simulator, pkill update_dyld_sim_shared_cache, pkill -9 update_dyld_sim_shared_cache and launchctl remove com.apple.CoreSimulator.CoreSimulatorService if the simulator process still exists in ps aux list.

What I know now as Xcode 14 issue is what is written in the Xcode 14 Known issues for the simulator but Cleanse all simruntimes, Reboot mac and Reinstall the simulators to use could not be the answer this time because we are running over 60 macs in the system and there are 40 more macs incoming, avg 2000 builds per day.

Is there anything wrong what we are doing in the operations?

and would there be any alternative solutions or suggestions for this situation?

Thanks in advance.

Post not yet marked as solved Up vote post of dokimyj Down vote post of dokimyj
2.7k views
Posted by
dokimyj
Reply
Add a Comment

Replies

Hello,

We haven't been able to reproduce this issue on our side yet. Could you please reproduce and grab a sysdiagnose? Please submit the sysdiagnose via Feedback Assistant (https://developer.apple.com/bug-reporting/).

Also, what is the intent behind running the list of commands you mentioned above at the end of each build job? Killing CoreSimulatorService and the other processes should not be necessary and only make times when you want to use Simulator services take longer since we can't amortize the cost of caching costly information in the service. 

Could you check if you still run into this issue if you don't run those commands after the end of each build run?

Thanks

Posted by
Developer Tools Engineer
Post not yet marked as solved Up vote reply of Developer Tools Engineer Down vote reply of Developer Tools Engineer

  • https://feedbackassistant.apple.com/feedback/11968889

    I filed it right after you added this comment but never cared yet.

    You said I gotta stop killing the service after each job, but the behavior reproduced in 100% probability if so.

    Why we kill Simservice is because of the error below from the long past.

    CoreSimulator is attempting to unload a stale CoreSimulatorService job. Detected Xcode.app relocation or CoreSimulatorService version change.

    —
    dokimyj
Add a Comment

Thanks for the reply.

I tried stopping killing simulator jobs and services before starting the build, but it has got worse: failed on every build trial (where it fails was doing carthage bootstrap for Swinject-watchOS/tvOS).

18:55:30 $ carthage bootstrap --derived-data path/to/.derived_data --log-path path/to/logs/carthage.log
18:55:31 ▸ *** Checking out Swinject at "2.6.0"
18:55:31 ▸ *** Cloning Swinject
18:55:32 ▸ *** xcodebuild output can be found in path/to/logs/carthage.log
18:55:32 ▸ *** Skipped downloading Swinject binary due to the error:
18:55:32 ▸ "API rate limit exceeded for 211.14.8.247. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)"
18:55:44 ▸ *** Building scheme "Swinject-iOS" in Swinject.xcodeproj
18:56:14 ▸ *** Building scheme "Swinject-OSX" in Swinject.xcodeproj
18:56:33 ▸ *** Building scheme "Swinject-tvOS" in Swinject.xcodeproj
18:56:40 ▸ Could not find any available simulators for tvOS

I will report the bug with sysdiagnose (probably sysdiagnose.log only for reporting, right?)

Posted by
dokimyj
Up vote reply of dokimyj Down vote reply of dokimyj
Add a Comment

Having the same issue. Now I am not able to build anymore. The funny part is that my watch is on 9.3 and the Xcode build is failing as 9.1 files are missing. Tried reconnecting my iPhone and watch with the MacBook and with each other, quitting and reopening Xcode, restarting MacBook, clearing all derived data and DeviceSupport files, installing 9.1, etc, etc, etc. No progress for the last 2 days and It is not making any sense.

Posted by
BibinAlex
Up vote reply of BibinAlex Down vote reply of BibinAlex
Add a Comment

Fixed it by removing the duplicates.

Xcode>Settings>Platforms

I had a few duplicates. Removed the duplicates, installed watchOS 9.1 the platform again and it works

Posted by
BibinAlex
Post not yet marked as solved Up vote reply of BibinAlex Down vote reply of BibinAlex

  • Thanks for the solution. If this one persists without new patch from Apple official, I need to find out if I can do this via shell scripts...

    —
    dokimyj
Add a Comment

Updates on the problem(Already reported additionally on Feedback Assistant):

xcodebuild: error: Unable to find a destination matching the provided destination specifier:
		{ platform:watchOS Simulator, id:DAC71A8E-D8DC-4FC4-B67F-8462296F9F9E }

but Available destinations for the "Swinject-watchOS" scheme: has:

...
		{ platform:watchOS Simulator, id:DAC71A8E-D8DC-4FC4-B67F-8462296F9F9E, OS:9.1, name:Apple Watch Series 5 (40mm) }
...

so the solution BibinAlex and many others suggested would be the key... but what CI engineer gotta do is to make builds of users faster and stable.

Hope this puzzling mess cleared up soon.

Posted by
dokimyj
Up vote reply of dokimyj Down vote reply of dokimyj
Add a Comment

Hello dokimyj. Did you get a chance to submit the sysdiagnose via Feedback Assistant (https://developer.apple.com/bug-reporting/) yet? If yes, could you share the FB idea so we can review your logs to figure out what is happening here.

Posted by
Developer Tools Engineer
Up vote reply of Developer Tools Engineer Down vote reply of Developer Tools Engineer

  • https://feedbackassistant.apple.com/feedback/11968889

    I already filed a bug report over a month ago and nobody cared yet. I have another 'definitely suspicious behavior' on Ventura, also filed a report and no answers or feedbacks yet, these things really frustrate me a lot towards Apple.

    —
    dokimyj
Add a Comment

https://feedbackassistant.apple.com/feedback/11968889

My comments doesn't seem to be approved after submission. Here's my FBA with crashlogs, sysdiagnose. I filed it a while ago but never revised yet.

Posted by
dokimyj
Up vote reply of dokimyj Down vote reply of dokimyj
Add a Comment