"How to" for dext distribution

SO, while looking into another issue (r.139973639), I did find an issue in Xcode 16 that might explain the issues you're seeing. Basically, Xcode 16 isn't properly handling situations where the same account has multiple approved version of the same entitlement.

In concrete terms, if you have these two entitlements approved on your account:

Entitlement A:
<key>com.apple.developer.driverkit.transport.usb</key>
<array>
	<dict>
		<key>idVendor</key>
		<integer>10</integer>
		
	</dict>
</array>


Entitlement B:
<key>com.apple.developer.driverkit.transport.usb</key>
<array>
	<dict>
		<key>idVendor</key>
		<integer>14</integer>
		
		<key>idProduct</key>
		<integer>6</integer>
	</dict>
</array>

...then automatic code signing always chooses "A", ignoring "B". In addition, the portal will allow you to enable "A" and "B" on the same bundle ID, even though this configuration doesn't work. If both are enabled, the the first will always be used (even with manual profile generation).

SO, here is what you need to do to address this:

1. On the portal side, configure whichever entitlement value you need and disable the others. You should only have ONE of any of these keys configured on any bundle ID.

2. Manually generate the provisioning profiles you need.

3. In Xcode 16 switch to manual code signing and sign with the profiles you generated.

Note that #1 is critical here. If you don't do one first, you'll end up generating a slightly different variation of the same failure.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I've been able to re-test all of these automatic codesigning/provisioning/notarization suggestions on Xcode 16.1, by modifying all of the bundle IDs, changing to "Automatically Manage Signing" and attempting again with my "Admin" developer portal credentials.

It does not work. I still get all 3 errors of:

• There is a problem with the request entity - you already have a current Developer ID Application Managed (With Kext) certificate or pending certificate request.
• No profiles for "com.company.HostingApp.Driver" were found - Xcode couldn't find any Developer ID provisioning profiles matching 'com.company.HostingApp.Driver'.
• No profiles for com.company.HostingApp" were found - Xcode couldn't find any Developer ID provisioning profiles matching 'com.company.HostingApp'.

It seems you are correct, the Admin level does not have authority to manipulate the developer portal side of the automatic process.

"Tightly controlled account access" does not really work in the modern world of two-factor authentication and remote development teams. The "Team Agent"/"Account Holder" is the CEO, typically - the only one empowered by the company to make legally binding agreements with Apple. The CEOs in most large organizations are not going to distribute their 2FA information to multiple developers just to get tasks like constructing App Identifiers done.

Yes, most companies use something of a "build machine" account that produces the corporate-signed software, however, that account is rarely, if ever, operated by the CEO either.

I understand that my complaint needs to be entered as a feature request, and I will enter a Feedback Assistant report to this effect.

In the meantime, however, the above set of instructions I provided has made it possible for me to complete the task of producing distributable dext software, so I will be marking that as the accepted solution.

Thank you!

So, I believe the "root" error here is this:

There is a problem with the request entity - you already have a current Developer ID Application Managed (With Kext) certificate or pending certificate request.

...which I think is caused by your machine not having a Developer ID certificate. Xcode tries to generate one and fails because, yes, that's restricted to the Team Agent. That is documented in "Roles and access", which I previously referenced.

The reason for that restriction is at least partially tied to this:

The "Team Agent"/"Account Holder" is the CEO, typically - the only one empowered by the company to make legally binding agreements with Apple.

Strictly speaking, the Developer ID certificate is the ONLY object required to sign and distribute software as "your company", hence the restrictive setting.

However, Admins can "Create cloud-managed Developer ID certificates", however, that access is restricted as a separate permission in " Granted as a separate permission in Users and Access".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Yes, I understand that Team Agent / Account Holder is the ONLY account with the authority to bless a computer with the ability to produce distributable software on behalf of the company. My point is that the automatic process is failing - whether that's by Apple's design due to security concerns and only the CEO can make dext IDs, or there's an issue occurring between my accounts, certificates, Xcode 16, and the developer portal, I do not know. I have the following certificates installed, full list for transparency:

• Apple Developer: myemail (My_non_corporate_team_ID), private key: MyName (MyName)
• Apple Developer: myemail (a_2nd_team_ID), private key: MyName (TeamName)
• Developer ID Application: TeamName (TeamID), private key: imported private key
• Developer ID Installer: Team Name (TeamID), private key: imported private key
• Apple Distribution: Team Name (Team ID)
• Apple Root CA
• Apple Worldwide Developer Relations Certification Authority (x2)
• Developer ID Certification Authority (x2)

The two Developer ID ones (Developer ID Application and Developer ID Installer) I have used successfully to produce distributable software from this computer. And, as noted earlier, if I perform all the manual confuguration and signings, I can produce dext software for distribution successfully, but as far as I can tell, we still can't perform automatic signing/provisioning/notarization which is what you are explaining should work.

I have confirmed that Team Agent/Account Holder has granted "cloud certificates" to my account - my apologies for not being able to locate the precise terminology for that, though. Looking at the list of certificates on the Developer portal, we have the following:

• My name, Development
• TeamName, Developer ID Installer
• TeamName, Devleoper ID Application (With Kext)
• TeamName, Distribution
• TeamName, Developer ID Application Managed (With Kext)(Xcode Cloud)

Development, and Distribution were created by me. Developer ID Application Managed (With Kext )(Xcode Cloud) was created by Xcode Cloud.

When I receive the errors from the attempt at automatic distribution, the first error explicitly reads (again):

• There is a problem with the request entity - you already have a current Developer ID Application Managed (With Kext) certificate, or pending certificate request.

Well, yes, we do appear to have one in our list of certificates. Should I delete it and try again? How would I check for a "pending certificate request"?

When the error is encountered, there is a "Show Logs" button, but I am not seeing much useful information that I am not currently conveying. Here is a snippet from the IDEDistributionProvisioning.log:

Should I open a code-level support incident for this so we can dig into the logs? The error information presented is not enough to help diagnose the problem that's happening here.

we still can't perform automatic signing/provisioning/notarization which is what you are explaining should work.

No, unfortunately, automatic will not work. I thought Xcode 16 had resolved all of the issues here, but it has not. My earlier forum post has the full details of the remaining issue.

This is the advice I gave in tha post:

1. On the portal side, configure whichever entitlement value you need and disable the others. You should only have ONE of any of these keys configured on any bundle ID.

2. Manually generate the provisioning profiles you need.

3. In Xcode 16 switch to manual code signing and sign with the profiles you generated.

A few notes on this:

• During profile generation, you pick the specific keys that will be associated with the profile you're generating, so make sure you pick what you want to.

• Different profiles will need to be generated for every build type you're going to use manual signing with. SO, for example, a development build can't be signed with a Developer ID cert. You should still be able to use automatic for development builds, but don't try and use your dev ID cert for development.

• When exporting builds from an archive, it can be very easy to pick the wrong profile and those issue can then cascade in ways that confuse the final result. For example, if you select an App Store profile for the main app, Xcode can then end complaining that the Developer ID profile is missing a required entitlement. That's technically true, but not really what the problem is.

• Xcode stores signing profiles in <home directory>/Library/MobileDevice/Provisioning Profiles/ and I'd actually recommend removing (back them up to another location and then delete them) everything from that directory. You should then generate a select new profiles for every component in the build.

In terms of this specific error:

"You already have a current Developer ID Application Managed (With Kext) certificate or a pending certificate request."

Quinn also suggested checking the entitlement using the approach described in this post.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware