A Beginner’s Guide to iOS Provisioning Profiles

A Beginner’s Guide to iOS Provisioning Profiles

If you’ve spent any time developing an app for iOS, then you’ve probably stumbled across the bit of the Developer Console called ‘Certificates, Identifiers & Profiles’.

Certificates, Identifiers & Profiles

This is not a blog post about how to do anything in that section.

Instead, it’s a rough guide to what everything means — in the hope of providing some relief/context when you’ve just seen the error ‘No code signing identities’ for the millionth time and feel like throwing your laptop out the window while shouting ‘Code sign this!’

(Note: this article focuses on App Store apps, rather than in-house apps, which you can create through the Apple Developer Enterprise Program.)

Why Provisioning Profiles?

Good question. The key thing is that, unlike Android, you can’t install any old app on an iOS device: it has to be signed by Apple first.1 However, when you’re developing an app, you probably want to test it before sending it to Apple for approval. Provisioning profiles are simply a way for you to do that: they’re like a ‘temporary visa’ that lets you run and test your app on a physical device. And like all good visa schemes, this means dealing with some bureaucracy…

The Components

Provisioning profiles always require the following components:2

  • A certificate
  • A unique app identifier (an ‘App ID’)

In some cases, they also require:

  • A list of devices the app can run on

The Certificate

This is a public/private key-pair, which identifies who developed the app.3 (Without such certificates, I could e.g. create an app called ‘Facebook’ and pretend that it’s an update to the actual Facebook — and hence trick you into giving me your login credentials.)

When you try to create a new certificate, you’ll be presented with several options. For provisioning profiles, the key ones are:

  • iOS App Development: a development certificate. These are for developers who want to test the app on a physical device while writing code.
  • App Store and Ad-Hoc: a distribution certificate. These are for when you’re ready to give the app to other people — first for testing (the ‘Ad-Hoc’ bit) and then for general distribution via TestFlight or the App Store.

When you join an iOS development team, you’re either a ‘Member’ or an ‘Admin’. Anyone can create development certificates, but only those with admin privileges can create distribution certificates.

The App ID

This is a unique identifier for your app. Apple recommends using a ‘reverse-domain name style string’ of the form: com.yourcompanyname.yourappname. You can then associate ‘entitlements’ to your App ID, such as iCloud, Push Notifications, Apple Pay, etc.

It’s also possible to create ‘wildcard’ App IDs, e.g. com.yourcompanyname.*, which can be used for multiple apps. While these can be useful in some cases, note that you can’t associate entitlements to them.

Extra tip: if you’re planning on releasing an Android app as well, then you should avoid using hyphens (-) in your App ID — otherwise you won’t be able to use the same one on both platforms.

The List of Devices

This is a list of devices.

This is perhaps the most annoying part of the process: if you want to distribute your app to testers (without using TestFlight), then they need to send you their device’s ‘Unique Device Identifier’ or UDID. Unfortunately, you can’t find it within iOS itself: they’ll need to connect their device to a computer.

I heartily recommend the website whatsmyudid.com, which provides clear, illustrated instructions about what to do. However, you should still mentally prepare yourself for people sending you all kinds of random, irrelevant strings with the question: ‘Is this it?’ (Hint: if it’s not a 40-character, hexadecimal string, then the answer is no.4)

Creating a Provisioning Profile

Congratulations, you’re now ready to build your provisioning profile! Again, there are quite a few options, but the main ones are:

  • iOS App Development: for testing the app on a physical device while developing.
  • Ad Hoc: for distributing the app to non-TestFlight testers (e.g. via HockeyApp).
  • App Store: for distributing the app via TestFlight or the App Store. (Note that this one doesn’t work on its own: your app will still need signing by Apple.)

Here are the key differences between them:

Provisioning Profile Certificate App ID List of Devices
iOS App Development iOS App Development Yes Yes
Ad Hoc App Store and Ad-Hoc Yes Yes
App Store App Store and Ad-Hoc Yes No

So when iOS attempts to install an app, it checks the following things:

  • That the private key used to sign the app matches the public key in the certificate;
  • That the App ID is correct;
  • That the entitlements required are associated with the App ID;
  • That the device itself is in the list of devices.

If anyone of these conditions fail, then the app will not install — and you’ll see a greyed-out app icon with no error message or clue for how to proceed. But at least now you have somewhere to start: you can go through those four bullet points manually, and make sure everything is as it should be. (We’ve found it’s usually an issue with the list of devices.)

The End

I hope this post helped demystify what’s going on when you create a provisioning profile. If not, then please feel free to leave a question in the comments below!


Footnotes

1 This doesn’t apply to the iOS simulator or a jailbroken device. [back]
2 Note that these correspond to the sections of the left-hand menu within ‘Certificates, Identifiers & Profiles’. [back]
3 Although this is all a lot more elaborate than Android’s system, one of the great advantages is that you can recreate certificates. On Android, if you lose the original private key then you’re screwed: you won’t be able to update your original app, and you’ll have to convince all your existing users to download a new one. [back]
4 I once even got sent a 40-character, hexadecimal string that wasn’t a valid UDID, and looked nothing like the actual one they eventually sent me. To this day, I still have no idea where they got it from. [back]


You liked this article? You'd probably be a good match for our ever-growing tech team at Theodo.

Join Us

  • > I once even got sent a 40-character, hexadecimal string that wasn’t a valid UDID, and looked nothing like the actual one they eventually sent me. To this day, I still have no idea where they got it from.

    A UDID is the result of a SHA-1 calculation: there is no such thing as a 40-character hexadecimal string which is “isn’t a valid UDID” by syntax, so this is interesting to me: if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)?

    (Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was “invalid”, that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application.)

  • Bilal Abdul-Nabi

    I am flabbergasted that developing on iOS is still a frustrating process compared to Android. Testing apps on Android is really really easy (just deploy the apk on your device and you are good) whereas on iOS you have to jump through so many hurdles just to put it on a device.

  • Oliver Waterkamp

    thanks for the article, it helps me for the first steps…:-)