How should an organization with multiple iOS applications under development manage iOS distribution certificates?

Question

I've recently had some involvement with a group with an organizational account for iOS development.

They have multiple teams all developing separate iOS applications. I was somewhat surprised to learn that there is no coordination at all of use of the organization's "iOS distribution" certificates. Instead whichever developer needs to submit a build just creates a new one, revoking one or more existing ones if necessary (Apple appears to allow a limited supply of three of these to be "live" simultaneously). Justification for this practice seems to be a combination of the observations that:

• distribution certificates created by one developer aren't (easily) usable by another (you can find quite a few questions around SO on this topic; the solution appears to be to make sure the private key element of the certificate is also shared, but this organization has yet to take that on board. Example, another example; there are many more).
• xcode7 makes it easier than ever to churn distribution certificates, so it's clearly Apple's intended way (xcode6 would have needed a trip to the developer center).
• distribution certificates are only needed for the fairly small window of appstore submission; once the app is in the appstore it makes no difference whether the distribution certificate is revoked.
• Apple seem to have some slightly odd last-in-first-out rules around distribution certificate renewal (if you have "old", "newer" and "newest" and you revoke "newer" or "newest"... you'll find you still can't create a new one until you've revoked "old"). Or at least those rules appear odd to an organization which would have liked to divide up the limited stock of distribution certificates between various teams/projects, but found that didn't fit what Apple actually provide.

However, I observe a very serious negative consequence of this policy of rapid distribution certificate churn is that testflight builds don't stay valid for very long at all and tesflight users find themselves getting dialogs about invalid certificates or having apps they're supposed to be testflight testers of disappearing from testflight all too soon. (In fact see also this question along the same lines).

Given that Apple clearly see testflight as an important piece of the appstore infrastructure, I find it hard to believe this organization is going about things in the way Apple actually intend things to be done. Can someone with some insight into the Right Way of doing things please enlighten me?

Apologies if my terminology is off in some of the above... I just dabble in this stuff.

Answer 1

The right way is to have one distribution certificate and share the private key. We share a small keychain that contains just the private keys and certs needed for development/distribution among our org. You can add this 'stub' keychain to all your development machines, and if it's checked into version control, you can push out updates to everyone easily. You can also password protect it, in which case Xcode will ask you to unlock it when using to codesign.

The fact that it's "easy" to churn the certs is actually a bad thing, IMO. As you've observed, it's easy for other developers on the team to screw things up, particularly regarding TestFlight, although I heard from another developer recently that Apple might have fixed that. (I haven't confirmed it myself.)