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.

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

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)

NSApplicationDelegateAdaptor would be your starting point.

You need to add override init(window: NSWindow?) { super.init(window: window) } in your subclass. See https://docs.swift.org/swift-book/documentation/the-swift-programming-language/initialization/ which say: Rule 1 If your subclass doesn’t define any designated initializers, it automatically inherits all of its superclass designated initializers. Rule 2 If your subclass provides an implementation of all of its superclass designated initializers — either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition — then it automatically inherits all of the superclass convenience initializers. The (unstated) corollary here is that if you only override some of the superclass's designated initializers, you inherit none of them. in your case, you'd overridden init(coder:) not init(window:), so the compiler didn't 'see' an init(window:) at all. I'm not smart enough to figure this out on my own, I asked an LLM and then asked it to show me the documentation, because you really can't trust those guys. ;)

you said "selected it as a preview device" - what do you mean here? It sounds like you selected your model of phone for the simulator. In the middle top of the Xcode window, it shows your target name a run destination. By default, that run destination for an iOS app is a simulator. Plug in your phone. If it doesn't appear in the popup menu as a run destination, choose "Manage run destinations..." from that menu. It should show up as "discovered" in the list on the left of the Run Destinations window. The first time you pair the phone with Xcode takes quite a while (several minutes for me).

That sample doesn't quite work out of the box. Here is how you can get it to work on macOS 26 with Xcode 26 (and earlier versions of both, but that's what I'm using). Download the sample from https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app?. Follow only some of the directions under Configure the sample code project: (turn off SIP) - skip this, it is no longer necessary Set Automatically manage signing for both the driver and the app targets Select a development team. Xcode will tell you that you cannot select an individual for this type of signing. ignore the advice about "Sign to run locally" and AD_HOC_CODE_SIGNING_ALLOWED. ignore all the other stuff. You don't need to make profiles, add capabilities, manually download profiles or add them to Xcode. Now go the Build Settings for the driver and app target, and change the Product Bundle Identifier. The download project uses a disambiguation string that doesn't work, and you end up with very long bundle IDs which cause an error - see https://developer.apple.com/forums/thread/785223 I used com.shorty.dext-to-user-client-2-${DEVELOPMENT_TEAM}.driver for the driver and com.shorty.dext-to-user-client-2-${DEVELOPMENT_TEAM} for the app Then, to make running and debugging easier, you can alter the Scheme for the app. In Xcode, at the top of the window, click on your app target and select Edit Scheme. In the dialog, expose the Build scheme and select the Post Actions. Add a new Run Script phase with this content: ditto "${BUILT_PRODUCTS_DIR}/${FULL_PRODUCT_NAME}" "/Applications/${FULL_PRODUCT_NAME}" That will put your app into /Applications every time you build it. Build the app. Next, tell the debugger to run that copy and not the one in the Build Products folder. Expose the Run part of the scheme, click on the Run section, then in the Info tab you'll see a popup for the Executable: location. Click that, select other..., navigate to your app in /Applications. Everything else should Just Work. It is possible to develop dexts if you're not a member of a development team, but it is much more difficult.

you can see what iostat does by looking at its source code, which is here https://github.com/apple-oss-distributions/system_cmds/tree/main/iostat

https://developer.apple.com/programs/

I think the problem isn't so much the preset as the use of the AVExportSession itself, which can only accept presets. To get more control, you could use an AVAssetWriter. You can set it up with a preset to begin with, then alter some of the parameters.

Is com.apple.security.accessiblity a documented and valid entitlement? see https://developer.apple.com/forums/thread/799000

the source code of memory_pressure is here: https://github.com/apple-oss-distributions/system_cmds/blob/e0c267e80e451b9441ec4f4bb05dd72f0b49d596/memory_pressure/memory_pressure.c

Kevin, thanks for the suggestion. Unfortunately, it didn't work. I can put a different value for bInterfaceProtocol into the USB Device Info dictionary of the IOUSBMassStorageDriverNub, but that doesn't affect how the rest of the stack behaves. Whether I put 80 or 98 into bInterfaceProtocol, I always end up with a IOUSBMassStorageUASDriver attached to the IOUSBMassStorageDriverNub. I don't think modifying properties is going to work, unless there is some property I can add to the interface or the device that tells the stack "don't use alternate 1" or "always use alternate 0", which would require direct support from the USB stack.

You're in the wrong place to ask questions like these. support.apple.com would be more appropriate.

I tried making a codeless dext which matches to my IOUSBHostInterface. It has a plist that looks like this: CFBundleIdentifierKernel = com.apple.kpi.iokit // not sure if this is required IOClass = AppleUSBHostMergeProperties // uses IOProviderMergeProperties IOMatchCategory = $(PRODUCT_BUNDLE_IDENTIFIER) // makes its matching unique IOProviderClass = IOUSBHostInterface // what I want to match against IOUserClass = force_alt0 // not sure I need this, because we don't need a user-space process at all // required properties for matching to a IOUSBHostInterface, // see https://developer.apple.com/library/archive/qa/qa1076/_index.html idProduct = x // my product's usb product ID, as a Number idVendor = y // my product's usb vendor ID, as a Number bInterfaceNumber = 0 bConfigurationValue = 1 IOProviderMergeProperties = { bInterfaceProtocol = 80 // 0x50 sentinelProperty = "I am just a string" } I can see in the IORegistry that my sentinelProperty is applied to the interface, but bInterfaceProtocol is not. If I look at the IORegistry without my codeless dext, I see this hierarchy IOUSBInterface bInterfaceProtocol = 0x62 IOUSBMassStorageInterfaceNub, bInterfaceProtocol = 0x50 IOUSBMassStorageDriverNub, bInterfaceProtocol = 0x62 IOUSBMassStorageUASDriverNub, bInterfaceProtocol = 0x62 with my codeless dext, I see the same classes, with the same values of bInterfaceProtocol. I expect that tweaking the bInterfaceProtocol value on the IOUSBHostInterface at driver match time doesn't make any difference. Something in the USB stack that matches later, perhaps the IOUSBMassStorageDriverNub, is looking at the IOUSBHostInterface and making its own decision about what alternate interface to set, which causes IOUSBHostInterface to set its own bInterfaceProtocol property value. The value I designate in my IOProviderMergeProperties dictionary may well be briefly applied to the IOUSBHostInterface, but is later overwritten. Is there some other way to convince the OS to not use alternate interface 1?