Technical Inquiry Regarding DriverKit USB Serial Communication Issues on iPadOS

App Stops Functioning After Repeated Builds When I first build and run the sample code without any modifications, it works as expected. However, after making changes and running the app repeatedly on the iPad, it eventually reaches a state where the app stops functioning completely — no logs are printed, and device communication fails.

So, my first and strongest recommendation is that you stop using the iPad and shift your development efforts entire to the mac, even if your final target is exclusively iPadOS. Particularly in early development, ALL iPadOS does is make EVERYTHING about DEXT development more difficult. More specifically:

• The build/test/debug cycle is slower.

• The lack of critical tools like IORegistryExplorer.app make it very difficult to determine exactly what's going on.

• The logging infrastructure is more cumbersome.

• Because of how "opaque" iPadOS is vs. macOS, fixing issues is unnecessarily cumbersome and complex.

Putting all of that another way:

1. A DEXT that is not fully functional an macOS will NOT work on iPadOS.

2. A DEXT that is fully functional on macOS will generally work fine on iPadOS.

3. Any time "saved" by "skipping" macOS is the VASTLY overwhelmed by the additional friction created by iPadOS.

...all of which means that it's much easier/faster to get a DEXT working on macOS, then move to iPadOS and fix any problems (assuming any occur) than it is to directly target iPadOS. I want to be clear that the issue created by #3 are not small. Indeed, your ENTIRE question here is almost certainly caused by development friction. Case in point:

...after making changes and running the app repeatedly on the iPad, it eventually reaches a state where the app stops functioning completely — no logs are printed, and device communication fails.

What could be causing this behavior?

My first guess would be that the support component in the kernel failed to unload cleanly (probably due to timing issues), which then caused the DEXT to fail to unload. This works:

Surprisingly, if I generate a new Bundle Identifier, the app functions normally again.

...because the bundle id is the core identifier the system uses to track objects. As far as the system is concerned, having a new bundle ID is the same as installing an entirely new driver.

This behavior is a little odd:

Reinstalling the app or rebooting the iPad does not resolve the issue. Even when I revert to the original, unmodified sample code, the problem persists.

...as I would have expected the reboot to clear the issue. Did you delete the broken app before rebooting? And/Or disable the DEXT?

If the app was still installed and/or the DEXT enabled, then I suspect what happened is the following:

1. The DEXT had an issue the prevented it from cleanly unloading. This would prevent it from unloading properly, which also means it could not removed.

2. The device is rebooted.

3. Your DEXT is specifically configured to match against the "generic" registry (not specific hardware)

I would like to ask:

Have similar cases been reported before?

DEXT/KEXT development is inherently somewhat "bespoke" (so almost every case is somewhat different) but in the general sense, yes, that you're seeing doesn't actually sound all that strange. Indeed, when do general KEXT development, the first step is always "get the thing to match and load properly" and the second is nearly always "get the darned thing to unload cleanly".

Currently, due to the issue above, I am unable to obtain a device instance at all. Even assuming this is resolved, I noticed that the sample code does not include any implementation or reference material for USB serial communication itself.

Keep in mind that the sample you're working with ("Communicating between a DriverKit extension and a client app") is, by design, not actually a "working" driver. It was built to demonstrate the IOUserClient architecture and was intentionally built "outside" any of the DEXT families or specific busses so that it could more easily be adapted to the other families. In particular, it matches against IOUserResources because that allows it to "always" run under all conditions, not because any DEXT would actually work that way.

Is there any official sample code or documentation available that demonstrates USB serial communication between an iPad and an external device using DriverKit?

First off, clarifying what this will actually require, USBSerialDriverKit is NOT available on iPadOS, so what you DEXT will actually need to do is:

1. Use the "base" USBDriverKit layer to directly open the USB interface and then directly exchange USB packets to transfer data.

2. Use an IOUserClient to transfer data with the user level app.

...with #1 being the most difficult of the two. Note that implementing #1 requires a detailed understanding of USB and the specific details of the hardware you interacting with.

Is there any official sample code

No, not really. The reality is that our kernel APIs have always been inconsistently documented and DriverKit itself is no exception. While it is obviously possible to create a working DEXT, that's largely because most developers interacting with it are actually "porting" existing IOKit drivers and/or already have an in depth understanding of IOKit. Indeed, largely gaps exist in the DriverKit documentation (for example, how DEXT matching dictionaries work) because DriverKit is actually modifying the existing IOKit matching dictionary and the documentation basically assumes the reader knows that (without actually saying so).

If this is your first time interacting with this part of the system, then there's some the guidance at the start of this post might be helpful, however, the reality is that simply is not a straightforward API to learn or work with.

1. Difficulty Debugging Due to Missing os_log Output

Assuming you're referring to redaction issues when using os_log or IOLog, then take a look at this forum thread for an overview of the issue and a code snippet that resolves it.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

One other suggestion on all this. If you're starting on macOS, the other approach here would be to actually start by using the IOUSBHost Framework (instead of a DEXT) to sort out the basic control/command process, then "porting" that code into a DEXT. The framework says it:

"Create host-mode user space drivers for USB devices."

...but that's a very wordy way of saying "lets an app directly talk to USB devices". The IOUSB Framework has the same API structure as USBDriverKit and IOKit, so it's relatively straightforward to translate the framework code you write into a DEXT. However, using the framework means:

• You're code is running in a standard app which you can directly debug. This also removes all DEXT loading issues/friction.

• Some of the code you'll be writing is code you'll end up writing anyway. For example, the IOKit code used to find the USB device you want to work with is exactly the same code you'd using on iPadOS to find and open your own user client. And, just like I discussed earlier, this code is MUCH easier to sort out and debug on macOS, so you'd probably hav written in there anyway.

• The kernel driver underneath the framework ensures "coherent" device interaction and state in a way that USBDriverKit does not. In concrete terms, if your app crashes while communicating, it's very likely that the kernel will close and reset the device such that it will work fine when you run your app again. A similar situation in a DEXT could require a device hotplug, a full power cycle of the machine, or even panic the kernel*.

*Yes, it is entirely possible for a DEXT to panic the kernel.

The larger point to understand here is that much of the work in this kind of development is about testing/experimenting to figure out what will actually work, not simply "writing the code that works". Because of that, you're often better off working with the system/API that's easiest/fastest to test and experiment in, not the system/API you're actually going to ship.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware