Enable -allowProvisioningUpdates for gym builds in Xcode 9 by default

[KrauseFx]

Fixes #9589

[sander-m]

Does this work in CI environments? I suspect that an Xcode user needs to be logged in for the signing process to work, since it creates and updates profiles in the dev portal automatically.

[KrauseFx]

Oh that's a great question. Actually, I don't know. Also, I don't know if this will fail the build in case the user isn't logged in. Maybe it requires some more testing, let me know if you hear/know anything :)

[sander-m]

From xcodebuild --help

-allowProvisioningUpdates  
Allow xcodebuild to communicate with the Apple Developer website. 
For automatically signed targets, xcodebuild will create and update profiles, app IDs, and certificates. 
For manually signed targets, xcodebuild will download missing or updated provisioning profiles.
Requires a developer account to have been added in Xcode's Accounts preference pane.

Requires a developer account to have been added in Xcode's Accounts preference pane
I wonder if this can be automated for CI purposes.

[KrauseFx]

Yeah, nice catch, thanks for posting this. Yeah, if there is a way to detect if the user is logged in Xcode, that would probably be enough. Are you interested in looking more into this and seeing if you can find a plist file or Keychain entry that's being added when you login, so we can query that?

[sander-m]

After adding my Apple ID to Xcode 9 for the first time, those entries were added to my Keychain:

Would it be sufficient to check for existence of com.apple.gs.xcode.auth.com.apple.account.AppleIDAuthentication.token using the security system tool? This would probably require the keychain to be unlocked, but seems to work:

security find-generic-password -s com.apple.gs.xcode.auth.com.apple.account.AppleIDAuthentication.token

This not a perfect check though, because after removing my Apple ID from Xcode again, those keychain entries still exist.

[KrauseFx]

Oh nice. Mh, so that's the password + email is stored, do you think we can find out the location of the plist files on where the account list is being stored?

[kdawgwilk]

But you can also sign in to Xcode multiple times so even an account exists that doesn't mean that it will have access to the correct dev team on Apple dev portal

[jonkan]

I'm a little worried that allowProvisioningUpdates would break our setup, i.e. losing control over what profile is used.

We have enterprise apps and use sigh to (re)generate a profile that gym picks up when exporting the ipa. And with Xcode 9 this now fails as others have reported in #9589, xcodebuild fails with a "No profiles for '<bundle-identifier>' were found".
Passing allowProvisioningUpdates does make it work, but doesn't result in the sigh-generated profile being used (even though it's specified in the export options plist generated by gym)!

However, as @threat70 mentioned in comment I also found that adding signingStyle manual to the export options plist file made xcodebuild use the correct profile and export successfully.

	<key>method</key>
	<string>enterprise</string>
	<key>provisioningProfiles</key>
	<dict>
		<key>bundle-identifier</key>
		<string>profile-name</string>
	</dict>
	<key>signingStyle</key>
	<string>manual</string>

According to xcodebuild -help, signingStyle defaults to automatic for apps that were automatically signed when archived (which is our case). I assume this is the reason xcodebuild seems to ignore the provisioningProfiles entry..

[Alexander-Ignition]

@jonkan, thank you very much
I had the same problem

[felipelmota]

Had the same issue for a week and this fix worked to me after update to Xcode 9. Worked like charm.

[TMUSJRad]

Is there a timeframe for when this will get merged? We have a build using fastlane and Xcode 9 and it is broken until this fix is in. Thanks!

For some reason, adding the export_xcargs: "-allowProvisioningUpdates" to the gym call does not add the flag to the xcodebuild command.

[AnisovAleksey]

@BCOVJRad I think need find reason why export_xcargs doesn't work, without specify -allowProvisioningUpdates always.

[robotive]

@KrauseFx I think this breaks Jenkins when using a non-Admin/Member Apple ID, which is what we use on our CI slaves. My understanding is that an Admin-role Apple ID is required for -allowProvisioningUpdates to properly work.

[ohayon]

Hey folks! I am going to close this PR because it looks like #10272 has been fixed by other changes 😄 🚀