Post

Replies

Boosts

Views

Activity

Detect if the current device supports DriverKit?
When we ship an iOS app with a DriverKit driver bundled, we'd like to be able to check if the device the app is running on is actually capable of installing & running DriverKit drivers. However I have yet to find a reliable way to achieve this. We want to know before the driver has even been enabled, as we want to direct the user to enable it in the app's settings. I have tried a few things to no avail, and lots of it has just been unmaintainable guesses at which device the app is running on, rather than checking directly if DriverKit is actually available. Is there any suggested way of achieving this? Thanks!
4
0
102
Jun ’25
Can't enable an iOS Driverkit driver when using an older app ID
Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.
3
0
149
Apr ’25