Where do you even request the entitlement? Apple dev support sent me this link but I can't seem to find an actual link to send a request. https://developer.apple.com/documentation/driverkit/requesting_entitlements_for_driverkit_development That link leads to here: https://developer.apple.com/system-extensions/ but that web page doesn't have an obvious link to submit a request.

Have you gotten any answers on this? I want to use LibUSB for our device, but the more I'm looking around it looks like LibUSB might not work that well now on MacOSX 11 and up. Apple seems to be forcing developers to use DriverKit to access USB. The issue is getting the Entitlements for the driverkit. They are not very quick to give DriverKit entitlement even though they want us to move forward with using it. I read somewhere that if you unplug your device and plug it in again after your application is running it'll work since the OS is not holding on to the USB interface anymore. Give that a try.

You definitely need to have MacOS. You could technically run a MacOS on a VM on PC but that will definitely be a breach of the license agreement. I recommend just buying a Mac Mini. It's pretty reasonably priced and you could use it for development with XCode. You could get the model for 2020 for under $500 from various sellers.

Did you try stepping through the codes and see whether the structs got filled in when you called Json4Swift()? It seems like you might not be getting the data you need with: required init(from decoder: Decoder) throws {         let container = try decoder.container(keyedBy: CodingKeys.self)         household = try container.decode(Household.self, forKey: .household) You have the try function but no catch so if it fails you wouldn't have any idea. So maybe try stepping through that function and see whether your container and household are getting populated correctly.

I think you have to request it from Apple. There are other questions in the forum discussing this. Unfortunately, Apple has been very slow to respond to any requests. I think maybe it has to do with the new paradigm of not wanting developer to touch kext anymore. Maybe they are moving everything toward a higher level interface as they are doing now with USB devices via dext with DriverKit. Sadly, it's been extremely difficult so far for me to get answers on DriverKit ... https://developer.apple.com/forums/thread/69170

Have you heard anything back? Why is this forum so inactive ...

I also ran into the same problem so I gave up and just move my minimum target to 11 (Big Sur). I don't have the issues anymore but that doesn't fix your problem with trying to deploy to Catalina. It seems like Xcode 13 is focusing on newer OS versions. Even SwiftUI is deprecating a lot of functions that support 10.15. In fact, all the new functions are only for macOS 12 like .overlay and material background. Such a tough choice regarding having to support older OS since Apple breaks the backward compatibility so quickly so people have to move to the new version.

I started messing around with various things to see if there was anything I could do. Then I remembered reading about USB HID somewhere that when you send a command to set an Output Report, an Input Report is generated. You are supposed to acknowledge the Input report with a receipt. That makes me wonder whether my set command didn't finish the process because the generated input report wasn't received back. The custom device we have doesn't work like that since the USB HID reports are used more like a USB HID Feature Report rather than the proper device reports to pass back-and-forth communications. Since our custom device will never generate an input report when the output report is sent to it, I decided to pretend that everything is an input report so that it doesn't generate any response. I made one small change to the code and now it works. success = IOHIDDeviceSetReport(dev!, kIOHIDReportTypeInput, CFIndex(buffer[0]), bufferPointer, bufferLength). //a way to force no report generation At the end of the day, our custom USB HID device is not implementing the usage properly, but this is probably true for many micro-controller-based USB HID devices that people were implementing based on Jan Axelson's USB HID examples on PC decades ago.