Toggle to enable Driverkit Driver not appearing in App Settings in iPadOS

Has anyone seen this happen with their apps and if so,

I've actually only seen this happen in development and am disappointed to here it's happening in production.

what is the issue/workaround?

The workaround I've long suggested is to include a settings bundle in your app so that your app always has some kind of setting. As far as I've seen, the issue has always been tied to initial setting presentation, so forcing the system to "always" present settings for your app seems to prevent the problem.

Also, I have raised a feedback for the same here but there has been no reply.

What's the bug number?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@DTS Engineer Hi Kevin,

The workaround I've long suggested is to include a settings bundle in your app so that your app always has some kind of setting.

I have a Settings bundle included in my app already. Also, I believe this setting is provided by the OS itself and having a custom setting in my bundle is not going to help activate the driver. The issue is that the toggle does not appear suddenly in Settings for some users in some versions of iPadOS even in the presence of a Settings bundle and I am unable to figure out why.

What's the bug number?

FB24167071 (Toggle to enable Driverkit Driver not appearing in App Settings in iPadOS)

I have a Settings bundle included in my app already. Also, I believe this setting is provided by the OS itself, and having a custom setting in my bundle is not going to help activate the driver. The issue is that the toggle does not appear suddenly in Settings for some users in some versions of iPadOS, even in the presence of a Settings bundle, and I am unable to figure out why.

The issue I've seen in the past was tied to the initial build out of the settings screen, so including a settings bundle meant that the system always built the screen, which then included the DriverKit switch. That's not the situation in your case, but that's why I suggested it.

Moving to your bug:

FB24167071 (Toggle to enable Driverkit Driver not appearing in App Settings in iPadOS)

A few points here:

• In order to really investigate this, we'd need a sysdiagnose from a device experiencing the problem.

• There were several bugs that could cause this, which were fixed in early iPadOS 18 releases. They shouldn't be an issue on iPadOS 26 or the current/later releases of iPadOS 18, but they might be a problem if you have users on older versions of iPadOS.

• Going forward, OSSystemExtensionsWorkspace.systemExtensionsForApplicationWithBundleID will let you query the system to determine your app driver status. I don't know how it will behave and devices that are failing, but it would be a worthwhile data point to add into this, particularly if it returns that you don't have any DEXT. Unfortunately, several bugs mean that it isn't reliable before iPadOS 27.

• I looked up your app using the details in your bug and, while I didn't see any direct problem, I am concerned that your DEXT version number doesn't really comply with the kernel version criteria described here. I actually wrote up a test app to test how it's parsed and it does work; however, you're not really in compliance with the spec and it's possible there's a sanity check I've overlooked. I'm not sure there is any great fix for this (you can't just return to the normal format, as that would be "reducing" your version number), but at the very least you need to slow down your version growth.

Related to that last point, it looks to me like you may routinely be rebuilding your DEXT as part of your release process which, in my opinion, is a mistake. My recommendation is that you build your DEXT independent of your app project, include it as a "static" resource, and only update it when the DEXT actually changes.

Every time your DEXT version changes, the system is going to need to go through an update cycle, but that can be much trickier than it seems. The system can't replace your existing DEXT while hardware is attached, which means you can end up with very long delays before your new version actually installs. That’s fine if there are real differences between DEXT versions, but routine rebuilds mean you’re just generating "noise".

Beyond that, bugs are always possible. Last year, a fix to the network family broke binary compatibility, "locking" builds to that particular system version. That meant that:

1. Existing drivers worked on all existing systems but not that update.

2. Drivers built with that update’s SDK worked on THAT system update but not on any other update.

Neither of those choices is great but #1 is better than #2, particularly since fixing the issue meant #1 worked on the next system update and #2 started failing.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

In order to really investigate this, we'd need a sysdiagnose from a device experiencing the problem.

Sure, I'll make sure to get the sysdiagnose from the device if at all I can reproduce it.

Going forward, OSSystemExtensionsWorkspace.systemExtensionsForApplicationWithBundleID will let you query the system to determine your app driver status.

Thank you for pointing me to this. I'll check how this API behaves in older versions of iPadOS or probably wait till iPadOS 27 releases just for it to be reliable as you have said.

I looked up your app using the details in your bug and, while I didn't see any direct problem, I am concerned that your DEXT version number doesn't really comply with the kernel version criteria described here.

I checked the thread and this is my understanding. Currently, both my app and the driver follow this way of versioning:

CFBundleVersion - some value between 100-990 (build number)
CFBundleShortVersionString - 9.0.0 (The app/driver version)

Ideally, should the CFBundleVersion in my case be set to something like 9.0.0.100 then as per the compliance instead of just 100? I guess it works in my case as it will never be 5 digits but for future proofing, I should fix this to something like above.

My recommendation is that you build your DEXT independent of your app project, include it as a "static" resource, and only update it when the DEXT actually changes.

I'll make sure to version up and build the driver only when there is an actual change instead of every time.

Thanks, Abishek.

Sure, I'll make sure to get the sysdiagnose from the device if at all I can reproduce it.

I'd also pay attention to what system version it's happening on. iPadOS 26 and 27 are obviously our primary focus, so bugs on earlier systems are significantly harder to fix. I'd still like a sysdiagnose from older systems, but I don't know if a fix would be possible.

Ideally, should the CFBundleVersion in my case be set to something like 9.0.0.100 then as per the compliance instead of just 100?

That format is that ideal, however, "900" (or 900.x.x.x) is still "allowed". Of course, the problem here is that if you're increasing that number very quickly, you can:

I guess it works in my case as it will never be 5 digits but for future proofing, I should fix this to something like above.

...run out of space, at which things fall apart. That's another upside to using a "static" build.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware