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.