Seeing the same issue, in addition to seeing it on the first 3 navigators (⌘1-3). It didn't work like this in previous Xcode versions, as I often leave the dev doc window open in the background. Filed feedback FB8949830.
Post marked as Apple Recommended
Submitted bug report FB8710561 for this issue
Yes, the shutting down after multi-buffering is where I'm seeing the problem. This sample code is what I've been following for some of my implementation (https://developer.apple.com/library/archive/samplecode/AdoptingMetalII/Introduction/Intro.html), even though my implementation is more complex as depending on what I'm rendering, only some of the buffers are going to be in use, so their associated semaphores end up getting deallocated. I'm definitely open to a better solution to this semaphore problem if there's one that doesn't involve a workaround. Thanks!
In looking at this further, I realized that somehow a bridging header didn't get selected/added when I added this file into my Xcode project (which is otherwise all Swift code). If anyone else runs into a similar situation (but I think Xcode should prompt to add a bridging header when you add a .h file to an all-Swift project), I fixed this issue by going into the build settings in the Swift Compiler - General section and filling in the Objective-C bridging header value (which was previously empty) with the shader types .h filename (which is how it's set up in the Xcode Metal template also). So if your target is named MyApp, and your shader types file is named ShaderTypes.h, then the value in Objective-C bridging header would be MyApp/ShaderTypes.h. This assumes that the single shader types file is the only .h file in your project you need exposed to Swift - adjust accordingly if you need to expose multiple .h files to Swift.
