NSApplicationDelegateAdaptor would be your starting point.

I don't know if there's anything Electron-specific, but if your app has com.apple.developer.system-extension.install, you need a NSSystemExtensionUsageDescriptionKey or OSBundleUsageDescriptionKey (for DriverKit extensions). Your failure to launch may not be what you think it is. Your program may have some code which unconditionally registers your extension at launch time, and your lack of the required usage description causes the system to terminate your app very early in its life cycle. You may be able to see what is going on my monitoring the console log (filter on your app's bundle ID)

https://developer.apple.com/documentation/audiotoolbox/encoding-and-decoding-audio

Sorry about the delay, I didn't see your message on the day it was posted (that little bell icon doesn't do much). I figured out what I was doing wrong but hadn't got around to replying to my own post. I was using this initializer: @nonobjc public convenience init(formatDescription: CMFormatDescription, maxFrameDuration: CMTime, minFrameDuration: CMTime, validFrameDurations: [CMTime]?) In previous code, I'd created a format like this (pseudocode): CMIOExtensionStreamFormat(formatDescription: description, maxFrameDuration: 30 fps, minFrameDuration: 30 fps, validFrameDurations: nil) which seemed to work fine - my virtual camera had a single format with 30fps. When I made a generator with multiple formats, I tried to add another format with a different frame rate like this: CMIOExtensionStreamFormat(formatDescription: description, maxFrameDuration: 29.97 fps, minFrameDuration: 29.97 fps, validFrameDurations: nil) and ended up with an AVCaptureDevice which offered two formats, both with the min and max frame duration of 30fps. That was the wrong thing to do. I only need a new CMIOExtensionStreamFormat only for a different size of output stream (all my streams use the same pixel format). Each size gets one format with multiple frame rates - pseudocode: CMIOExtensionStreamFormat(formatDescription: description, maxFrameDuration: 29.97 fps, minFrameDuration: 60 fps, validFrameDurations: [29.97fps, 30fps, 59.94fps, 60fps]) That works. Apple's built-in webcam on my laptop can provide arbitrary frame rates between 1 and 30 fps , while most UVC cameras only support a limited, fixed set of frame rates. With that mystery solved, my remaining question is how best to provide an actual frame rate which is closest to the promised value? Currently I do. this by counting frames since the start of generation and comparing setting a timer to fire at the anticipated time of the next frame (startTime + frameCount*frameDuration), rather than using a repeating timer.

have you checked the Privacy & Security section of System Settings? I haven't had this problem with installers, but I have seen app launches blocked here during development. In the normal flow, the user sees a dialog asking for permission, but under some circumstances that dialog won't appear - but the permission is still requested, it is just lurking unseen in System Settings. You could also request the detailed notarization log from the server, which tells you more than the mere result of the command. spctl tells you what you already know - that the packet is rejected on your machine. Check the system log to see if there are any further details on the reasons why. I usually dump the last minute into an archive and search that - log --last 1m , because working with the active log is frustrating, it is populated very quickly.

The plist you posted looks strange - it has a mixture of entitlements (which go into a .entitlements file) and other properties which I'd expect to see in an Info.plist. I don't see your driver's personality anywhere, which is what the OS uses for driver matching. Take a look at /System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBSerial.dext/Info.plist for example.

Hi Kevin, thanks for this write-up, but I noticed you wrote this: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. "IOClass"-> This is the in-kernel class that your driver loads on top of. they're not both the same thing though. It is often difficult to tell what these should be from the documentation for DriverKit, because it concentrates on the user-side classes, trying mightily to pretend that the kernel side doesn't exist.

You've set IOProviderClass to IOUSBHostDevice, but your IOKitPersonality includes the interface number, which a device doesn't have. You probably want to match against the interface (set IOProviderClass to IOUSBHostInterface) If you really want to talk to the IOUSBHostDevice, not the IOUSBHostInterface, reduce your matching criteria to include only the items in this table: https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/USBBook/USBOverview/USBOverview.html#//apple_ref/doc/uid/TP40002644-BBIDGCHB The table is ancient, but still relevant. If you over-specify matching criteria, you won't match at all. You're right not to put an IOProbeScore in there. The matching process calculates an IOProbeScore (more criteria -> higher probe score). The system's driver is unlikely to be as specific as yours, so you will outmatch it anyway. The only reason to manually specify an IOProbeScore is to outmatch another driver which would otherwise have the same score based on its matching criteria. That is unlikely here. You asked about the difference between IOUSBHostDevice and IOUSBHostInterface. Start here: https://developer.apple.com/documentation/usbdriverkit If you match against the device, you can only send requests to the control pipe, and you prevent the OS from building any kernel abstractions which can talk to the interfaces, unless your driver makes that happen. If you need to operate on anything more than the control pipe, you're better off matching against the interface you need. This gives you access to CopyPipe. Once you have a pipe, you can send or receive data through that pipe.

I suggest you get in touch with the maintainer of the project you cite. I tried building it, but it went off into the weeds when trying to parse the USB descriptor of three different UVC cameras. Have you found the code which enables/disables the zoom control? That should give you some clue. You said "tt seems that the zoom control commands are not successfully sent or recognized by the camera" - which is it - sent, or recognized? Does your code send the command? How? (show code). Does the camera or the USB stack return an error, and if so, which error? You're not giving us much to go on here.

this forum is for questions related to developing software for Apple platforms. your question would be better asked at https://discussions.apple.com

CMVideoFormat... pertains to video. You're asking about photo (still) capture. See https://developer.apple.com/documentation/avfoundation/avcapturephotosettings

I think the short answer is no. Your peripheral isn't in charge of the connection, the central is. You can request, the central isn't obliged to accept your request. Remember your peripheral is not necessarily the only one the phone wants to maintain a connection with, and you're not in charge of everything going on in the central.