"I would run this on a physical iOS 16 + device as stated in the project description." - Thanks; I did suspect that, which is why I also tried the Mac server on Ventura, with the same effect. (Although the IOServiceGetMatchingService call is only made on macOS as far as I can see, iOS uses UIDevice.current.identifierForVendor ?? UUID() which seems like it should work on iOS 15 as well. I'll try to identify another device we can safely move to iOS 16 beta and try again.

"A good description of these capabilities is found here in the DeviceDiscoveryExtension." - I did read that before posting, but it left me with some ambiguity. To be abundantly clear: if we want to enable owners of our device to stream to it, do we need to persuade the developer of every app they want to use it with need to embed our extension, or can we ship it in our app to provide the streaming target system wide? Obviously the demo project would answer that if I could get it to work…

I have now tried the demo project in a combination of an iPad Pro 11" 3rd gen and iPhone 8, both running iPadOS/iOS 16 beta 2, in both combinations of roles, as well as the iPhone 8 with the MacServer on macOS 13b2. All combinations fail in exactly the same way, the activity spinner just spins and spins and eventually disappears again; the tick never appears next to the selected server, and no video/audio is ever output on any server. It seems like this should work, so I have filed FB10511946.

With your question, are you implying we shouldn't be using Xcode/xcodebuild to perform release (Developer ID) code signing? What's the recommended way to do dext builds? I'm currently trying to update our release build infrastructure to use Xcode 14 and I'm running into the same issue as the original poster. Xcode 14 insists that dexts must be signed using a provisioning profile with its "platform" property set to "DriverKit," and there is no way to generate those for Developer ID signing.

It's definitely possible to work around this issue by selecting development signing in the dext target, and then in the app target, add a run script build phase which signs the embedded dext with Developer ID. Note you need to strip the signature off the dext's binary, and copy the developer ID provisioning profile as the embedded.provisionprofile before invoking the codesign command on the .dext bundle with the developer ID signing identity and entitlements file.

Xcode 15 doesn't fix the problem, but the workaround still works. It does some extra checking that the app and dext are signed using the same identity, so you have to make sure to do things in the order it wants. (A run script phase after the embed system extension phase in the app target still works for this purpose if the app itself is set to developer id signing.)

Thanks for confirming that this is indeed a bug and shouldn't happen. I'll prioritise non-UI work and stick with Xcode 15.2 for the moment, and see where we are towards the Xcode 16 GMs. I'm not sure WWDC2022/102 really tells me much about the Mac Catalyst SDK specifically? It says UIKit is here to stay, but these aren't UIKit APIs. SwiftUI sounds nice in theory, but its backwards and forwards compatibility story continues to be rather complicated as far as I can tell.

The APIs in question are back in Xcode 16b5, so thanks for whatever part you played in that!