Code signing is one of those frustrating chores that iOS developers inevitably have to deal with--whether it’s creating provisioning profiles or managing development or production certificates, or certificates for push notification. The process is tedious, frustrating and convoluted, but it doesn't have to be.
Code signing can be an especially onerous task in team environments, where you have to download an updated provisioning profile every time you have duplicate profiles or profiles that unexpectedly expire, and each time you add a device. All developers have to generate his or her own signing identity, which takes time away from more important tasks, such as building and innovating.
Luckily, there is an alternative--a new best-practice that is emerging in the iOS community. A mechanism for keeping all keys in sync and managed centrally through a Git repository, the premise is that everyone on the team would use the same account, with a single code signing identity.
In this article, we take you through the process of setting up a Git-based code-signing process for your iOS team.
Getting Started with Git-Based Code-Signing
The first step is for everyone to start using a single Apple ID, so create a new apple ID for the team, like AcmeDevelopment@icloud.com.
Next, create a private Git repository (Bitbucket would also do), for the purpose of storing the development profiles.
On the Apple Developer website, you will now create and generate the certificates for each environment, as well as private keys (you can export them from Keychain). All of this will be stored in the private Git repository you’ve just created.
You also need to generate the provisioning profiles for the various targets (Development | App Store | Adhoc), matching the certificates, and store them in your Git repository. The Codesigning.guide recommends encrypting the private keys prior to committing them to your private Git repository, which can be done as follows, in terminal:
openssl des3 -in file.txt -out something_private.p12
You will need to confirm a password, which should be shared only with the members of your team. Alternatively, upon export Keychain can encrypt using a password. Likewise, you can decrypt a file using openSSL.
Once you have encrypted your provisioning profiles and certificates, and pushed them to your private Git repo, your team will have access to them. You can subsequently grant access to this repository to new team members, and import the certificates and provisiong profiles into their Keychains (after decrypting them, of course).
The certificates and private keys should be imported into your Keychain, either using Finder or using the ty import’ command The provisioning profiles should be copied over to ‘~/Library/MobileDevice/Provisioning\ Profiles/’ (source: CodeSigning Guide)
There is one more thing you need to do in Xcode before you are done. Your Xcode project must choose the provisioning profiles automatically (or otherwise defined statically). The CodeSigning Guide recommends passing the UUID of the provisioning profile for each of the bundle identifiers. You also need to repeat this for each of the targets if your app has multiple targets.
There are still quriks associated with code-signing and provisioning, and hopefully Apple can make this an easier process in the future, but for now, this emerging best-practice makes the task slightly easier.
For an even easier workflow, a tool called Match allows users to generate new certificates and profiles, and automatically pushes the changes back to your private Git repository. It even creates a nice README.md file to help your other team members onboard more easily.