Reading Files from USB-C Storage on iOS Devices

We believe that MFi certification is not necessary for USB-C connections. Is this understanding correct?

Yes, that's correct. The system directly supports USB mass storage devices. The system will mount the volume and make it accessible through Files.app and APIs like UIDocumentPickerViewController.

Implementation Method We prefer not to use standard components like UIDocumentPickerViewController. Are there any methods to access the file system directly, or any other suitable approaches you can recommend?

No, not really. You can use our standard components to get access to a directory and then provide your own navigation UI, but the only mechanism that will get you that initial access in one of our controls. In addition, there is currently an issue with cross volume bookmarks (r.102995804) which prevents resolution from working across volume mounts, so you also can't (reliably) use a bookmark to preserve access like you could on the users local storage. As things now, there isn't a good way for an iOS app to preserve long term access to an external file system.

or any other suitable approaches you can recommend?

Anticipating the question, yes, it is technically possible to access a mass storage device through DriverKit. However, it would require enormous work and come with considerable downsides. In particular:

-Access to the device would be through "USBDriverKit" and a custom UserClient. That means the actual device communication would be handle through "raw" USB commands NOT through the systems SCSI implementation. You'd need to build your own SCSI AND file system implementation on "top" USBDriverKit, then handle routing data out to user space through your custom user client.

-The DEXT will prevent the mass storage layer from loading on this device, so all access will be restricted to "your" app. A USB DEXT and release it's access, so it might be possible to enable access again but the transition process would be cumbersome.

-DriverKit entitlements are tied to specific hardware, so the is only an option when the hardware involved is "yours".

Basically, it's possible in the technical sense but the work involved is so large that it's only really viable for very specific cases where the file system configuration is inherently extremely simple and the user has no reason to access the storage independently.

Similarly, I'd only even consider something like this for existing hardware with a VERY significant installed base. If you're building a new product, I think it would be FAR easier to use multiple LUNs, allowing the system to attach to the mass storage LUN and you DEXT to connect to a vendor specific LUN.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

If I‘m not out of turn, I have a related question that I just might be incorrectly categorizing.

Disclaimer: I am not a Developer. I am a Program Manager thats trying to assign a new dev team to tackle a similar problem space. Definitively, not a large user base, not for profit, but a very specific scientific need that requires uniformity/standardization. Think, like, a USB drive that needs to be loaded with a specific key, for things to boot and work. Maybe 1-2 total files at one time, and they change often.

The goal for us to be able to write a custom app, to download today’s files, 1-2 total, probably from something simple like Box.com through the API Examples. The App will only ever pull them down, and only keep the newest correct ones.

The user would need to be able to put a put a USB-C Drive into an iPad (Mini or pro), and copy those files to the drive. Then the drive goes where it goes, does what it does. :) Rinse. Repeat.

I’m not savvy on the meaning of DEXT and LUN, but given the circumstances/requirements, is that still the issue at hand? Is this something we can open a Enterprise Developer Ticket to get some hand holding, for?

Note: If we needed to specify a model of drive, we could stick to one for a while. We also understand we might need to do all the formatting outside of the device, limitations, etc. It’s just about getting a pair or three of files onto a normal flash drive, repeatable, with hopefully a clever and nice UX!

The goal for us to be able to write a custom app, to download today’s files, 1-2 total, probably from something simple like Box.com through the API Examples. The App will only ever pull them down, and only keep the newest correct ones.

As things stand today, you can't really do what you're describing, at least not in a really "automatic" way. You can:

• Use iPadOS to download the file and (ultimately) copy the data into place.

• Depending on the file system layout, you could also do validation to confirm you were putting the file in the right place, etc.

However, you will NOT be able to fully automate the full process of copying the data on to the target volume. The user would need to give you access to the location/filesystem using an API like UIDocumentPickerViewController. That's because the iOS bug I mentioned earlier (r.102995804) prevents bookmark from being resolved properly except during the initial mount (when they were created).

The user would need to be able to put a put a USB-C Drive into an iPad (Mini or pro), and copy those files to the drive. Then the drive goes where it goes, does what it does. :) Rinse. Repeat.

First off, please file a bug on this and post the bug number here once it's filed. As part of that bug, please include as much detail as you can about WHY you're trying to do this (not just "what" you're trying to do).

This is exactly the kind of work flow that the bug I referenced earlier prevents and documenting these issues is important to getting the issue fixed as quickly as possible.

I’m not savvy on the meaning of DEXT and LUN, but given the circumstances/requirements, is that still the issue at hand?

To be clear, trying to solve this sort of issue through DriverKit is not a REMOTELY practical solution, as would require multiple developers with VERY deep knowledge of VERY complex parts of the system (raw USB, SCSI communication, and file system implementation). There are a small number of developers who MIGHT be able to implement something like that, but that's ONLY because they HAPPENED to already have all of the required knowlege. For example, a hardware vendor might already have the driver knowledge because their accessory communication required a driver and the storage background because they'd implemented those layers on their accessory platform. However, even then it's not something I'd recommend.

My write up should be considered a warning, not a recommendation. A very "casual" review of DriverKit for iPadOS can make it seem like this is "doable" when the reality is that it would be EXTREMELY difficult to actually implement and that's what I want to warn against.

Is this something we can open a Enterprise Developer Ticket to get some hand holding, for?

No. The hardware approach isn't a viable option for you and it's well outside the sort of thing they could assist with. It might be worth escalating the bug above with them as well, but I think that's really the only way they could help with.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware