Kevin Elliot said By default, DEXTs are only allowed to connect to processes signed by the same team as the DEXT. No entitlement is required for this I have not found this to be the case, at least not for communication between my CMIO Extension and my dext. The Extension must be sandboxed, and UserClient Access is required to escape the sandbox. UserClient Access is managed, so it isn't available to me yet for my dext's bundle ID. For development, I use allow-any-userclient-access in the dext, but still have to use com.apple.security.temporary-exception.iokit-user-client-class in the extension to escape its mandatory sandbox.

you said "The issue was also submitted through Apple’s public macOS feedback form on 24 September 2026. That form confirmed receipt but did not provide an FB case number." The place to file bug reports is Feedback Assistant (the app), or you can use the web interface at https://feedbackassistant.apple.com

probably this: https://developer.apple.com/documentation/avfoundation/avcapturedevice/setexposuremodecustom(lensaperture:duration:iso:completionhandler:)

did you use Feedback Assistant to file a bug? This isn't a bug reporting forum.

The Elgato 4K X enumerates differently depending on the bus speed it is enumerated at. Its PID is different on USB 2, USB 3 Gen 1 (5Gbps) and USB 3 Gen 2 (10Gbps). One of the confounding variables here is that you're using a PCIe USB card in a Thunderbolt enclosure, and that card seems to be enumerating the 4K X at 5Gbps sometimes, and 10Gbps at other times. The first thing I'd try is a different (better) USB cable. This won't fix your original problem, but why do you care? You can synthesize your own persistent device identifiers. Undoubtedly, it would be convenient to have a uniqueID which is persistent and stable across topology changes, but you can create your own property and tack it onto your abstraction.

Please file a bug about this (mine, FB12782458, is two years old). In the meantime, you can synthesize your own persistent identifier which survives topology changes from vid, pid and serial number.

I think your summary is correct, aside from this part: "as long as only one of them is installed and operating at a time". That's up to you. You've written a driver, and the driver can elect to support only one client, or multiple clients. You can even get the com.apple.application-identifier from the client's entitlements dictionary, using CopyClientEntitlements in your user client's Start_Impl. The application-identifier is of the form ., so if you're called by a regular app, you can figure out which app it is and what team signed it. I've never tried more than one client. I assume that each user-space client's Open() causes a new call to your NewUserClient_Impl in your driver, and you can decide there whether to reject the call if you already have a client, replace the client, or make a new client.

The way this usually works is that you create a new dext target in your app project. Xcode then takes care of the build dependencies for you. In some senses, the easiest way to go forward is for you to make a new dext target in your existing app's project, then move your code files into that target. If you really need to maintain two separate projects, then I think you'll need to fall back on scripting to build the right targets.

Can you make installation of your iPadOS application a requirement for use of the driver? The delivery system for your dext would be your own app (which I think the user has to run once to install your driver). Once installed, any app can communicate with your driver if the driver has the com.apple.developer.driverkit.allow-third-party-userclients entitlement. Your app (or your customer's app) needs the com.apple.developer.driverkit.communicates-with-drivers entitlement.

For the first thing you're asking about, what gets called and how often, you can use Instruments. It regularly samples your app so you can see where it is spending its time. It does not record the back trace at every sample point though. To determine when particular routines are called, you can add signposts to your code. This can be more efficient than post-mortems of printf logs. Signposts can also be used to time methods. For "add "print break points" for logging without modifying code." you can add a breakpoint action which logs and automatically continues. You don't need to modify any code, and Xcode stores these breakpoints and their actions - you can even check them into source control if you want. Conditional breakpoints with actions aren't very quick though - they are faster than logging by hand, but they do affect the runtime of your program.

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.

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

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

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.

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.