When developing for iOS you inherit the responsibility of managing certificates, identifiers and provisioning profiles and it can be a headache just to get an application onto a real device. There’s plenty of information on the internet about how to generate certificates but very little information about how to manage this all within your team.

After a little trial and error we’ve worked out a format that is efficient and reliable. We’ve documented the process and open-sourced our results – you can find step by step instructions here.

To give you a little background we are a small team of 8 developers six of whom do iOS development. Even with such a small team we ran into issues where certificates or profiles became invalid as no process was in place for shared ownership. This usually resulted in revoking certificates or profiles being deleted in favour of solving the underlying issue. To solve this we started fresh, this is how we have developed the new structure…

Certificates

Development

In development everybody generates their own development certificate. You can do this by following the instructions on the developer portal. Once you’ve followed these steps through to completion make sure you backup these two files:

  • CertificateSigningRequest.certSigningRequest file (used to generate the certificate)
  • ios_development.cer file (the certificate itself)

They should be placed into a git repository and name spaced appropriately. If a computer is replaced for any reason in the future this certificate would need regenerating since these two files do not have all of the information available to be valid. To solve this we need to backup the full certificate as a .p12 file.

You can backup a full copy of this certificate by exporting it from Keychain Access as a .p12 file. This file we store alongside our .cer and .certSigningRequest files and is password protected with a password that the whole team knows. This certificate can be simply opened on a new machine and installed without regenerating.

Production

Just one certificate is setup for Production and just as in development a .p12 is generated, in this case everyone in the team can install this certificate onto their own machine.

Identifiers

Development

One development identifier is setup with a wildcard bundle id. This means it can be used across all apps in development. Identifiers do not download to your computer and are only used in reference to iTunes Connect and Provisioning Profiles.

Production

Each app going into production will require a Production App ID this is created by following the instructions in the developer centre.

A couple of things to note here are:

  • App ID names should be complete, full & sensible names.
  • The bundle id should not contain hyphens as this breaks compatibility with Android.

Devices

Devices are hard to manage and previously we have ended up with ambiguous names which mean you have to plug in the device to verify the UUID. We have adopted a naming convention that makes it far more obvious which device is being targeted.

Devices are named in the following format:

[Full name / Company Name] - [Device + Generation] - #[id]

For example:

Adam Butler - iPad Mini Retina 1st Gen - #1

…or…

Simpleweb - iPad Retina 3rd gen - #1

Provisioning Profiles

Development

We have just one provisioning profile for development and this profile is always setup for all certificates and all devices. If anyone regenerates this certificate it’s as easy as opening the new certificate to be up and running again.

Unlike certificates these are just managed on the iOS Developer Centre and aren’t backed up in our repository.

Production

Production profiles are set up on a per application basis as per the instruction on the developer portal. Only two rules here:

  • Never set the App ID to Development
  • Always set the certificate to the global team certificate (in our case Simpleweb)

We hope you find this helpful! If you have any questions about iOS development, feel free to get in touch.

 

Related Stories