External Accessory

We are listed for the MFI program as a licensed manufacturer. We have now started with the IAP3 sample code and the IAP chips to build up a USB communication between our accessory and an iOS device. We are looking for a sample project for the iOS part. Is there some available?

No, I'm afraid that's the only sample that's currently available. I'll also note that there are integration issues with the External Accessory framework and our modern APIs, even on iOS 18. If you want to run on a "broader" set of system versions, then I'm afraid my recommendation would be that you build on UIKit and the older app (NOT scene) lifecycle. If you want to use SwiftUI and/or the scene-based lifecycle, then you may need to require iOS 26.

Shifting to here:

And how does this relate to IOKit since it is available for serial communication on iOS16 as well?

Lots of clarifications here:

• On iPadOS, IOKit is specifically the user space API for DriverKit, not the more "general purpose" API it is on macOS.

• IOKit is really only available on iPadOS, NOT iOS. The framework does exist on iOS so that the same app can run on iOS and iPadOS, but it's effectively nonfunctional.

• On iPadOS, it is possible to create a DEXT that will enable communication with a given device, which does mean there is some (theoretical) overlap with what's possible using the ExternalAccessory framework. However, in practice, the two approaches have very different development processes and trade-offs.

Expanding on that last point, here is how I would summarize that split:

1. Using iAP3/ExternalAccessory lets you support the iPhone, not just the iPad. It also gives you access to the functionality of that protocol (for example, music library access) and integrated background support, none of which DriverKit provides.

2. DriverKit can provide FAR higher performance and bandwidth than ExternalAccessory; however, thinking of that in terms of simple performance is misleading. iAP3 provides a straightforward serial communication model, while DriverKit provides "full" access to the broader capabilities of USB/Thunderbolt. That means you’re basically comparing the performance of a basic serial protocol against what's possible with a bulk data transfer engine built on DMA.

3. Implementing a DEXT and its corresponding application is MUCH harder than using the ExternalAccessory framework.

In practice, that means there's a lot less overlap between these technologies than it might seem. More specifically:

• Most iAP3 accessories are special-purpose accessories, designed to use the protocol from the beginning.

• DriverKit is either used to support an existing accessory or because the nature of the accessory meant that iAP3 was never an option (required performance, integration into the system, etc.).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi, thanks for the clarification.

But this would mean we are not able to build an app that is based on SwiftUI and then deploy it for iOS 18 devices? For a medical product, this is not feasible. This would reduce the market to some few users. Is this meant serious?

Furthermore, the demo code from 2016 starts quite late in the process. I mean, we managed, after a nightmare of ordering procedure at Arrow, to get the MFI IAP chip samples and have this nice brief documentation of, like, 1200 pages. But what we are missing is somehow a step-by-step guide on how to build up a USB-C accessory.

When I ask the MFI support for code examples, they refer to the documentation and the developer support. But the documentation of the External Accessory Framework is also quite outdated.

And due to the license restrictions, it is nearly impossible to find coding examples at Stack Exchange or comparable sites.

For instance, I found the following code examples at Arrow: https://www.einfochips.com/blog/exploring-ios-external-accessory-framework-with-mfi-chips-a-developers-guide/

And here they write something about protocol string. Where do I get this string? Or how to do I get the UUID for my device.

Best regards,

Hi, thanks for the clarification. But this would mean we are not able to build an app that is based on SwiftUI and then deploy it for iOS 18 devices? For a medical product, this is not feasible. This would reduce the market to some few users. Is this meant serious?

If you're asking whether I would try to use SwiftUI with the ExternalAccessory framework, then my answer is "no".

When I ask the MFI support for code examples, they refer to the documentation and the developer support.

I think you asked them the wrong question. The External Accessory Framework is a public framework, which is why they sent you the information they did. However, that's not what you're actually trying to do. What you're trying to do is create an iAP2 accessory, which is exactly what the MFi program licenses and provides specifications for.

Unfortunately, that's all I can really say about this here. My recommendation is that you contact MFi support again asking for assistance with iAP2. You can also include the link to this forum post.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware