Certificates and profile organization for multiple products

Question

At my workplace we have completed development on one iOS app and are about to embark upon a second.

Before doing so I wanted to clarify a few things regarding certificates and profiles and build environments:

Q1: Am I correct in thinking that an Apple account can only have one distribution certificate, and that therefore this will be used in both apps? (via it being present in the provisioning profiles, I'll be creating a new set of profiles containing a new app id for the new app).

Q2: As it is the certificates and not the profiles that are installed into the keychain, I am assuming the new application should just build on the build machine that is currently set up for the current application.

Q3: Related to Q2, I am wondering if it is necessary, or a good idea, to have the builds for the current app and the new app separated by putting them on different physical build machines (or partition the build machine into virtual machines). If the two apps were using different certificates I would think this is necessary (or at least partition the keychain). I'm worried about certificate and keychain issues arising. However if the answer to Q1 is that there is only one distribution certificate then there should in theory be no need to have separate build machines for each application?

Q4: Both apps use push notifications, is it ok to use the same push certificate for both (in a different profile of course)?

TIA

Answer 1

Certificates and Provisioning can be a tricky topic, so it is certainly a good idea to ask first before inadvertently causing yourself some pain!

Q1: Only 1 Distribution Certificate per account?

Yes, Individual and Company accounts are limited to a single active Distribution certificate per membership year, however this certificate may be revoked and reissued at any time if the Individual or Company deems it necessary to do so (compromised Public/Private key, termination of employees with access to the private key, etc.). I recently answered a question "What are Code Signing Identities?" that may be helpful in providing some additional context about the information that is encoded into a Provisioning Profile and how Xcode looks up this information when performing Device builds. Do keep in mind that depending on the type of Provisioning Profile used (Development vs. Distribution) will alter the number and type of Certificates and test devices encoded in a Provisioning Profile.

You are also absolutely correct in that you will reuse the existing Distribution Certificate with an entirely new set of Provisioning Profiles that are encoded with the App Id / Bundle Id of the second application you are getting ready to / are writing.

Q2: Certificates and not Provisioning Profiles are what get installing in Keychain right? How would a build machine be impacted?

Yes, this is correct. Both your Development Certificate and Distribution Certificate are what get installed into Keychain while Provisioning Profiles are installed into a special directory within Xcode for use with Code Sign operations.

Assuming you've got your build machine setup and working for your first app, you've got a lot of the hard work done. A high level list of things you'll still need to do:

• Generate a set of Provisioning Profiles for the new AppId using the existing certificates
• Install the Provisioning Profile(s) on the Build environment
• Ensure the Xcode Project's 'Code Signing Identity' build setting is configured to use the newly created Provisioning Profiles or more ideally use the 'Automatic Profile Selector' if your project configuration allows it.
• Configure your Build system to actually make the new app.

Specific HOWTOs for these high-level tasks will be somewhat dependent on how you've setup your project and build system, but generally should follow the same workflow as was used when constructing the first app.

Q3: Is it necessary/good idea to partition the build environment on to separate machines?

As far as the 'necessary' part of this question, No, it is not required that you physically or virtually separate the build environments to be able to build these apps side-by-side, however you could elect to do so if your business needs are such that you required dedicated build environments on a per-application basis.

From a technical perspective, the Provisioning Profiles provide 99% of the partitioning necessary to be able to build side-by-side. The only time you would run into a situation where physical or virtual partitioning may be required would be if you were a member of two or more iOS Development Programs and the 'Common Names' on the certificates issued by each of these teams matched (ex. "iPhone Distribution: MyCompany" was the Common Name of the certificate from Team1 and was absolutely identical to a certificate issued by Team2). If this were ever the case you'd see warnings and errors in Xcode like the following:

Code Sign error: Certificate identity 'iPhone Distribution: MyName' appears more than once in the keychain. The codesign tool requires there only be one.

In all other cases, assuming you have both your Certificates and Provisioning Profiles installed and the Code Signing Identity value set correctly, then Code Sign can take care of itself.

Q4: Is it ok to reuse the same push certificate for both apps?

This one is a solid 'No'. Each App Id has its own set of Provisioning Profiles which are accompanied by a set of Entitlements, of which one is Push Notifications. When constructing a new Provisioning Profile with the Push Notification entitlement, you are asked to generate new Push Certificates -- There is no opportunity to provide your existing certificates to Apple. This is done to ensure that a Push Notifications 'Provider' (your server that creates the Push Notification payloads sent to Apple's Push Gateway) is sandboxed in a way similar to that found within the iOS ecosystem -- one provider per AppId...one sandbox per AppId.

From a security standpoint, this prevents an attacker from sending spammy push notifications to your user simply by providing a valid Push token and payload at Apple's Push Gateway. Either setup a second instance of your provider code and use the Push Certificates generated while making the new Provisioning Profile or update your existing provider to keep track of Push Notification tokens on a per-application level and use the right certificate when sending a Push Notification payload to Apple. Unfortunately, only you (or your colleagues) can make this determination as that decision will be governed by the technical capabilities of your existing provider and the degree of risk you/your company is willing to take unifying Push Notifications on the same provider instance.

Others may pipe up here and provide some additional insight about how they setup their own providers, but I've gone with entirely separate instances to prevent a scenario where updates for one app's Push Notifications could break Push Notifications for an entirely different app.