iOS provisioning profiles and signing identities

Question

I am a bit lost in all the certificates/provisioning profiles.

When I am doing ad-hoc distribution by first doing "archive" and then "distribute" in XCode and chose then my ad-hoc distribution profile, does it matter at all what I have set up in the Project->Target->Build Settings->Code Signing?

On one hand I read in different places that when you archive a build, you can (and really should) use that same archive both for beta testing with ad-hoc and then when ready just sign/distribute the same archive with an appstore profile and upload to app store. That kind of makes sense. It also tells me that I can really leave blank the provisioning profile in the project settings, the one that is chosen during "distribute" action is actually used, and the signing identity is actually the private key associated with the distribution certificate listed in that provisioning profile. Right?

On the other hand, testflight instructions (http://help.testflightapp.com/customer/portal/articles/1333914) clearly state that project settings should be set to use Ad-hoc profile as well, and the same profile must be used in the project settings and in "distribute". That means that I can not use the same archive both for ad-hoc and app-store distribution, can I? Do I need to change project settings every time I want to release for this or that distribution?

Also, if project settings are making any differences in archive/distribute scenario, it is not clear what Code Signing Identity should be used there. Testflight screenshots show iOS Developer is set both for debug and release, yet neither ad-hoc nor app store distribution have the individual iOS developer certificate associated with them, distribution profiles usually are associated with one and one only distribution certificate.

Can someone please shed some light and explain how is it actually supposed to be working?

Thanks

Answer 1

Yes, your build settings matter. Xcode picks up various entitlements from your initial code signing/provisioning profile configuration and it only makes minimal changes to them in the Distribute... phase.

So if Xcode chooses the incorrect profile during the Archive step you can end up with incorrect bundle seed ID, keychain groups, APN environment and iCloud entitlements.

The Distribute... button calls the PackageApplication script, which makes sure that get-task-allow is false (debuggers can't connect), embeds a provisioning profile, then re-signs and zips your app (although I may have the order wrong).

PackageApplication is worth reading. One could fault it for not being very smart, but I think it should be stricter and refuse to package an app whose entitlements differ from the provisioning profile it is using.

You can find it here Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication

I think one stable workflow for distributing Ad Hoc builds is

1. remove all wildcard provisioning profiles from your system
2. select your App Store profile in Release Configuration (used in Archive phase)
3. in Distribute select your Ad Hoc profile

The reason for 1. is that wildcard profiles (profiles that match multiple BundleIDs, created either manually by you or automatically by Xcode) are not worth the trouble. Yes, they get you running code on a device quicker, but you soon have to abandon them if you want to use push notifications or any other interesting service and then they hang around on your system and sooner or later Xcode will silently pick one of them and sabotage your App Store submission.

As for point 2. (selecting the App Store provisioning profile), I'm a little hesitant of specifying profile in the project, but the App Store one only needs to change once a year when your certificate expires (unless you edit the App Identifier in the Certificates, Identifiers & Profiles portal, then you'll need to regenerate your profile & re-select it in your project settings). Since the Ad Hoc and App Store profiles are based on the same App Identifier, their entitlements will always be in sync.

Point 2. should make point 1. unnecessary, but wildcard profiles will also happily screw up your dev builds too, so why give them the chance to stab you in the back?

Point 3. - you can change your Ad Hoc profile as much as you like - just remember to select the right one in Distribute; the entitlements are taken from the App Store profile which should change rarely. There's nothing stopping you distributing to the App Store from here. That's perfectly natural.

p.s. I don't know why TestFlight recommend selecting Ad Hoc in release instead of App Store.