Unfortunately it seems like there's a bug in the forums where I can't submit that JSON as a codeblock, apologies for the formatting
dharr
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
We're running into this as well, it's the main regression that's keeping us from updating. It takes about 10 minutes for xcodebuild for finish this step.
A spindump while this is beach balling is full of TargetDependencyResolver.discoverInfo(for:imposedParameters:)
This seems only to happen when using test or build-for-testing, builds or archives seem to be able to scale even with hundreds and hundreds of targets. As soon as we have more than a dozen or so test schemes, this slows to a crawl for us.
As far as testing goes, are you able to get a spindump? https://developer.apple.com/forums/thread/715929 could be related.
Still in RC2, haven't made any progress in determining what the root cause is
Negative, this happens on M1s, Intels, pretty much of any RAM size too.
Still present on Xcode 14.2. The Build Timeline shows this as "Preparing packages" because it doesn't actually seem to have a trace for the prebuild activities, there are no actual packages being prepared and the spindumps still show TargetResolver
Also running into this, I have a handful of other weird things too like when I go to uninstall listed runtimes I get:
❯ xcrun simctl runtime delete 21J353
An error was encountered processing the command (domain=com.apple.CoreSimulator.simdiskimaged.SimDiskImageError, code=18):
Cannot stage disk image or bundle for delete: 4A9A3A5B-03C2-4A4F-AF9B-A237B7A500BE
Underlying error (domain=NSCocoaErrorDomain, code=4):
“4A9A3A5B-03C2-4A4F-AF9B-A237B7A500BE.dmg” couldn’t be moved to “NSIRD_simdiskimaged_rClQ89” because either the former doesn’t exist, or the folder containing the latter doesn’t exist.
The file doesn’t exist.
Almost feels like my CoreSimulator directories got corrupted and now I can't recover.
Was this behavior ever modified? We have third party vendor frameworks that seem to rely on reading its own plist to determine the version, and unless this Xcode feature is disabled or fixed so it doesn't rewrite dynamic framework plists, the behavior of the framework turns incorrect.