An update on this: the APIs in question have been reinstated as of Xcode 16 beta 5. 🎉

I have just run into this issue while trying to switch our build infrastructure from Xcode 13 to 14. So that's one workaround for the minute: perform the build with Xcode 13. This is only officially supported on macOS 12 Monterey, though Xcode 13.4.1's command-line xcodebuild seems to run fine on macOS 13 Ventura as well. Another workaround I still need to try is whether it works to perform release builds without code signing in Xcode/xcodebuild, and then implement the codesigning myself using codesign. We're already having to implement custom scripts for notarisation and installer packaging anyway, so it's only a small step to bring the signing stage out of Xcode and into our own scripts.

None of the workarounds (get users to upgrade to Monterey, build the dext on Xcode 12, etc.) seemed particularly attractive or sustainable, so I've finally done a deep dive on this and figured out the problem. The change that introduces the crash is that starting with DriverKit 21, IOUserClient::ExternalMethod is annotated to run on a named dispatch queue rather than the default dispatch queue: QUEUENAME(IOUserClientQueueExternalMethod). According to the documentation, this queue is by default the dispatch queue, but I guess this association is only made in the DriverKit 21+ runtime, while macOS 11/DriverKit 20 doesn't have an entry for it in its dispatch queue name table by default. You can work around the issue quite easily by adding the entry yourself, using something like: IODispatchQueue* default_queue = nullptr; kern_return_t res = uc->CopyDispatchQueue(kIOServiceDefaultQueueName, &default_queue); if (res == KERN_SUCCESS && default_queue != nullptr) { res = uc->SetDispatchQueue(kIOUserClientQueueNameExternalMethod, default_queue); } OSSafeReleaseNULL(default_queue); This explicitly sets the kIOUserClientQueueNameExternalMethod queue to the object's default queue. You'll want to do this during init or Start of any user client subclass, and it's of course not needed if you're otherwise explicitly setting the external method queue; make sure to get the order right if you're changing the user client's default queue and want external methods to run on the same queue.

I can see no apparent change in the behaviour of the demo project (which I redownloaded in case it had changed) when using iOS/iPadOS 16 beta 3, Xcode 14 beta 3, and macOS 13 beta 3. Again, any servers that have started advertising show up on the client's video player's AirPlay target list, but selecting one just causes the activity spinner to appear and spin for a while. No video/audio played on the server, no tick next to the selected streaming target.

Update: I've now tested between the iPad Pro and an iPhone 8 both running iOS/iPadOS 16b2, using first the one and then the other as client, and I'm still not getting anywhere with the demo project.

In my experience, the turnaround time for these requests tends to be about 1-2 months. I don't have many data points, but anecdotally it seems to have moved closer to the 4-5 week end of the range this year. Note that you won't always receive an email notification, so I recommend checking the "Identifiers" section of the developer account Certificates, Identifiers & Profiles web interface every now and then. That's at https://developer.apple.com/account/resources/identifiers/list - open the App ID for your Dext and check under the "Additional Capabilities" tab. If the tab doesn't exist, you haven't been granted anything yet. Check that each of the entitlements has been granted for the platforms and deployment scenarios you're expecting, re-request anything missing, and specify the certificate types you're planning to use. In the past, I've seen many entitlements only be granted for development and App Store signing, not Developer ID, which can be a nasty surprise when you think you're about ready to ship your driver.

In case you haven't already done so by now, install the latest Drobo driver. (3.5.2 or newer)

Thanks for posting your solution, this solved my problem for signing the dext itself, and I've now refined this further:You don't need the workaround for the container app: you just need to create an App ID with the "system extension" capability, create a corresponding development profile in your developer account, import that onto your dev & test machines and then sign using that profile.You also don't need to use your Developer ID certificate for signing, the normal Apple Development (or legacy Mac Development) cert/key pair will do. The signing step can be added to the dext target as an Xcode "run script" build phase:if [ "$CONFIGURATION" == "Debug" ] ; then echo "Debug build, codesigning and injecting entitlements" signing_identity="Apple Development: YOURNAME (IDENTIFIER)" debug_entitlements_file_path="$SRCROOT/dext-code-path/your-dext.entitlements" codesign --verify --entitlements "$debug_entitlements_file_path" -f -s "$signing_identity" "$CODESIGNING_FOLDER_PATH" fiDon't forget to specify the entitlements file path as an input to the build step.