Hi Kevin,
First, thank you for your patience on all of this.
It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now.
FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere "else".
That's the issue, though. I don't know EXACTLY why automatic codesigning is failing - at least with manual code signing I can look at what settings I am using and try something else. If I just press "automatic" and it doesn't work (it hasn't yet), there does not seem to be anything further I can do to affect the problem - I am just stuck.
Next:
First, I had changed the bundle ID of my dext to what it "should be", after learning that the bundle ID ought to be an extension of the "owning" application's bundle ID.
This is common practice and what Xcode does by default, but I don't believe the system actually requires it, as it needlessly restricts/complicates what's possible without any real benefit. It's been awhile since I've specifically tested this, but it's definitely possible to create an app that doesn't follow this requirement and I believe it will work fine.
Ok, that's helpful information.
Next:
What IS true:
That's how the provisioning profile (2) from the developer portal knows the bundle ID of the dext that your application wants to create a user client for. Having this more clearly documented would be helpful.
...is that the user client entitlement IS tied to a specific bundle ID.
Got it. That failed in the automatic process, though - it kept bringing in the old dext bundle ID, and it was only AFTER involving the Team Agent and registering a new dext bundle ID that I got the correct results (via manual code signing and ignoring automatic).
This next piece might be the a-ha moment we've been looking for:
...finally under Additional Entitlements there is a drop-box to select DriverKit and System Extension Template for Mac Dev ID profile / Mac Direct Dist Profile (yours may not be named this, but mine is).
This step is not necessary and will not exist for many developers. The UI above is the original process used to "attach" managed entitlements to specific bundle IDs and was actually replaced by the "Additional Capabilities" tab you used above. You do not need to do so and it's effect will either:
Neutral, as the system should be smart enough to compare the existing entitlement set (configured through "Identifiers-> Additional Capabilities") and ignore any duplicates.
Harmful, as it will allow you to add entitlements to the profile that aren't configured on the identifier. That will then cause problems later, particularly with automatic codesigning.
OH. Ok, since it was presented, and I only had that option or "default" (which implied to not provide ANY entitlement), I chose the option which looked like it would do something. Thank you for clarifying, and glad I was detailing every step for us to find this.
As for whether or not your own app needs an entitlement to communicate to your own dext:
This part is complicated as there are multiple, different, mechanisms at work. Starting with the DEXT side:
By default, the initial connection system only allows connection requests from processes that are signed by the same Team ID as the DEXT. The "allow any UserClient Access" entitlement overrides that behavior allowing the "request" from any process. If "your DEXT" only talks to "your app/processes", then you don't need any entitlement to allow.
I know I have particular use cases that others will not, and for the moment I'm just trying to establish the correct rules to develop and deploy, outside of the App Store, a dext, it's owning application, and supporting applications.
For this particular dext, I need to allow "any userclient" to connect. It looks like the reason my apps can connect without defining the "userclient access" entitlement is because they share the same TeamID as the dext.
I used the term "request" because the DEXT itself has complete, dynamic control (at runtime) of what it actually accepts connections from. Note that I really do mean "complete and dynamic". If you want to create a DEXT UserClient that only accepts every other request on Tuesdays, that is entirely possible. This is a complicated topic on it's own so if you want to discuss that, lets start a new thread on that subject.
No, I don't need a follow-up thread. This I understand, I have two kinds of user clients and can dynamically control whether a connection is established or not, I have that working already. This thread is just for what codesign/entitlements/notarization is needed to actually deploy a dext outside of the App Store.
I suspect your app isn't sandboxed.
It is sandboxed - I'm in fact having trouble with accessing a user preference file thanks to the sandboxing (and spaces in the directory names), but the connection to the dext has no issues. I think it's due to the above bullet point about the TeamIDs matching, then.
Re: multiple dexts - understood, glad to hear that "com.apple.developer.driverkit.userclient-access" entitlement is an array. Should I be creating that entry in App.entitlements as an array with a single string entry? I was creating it as a string with the bundleID of the dext when I was trying it.
Re: creating an installer package:
Attempt the installation.
If it fails, check its location and tell the user if they need to move the app.
Thank you - this is a cleaner solution that is already functioning, and avoids concerns about installer codesigning/notarization breaking the application's/dext's settings.
I understand the repeated statements that Xcode 16 automatic codesigning, archiving, notarization, and deployment should work - but they have not done so for me to date. I will give it yet another try, now that I know what steps are necessary to get a manual configuration working properly.
