title: How should an organization with multiple iOS applications under development manage iOS distribution certificates?
body: <p>I've recently had some involvement with a group with an organizational account for iOS development.</p>
  
  <p>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:</p>
  
  <ul>
  <li>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.  <a href="https://stackoverflow.com/questions/13266125/how-to-use-distribution-certificates-in-a-team-of-two-developers">Example</a>, <a href="https://stackoverflow.com/questions/30349196/downloaded-ios-distribution-certificate-not-under-my-certificates">another example</a>; there are many more). </li>
  <li>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).</li>
  <li>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.</li>
  <li>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.</li>
  </ul>
  
  <p>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 <a href="https://stackoverflow.com/questions/35941216/managing-distribution-certificates-with-a-large-dev-team">this question</a> along the same lines).</p>
  
  <p>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.  <strong>Can someone with some insight into the Right Way of doing things please enlighten me?</strong></p>
  
  <p>Apologies if my terminology is off in some of the above... I just dabble in this stuff.</p>