See below for a scripted workaround.

Thanks for the test case :-) I filed also a feedback for this annoying bug (FB9494559).

Removed comment because Apple Forum is not able to show reasonably formatted comments... :-/ See my separate answer related to Xcode Playgrounds.

You are a lifesaver! Nevertheless I filed a feedback under FB9770204. This has to be fixed, it's unusable in this state.

What a pain... I wanted to give TDD another try and hit this VERY OLD issue. Its crazy that there are not more people complaining about it. Nobody is really doing TDD 😉

I suppose the affected project is the only one running on macOS. All others running in a simulator? I see the issue with failing unit tests on a macOS framework. The xcresult bundle is only a few kilobytes on success but is at least 60 megabytes when there was a failure. The reason is definitely the test-session-systemlogs-*.logarchive file in the result bundle. It contains data from all running processes of the machine.

It does not help on my macOS framework project. The delay persists! TDD becomes inefficient like this. It seems as if the diagnostic are still collected but not bundled.

Did you search for “Poster“ in activity monitor? Those processes are not „as active“ as the Springboard and diagosticd processes and therefore do not appear at the top of the process list when you sort by CPU%.

Just an additional note from me: Even though I can now see the watch, there is no reliable connection from Xcode to the watch. Some times I cannot deploy an app to the watch due to "Transport error". Sometimes the deployment works, but the debugger cannot attach... or while the app has started, suddenly the debugger disconnects. So far this is still a really unpleasant development journey...