How to distribute a DriverKit extension to third parties developing on iOS

Question

Capsmaldon2 OP

Created May ’24

Replies 2

Boosts 0

Participants 2

Hello,

We're developing a framework that needs to talk to a camera on iOS. We've written a Driverkit Extension to enable this but we're having trouble working out how to distribute this to third parties.

We have to specify the application's bundle id in the driverkit's bundle ID. But as far as I can tell that means if there are multiple consumers, they each need their own specially built driverkit extension.

For MacOS, we can see an entitlement that allow any 'user client' to connect to our driverkit extension. But from what I can tell, that doesn't seem to be the same for iOS.

Am I missing something? Or is it expected that we should have to build a new driverkit extension with a different bundle ID for every app that every third party wants to develop?

Let me know if I'm missing too much context, thanks in advance!

Boost

Answer 1

ssmith_c OP

May ’24

There's com.apple.developer.driverkit.allow-third-party-userclients for iPadOS.

0

Answer 2

ssmith_c OP

May ’24

HI capsmaldon2. Sorry for the delay replying, the forum design change seems to have caused all my watched threads to be ignored, or comments don't cause a notification. Comments are not very useful, in my opinion, so here's another reply.

It sounds like you're making a camera extension and a support framework, for use by multiple third parties. As you say, on iOS there's a requirement that the bundle ID of the dext begin with the bundle ID of the enclosing app.

You asked

Am I missing something? Or is it expected that we should have to build a new driverkit extension with a different bundle ID for every app that every third party wants to develop?

I think the answer is "yes" - at least a new dext with a different bundle ID for every different app which installs that dext. Multiple apps can use the dext. I

I suggest that you configure your targets so that the differences are described in xcconfig files. This way, you only have one dext target and one framework target. Making individual per-customer targets is possible, but doesn't scale well.

When you're developing for in-house testing, use your default configuration, when you're building for distribution to your customers, use the other configuration. You can select another configuration with xcodebuild --configuration.

You make new configurations at the Project level, which is where you indicate on a per-target basis what config file is used for each configuration.

Does your dext match against different hardware for each customer? I foresee some possible conflicts if end users install multiple copies of your dext from different vendors.

0