DriverKit vs MFi for iPad custom hardware serial communication?

> I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

Depends on exactly what your needs are and the hardware you're working with. Starting with MFi, the biggest advantage is that the software side (ExternalAccessory framework) is far simpler to use and includes support for background access (DriverKit does not). The main downside is that it requires a certain amount of custom hardware and the certification process.

Comparing it with DriverKit is... complicated. The software side of DriverKit is FAR more complicated. To start with, the DriverKit API is a somewhat odd derivative of the IOKit kernel API. For someone who's familiar with IOKit, it's similar enough to be understandable, but for a new developer, the learning curve can be quite significant. None of this is helped by the fact that DriverKit is poorly documented[1], to the point that my standard advice to new developers is to study the IOKit kernel API (which has old, but FAR better documentation in the documentation archive) before you actually try and make sense of DriverKit.

On top of that, the actual implementation is inherently more complicated. On its own, a DEXT is an stand-alone system component that operates ENTIRELY independently of your app. That means you need to first implement the DEXT itself (which handles hardware-level communication), then implement a second communication layer so that your app can communicate with your DEXT. Last but not least, on iPadOS, you'll need to be using USBDriverKit family directly, which means you'll be building and sending raw USB commands, NOT a higher-level abstraction.

In terms of advantages, there are basically two:

1. In theory, it can work with basically "any" USB device. It won't necessarily be EASY, but with enough to work, you can talk to whatever you want.

2. It can be substantially faster than ExternalAccessory. The protocol ("iAP2") used by the ExternalAccessory was originally designed to run over a pure serial connection and simply wasn't designed with USB in mind. At the other end of the spectrum, DriverKit means that you have "full" access to the bus’s capability, not just in terms of raw bandwidth but also in terms of secondary technologies like DMA or isochronous transfer.

In terms of which path I'd recommend, my first question would be what kind of hardware volume you expect to do. It's not particularly well known, but there are hardware partners who both sell MFi licensed serial adaptors and will work with you to create more "customized" accessories that are fully licensed:

https://redpark.com/

(Note: This isn't a formal endorsement of Redpark, they just happen to be the only vendor I happen to remember)

If you're planning to produce these as a large-scale product then joining the MFi program would be the obvious progression from there, but working with a partner is generally a better option for anything smaller than that.

In terms of when you should use DriverKit, that's a trickier question. Most DriverKit projects are using DriverKit because it IS in fact the only option. For example, if you want to implement complex audio hardware, DriverKit IS the only option. Similarly, if you need to move 10s of MB/second, then ExternalAccessory will not work.

That leads me to the other, often overlooked option which is basically "do something else entirely". For example, most drones work by having the drone create a WiFi hotspot which the iOS device then joins. The most obvious reason for that is that the drone can't have a control wire; however, what's less obvious is that that WiFi link is in fact FASTER than ExternalAccessory would be.

In a similar vein, one approach that I'm surprised no one has used is to have the accessory present itself as a USB Ethernet adaptor and the accessory presenting itself as a standard network endpoint on that "private" network. Both of those require a bit more hardware to implement but are relatively straightforward to design and implement with high performance.

Returning to the original question here:

I want to communicate serially with an iPad. Should I use the DriverKit route or the MFi route?

I'll be honest, I have a very difficult time thinking of any case where I'd use DriverKit to implement vendor-specific communication on iPadOS.

[1] This fact isn't really obvious until you actually start trying to implement a real DEXT, which is in fact a big part of the problem.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

See my reply to this here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware