Firstly, I realise that Kexts are deprecated. And for my needs, user-space IOKit from an application might be more than I’ll ever need, but I can’t help ensuring I’ve got all my ducks in a row while I’m designing an app.
I noticed in the above Kext deprecation notice that it’s more about specific APIs that are deprecated rather than the kext mechanism itself (no mention of IOKit kernel APIs there). Along with the fact that a reboot would be required and various other policy changes.
While reading up on System Extensions and the various newer tools, DriverKit, Endpoint Security etc, I’ve noticed there’s no mention of this “IOKit Driver” target/deliverable in the Xcode template chooser. It looks like, from the requirements, that DriverKit is aimed at hardware manufacturers, with a need to request the DriverKit entitlement for development.
With respect to Apple’s internal Kext deprecation roadmap, how safe is it to build a product that relies on using an IOKit Driver and are there any requirements similar to DriverKit? Would a developer need to request an entitlement?
If I developed an app using user-space IOKit and, for illustration purposes let’s say I also included an IOKit Driver in the app bundle. If I used the IOKit API, including header file constants only (no digging around in the IORegistryExplorer for non-public keys), as Apple intends them to be used, would this fall foul of any App Store rules that anyone is aware of?
Put another way, would making use of an IOKit Driver disqualify my app from being distributed via the App Store, similar to an Endpoint Security extension?
As an aside, there are a lot of API in the ES Framework that could be used to build apps that have nothing to do with Endpoint Security. File system related apps for example. It’s a shame there isn’t an enhanced middle ground between FSEvents and Endpoint Security framework.
You can’t distribute an I/O Kit driver on the App Store.
In terms of accessing I/O Kit via its user space API, that’s a complex question:
-
As far as the App Store is concerned, I’m not aware of any specific prohibition. However, I encourage you to review the App Review Guidelines yourself.
-
App store apps must be sandboxed, and the App Sandbox definitely imposes limits in this space. Some of these you can get around with hardware access entitlements.
-
There’s also the question of what’s supported. I see a lot of folks rummage around in the I/O Registry, find interesting stuff, use it, and then wonder why they’re app breaks a few years down the line. That’s not cool. In general, you should only rely on I/O Registry stuff for which there are symbolic constants in the SDK [1].
how safe is it to build a product that relies on using an IOKit Driver … ?
The answer to that depends on the specific I/O Kit family. Some families are completely supported by DriverKit. Some families have partial support. Some families have not yet seen any DriverKit action.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] If you’re building a custom driver, it’s fine to rely on your own stuff, of course.