Here's the fail log of xcodebuild with -destination flag, and without sudo upfront: 15:39:45 Exit status of command 'set -o pipefail && xcodebuild -project "SampleApp.xcodeproj" -scheme "SampleApp" -configuration "Release" clean -destination "platform=iOS Simulator,name=iPhone 13 Pro,OS=15.4" -derivedDataPath "/path/to/.derived_data/sim_app" build | tee '/path/to/artifacts/logs/build_sim/xcodebuild.log' | xcpretty --color --simple' was 70 instead of 0. 15:39:45 2024-09-25 15:39:14.700 xcodebuild[91142:22610080] Malformed bundle does not contain an identifier at /Library/Developer/CoreSimulator/Volumes/tvOS_22J5335e/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS 18.0.simruntime 15:39:45 2024-09-25 15:39:14.760 xcodebuild[91142:22610212] Malformed bundle does not contain an identifier at /Library/Developer/CoreSimulator/Volumes/tvOS_22J5335e/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS 18.0.simruntime 15:39:45 2024-09-25 15:39:43.986 xcodebuild[91142:22610077] Writing error result bundle to /var/folders/t2/vppt8b613w1b1pwfycwzgnc00000gr/T/ResultBundle_2024-25-09_15-39-0043.xcresult 15:39:45 xcodebuild: error: Unable to find a device matching the provided destination specifier: 15:39:45 { platform:iOS Simulator, OS:15.4, name:iPhone 13 Pro } 15:39:45 15:39:45 The requested device could not be found because multiple devices matched the request. ( 15:39:45 "<DVTiPhoneSimulator: 0x12467d3e0> {\n\t\tSimDevice: iPhone 13 Pro (7C44F49C-1406-4675-8297-0BB1E32030A4, iOS 15.4, Shutdown)\n}", 15:39:45 "<DVTiPhoneSimulator: 0x1246788e0> {\n\t\tSimDevice: iPhone 13 Pro (723AB83F-84B2-4553-A7FB-FE97FBC72A12, iOS 15.4, Shutdown)\n}" 15:39:45 ) ... 15:39:45 Available destinations for the "SampleApp" scheme: 15:39:45 { platform:macOS, arch:arm64, variant:Designed for [iPad,iPhone], id:00006020-0014092C3498C01E, name:My Mac } 15:39:45 { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device } 15:39:45 { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device } 15:39:45 { platform:visionOS Simulator, variant:Designed for [iPad,iPhone], id:5E4672C1-BFDC-4BF8-AECC-9101CAF005E2, OS:2.0, name:Apple Vision Pro } 15:39:45 { platform:visionOS Simulator, variant:Designed for [iPad,iPhone], id:F828FD1C-C6A9-4671-8A30-45888FE542C2, OS:2.1, name:Apple Vision Pro } 15:39:45 { platform:iOS Simulator, id:27B137B4-DDF5-4091-A77B-AEAE819E60BE, OS:15.4, name:iPad (9th generation) } 15:39:45 { platform:iOS Simulator, id:27B137B4-DDF5-4091-A77B-AEAE819E60BE, OS:15.4, name:iPad (9th generation) } 15:39:45 { platform:iOS Simulator, id:84E80242-3066-45BB-BE4A-24EC1512BE0E, OS:15.4, name:iPad (9th generation) } 15:39:45 { platform:iOS Simulator, id:84E80242-3066-45BB-BE4A-24EC1512BE0E, OS:15.4, name:iPad (9th generation) } ... 15:39:45 { platform:iOS Simulator, id:723AB83F-84B2-4553-A7FB-FE97FBC72A12, OS:15.4, name:iPhone 13 Pro } 15:39:45 { platform:iOS Simulator, id:723AB83F-84B2-4553-A7FB-FE97FBC72A12, OS:15.4, name:iPhone 13 Pro } 15:39:45 { platform:iOS Simulator, id:7C44F49C-1406-4675-8297-0BB1E32030A4, OS:15.4, name:iPhone 13 Pro } 15:39:45 { platform:iOS Simulator, id:7C44F49C-1406-4675-8297-0BB1E32030A4, OS:15.4, name:iPhone 13 Pro } 15:39:45 { platform:iOS Simulator, id:AA3C6F9C-A503-4301-8C70-760D20F31103, OS:15.4, name:iPhone 13 Pro Max } 15:39:45 { platform:iOS Simulator, id:AA3C6F9C-A503-4301-8C70-760D20F31103, OS:15.4, name:iPhone 13 Pro Max } ... Why do the simulator devices show up doubled? I executed job only once but seems like CoreSimulator starts up twice. I know this occurs intermittently but the problem shows up too frequently.

== Devices == -- iOS 15.4 -- iPhone 13 Pro (F86F0DD7-8C70-48FE-BA9F-02CFCB5FE417) (Shutdown) iPhone 13 Pro Max (DD28B2D3-675C-4FAD-A5DD-F4A4BE45DAD0) (Shutdown) iPhone 13 mini (C1CCCE8D-7424-4FA2-B1F2-FBF9DBD1CA64) (Shutdown) iPhone 13 (B251760E-E6C0-4945-AEFD-365B10F74A68) (Shutdown) iPhone SE (3rd generation) (CCA0A16C-060F-44CF-8716-009026D0701C) (Shutdown) iPod touch (7th generation) (094749BD-20AA-4DFD-9762-9F38A32D1209) (Shutdown) iPad Pro (9.7-inch) (594577D4-B27F-401B-9ACF-9FD256B42D6F) (Shutdown) iPad (9th generation) (B9631ABA-A4B5-4526-B351-CE06C02A43A8) (Shutdown) iPad Pro (11-inch) (3rd generation) (4F5BA965-C4B1-4934-B134-04A7649D7BF4) (Shutdown) iPad Pro (12.9-inch) (5th generation) (35CA6F06-4194-4801-89B3-0DEF6C0A1F98) (Shutdown) iPad Air (5th generation) (52982B96-5E14-426A-96C0-0F90FC163EF8) (Shutdown) iPad mini (6th generation) (E7B3EE06-D2B2-45F2-8C4C-B0A5CCDEF771) (Shutdown) Adding information from xcrun simctl list on the same machine and this would show clearly that no duplications are seen.

Finally got how this crash can be reproduced. This is very specific with Xcode 16 betas, recurring on Apple Silicon mac mini/macbook pro 14'' Sonoma 14.5, with CrowdStrike Falcon Sensor 7.14.18305.0 running. If you run swift run -c release swiftformat ./ with all caches and build artifacts of Swift Package, the shell will crash with SIGKILL and send crash report to you local Console.app. So the solution will be: separating swift build and swift run. After that we never complain of swift run crashes.

FBA was torn down due to insufficient evidence; but finally picked off the culprit. xcrun simctl ran smoothly after I deleted /Library/Developer/PrivateFrameworks and re-run xcodebuild -runFirstLaunch without Xcode 16 beta. Seems something not going well on simdiskimaged of Xcode 16 beta. If you are installing and using multiple simulators via dmg images directly downloaded from Apple Developer, consider using additional components not from Xcode 16 beta.

I just realized that this behavior was not because of Xcode 16 but coming with Sonoma 14.5 in terms of Simulator-related process. When using iOS 17.x simulators for xctest, diskimagesiod process numbers up over 30 processes on Activity monitor(in memory section). I'll add this feature to existing FBA. Pretty disappointed in Sonoma, showing significant another right after solving external drive related one...

Note that this behavior is first time seen after installing Xcode 16 beta and additional simruntimes. Each machine has simruntimes listed below: iOS 15.4 iOS 16.4 iOS 17.0.1, 17.2, 17.4, 17.5 iOS 18 beta (new) tvOS 15.2 tvOS 16.4 tvOS 17.0, 17.2, 17.4, 17.5 tvOS 18 beta (new) watchOS 8.3 watchOS 9.4 watchOS 10.0, 10.2, 10.4, 10.5 watchOS 11 beta (new) xrOS 1.1, 1.2 xrOS 2 beta (new) Filed FBA https://feedbackassistant.apple.com/feedback/13893850 because spindumps were massive although I created only 3 files of spindumps(simdiskimaged, diskimagesiod, kernel_task).

You are asking me to leak my mac info which is a rent from company... If I can reproduce on my private mac, I will. *I'm checking if I can find out what happens when xcrun simctl hangs but it seems like something(not clear but seems like kernel_task) is blocking simctl process for no reason while it's frozen... top -l 1 | grep simctl (5s interval) shows simctl process is sleeping until the freezing resolved and command executed

$ plutil -convert json -o - /Applications/Xcode-beta.app/Contents/Info.plist | jq -r .LSMinimumSystemVersion 14.0 Yep. Apple Dev is deceiving us now. Now my team gotta update over 100 CI macs to Sonoma just to install Xcode 15.3 beta all of the sudden. Great.

I filed FB12403764 but they said it is 'Works as currently designed' with "Please know this is behaving correctly. Both Xcode14.1 and 14.2 are matched with the watchOS 20S71 simulator runtime." comment. For CI maintainers, this is quite an issue because it frequently fails the build with 'watchOS 9.1 simulator not installed' errors. (See what happened to Bazel CI in https://github.com/bazelbuild/continuous-integration/issues/1431) Issue related to this behavior has initially been publicized by Xcodereleases of which I was unnoticed. (https://github.com/xcodereleases/xcodereleases.com/issues/32) So if you still have 20S71 on your CI build machine macs, beware not to delete those, keep it with care for Xcode 14.2 builds. If the problem related to watchOS 9.1/tvOS 16.1 simulator persists, check xcrun simctl runtime match help to see how xcrun simctl runtime match set works. For details, check my gist. https://gist.github.com/dokimyj/9a77cca9fb627a0ae51264a1fe329733

Actually, you wouldn't need to download dmg files. Here is the thing you can do via command line while getting away from ginormous dmg file downloads: Open Terminal.app. Execute sudo xcode-select --switch /path/to/Xcode-beta.app Execute xcodebuild -runFirstLaunch. Execute xcodebuild -downloadAllPlatforms and wait till it shows Downloading visionOS 1.0 Simulator (21N5165g): Done. If Terminal/Xcode 15 beta requires Full Disk Access or Developer Tools authority, allow it. If you only need xrOS, fix the command in 3 for xcodebuild -downloadPlatform xrOS. (or any other than xrOS like: iOS, watchOS, tvOS) If the command gets stuck on Finding content..., stop the command with Ctrl+c and delete xcodebuild cache by sudo rm -rf ~/Library/Caches/com.apple.dt.Xcode.

Never mind. I found what happened. Using sudo occurred xcodebuild -downloadAllPlatforms hang problem. Removing sudo from the command solved the problem.

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.

This bug persists on MacOS Ventura 13.2.1 on mac mini late 2018 Intel i7 6core. $ /usr/libexec/ApplicationFirewall/socketfilterfw --listapps ALF: total number of apps = 5 1 : /System/Library/CoreServices/RemoteManagement/ARDAgent.app ( Allow incoming connections ) 2 : /opt/exporter_proxy/exporter_proxy ( Block incoming connections ) 3 : /opt/node_exporter/node_exporter ( Allow incoming connections ) 4 : /opt/script_exporter/script_exporter ( Block incoming connections ) 5 : /System/Library/CoreServices/ControlCenter.app ( Allow incoming connections ) $ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblock '/opt/exporter_proxy/exporter_proxy' The file path you specified does not exist $ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove " /opt/exporter_proxy/exporter_proxy" The file path you specified does not exist $ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblock "2 : /opt/exporter_proxy/exporter_proxy" The file path you specified does not exist $ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblock /opt/exporter_proxy/exporter_proxy The file path you specified does not exist

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.

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?)