Certificates, provisioning profiles, and identifiers are important in Apple’s security schema. Apple’s security scheme for deploying applications to iOS devices is notoriously difficult to grok and has created many headaches for developers through inscrutable error messages when deploying from Xcode. However, Apple’s scheme is very flexible and currently allows for many different scenarios:
- People trust apps deployed from the App Store because Apple signs them cryptographically.
- Enterprise organizations can deploy applications to their employees without publishing them to the app store (so-called “Line of Business apps” that have no business being published to the general public).
- App developers can deploy development binaries to (up to 100 of) their own devices for testing.
- App developers can run a beta program by directly deploying correctly-signed apps to customers.
Here are some definitions for the components in Apple’s scheme:
Also referred to as “Application Identifiers” or “Bundle Identifiers“. They uniquely identify your application and typically have a reverse domain name such as
This is a cryptographic certificate granted to you by Apple. It works just like SSL where you get a certificate signed by an authority. Apple signs the private key that you use to sign different pieces of your application. Different certificates create different types of trust. Some allow you to sign and submit your application for the App Store, while others allow your application’s webserver to send push notifications to users via APNS. In the latter case, for instance, Apple uses this certificate to trust the webserver sending the push notification. Otherwise, it would be easy for an attacker to spoof a valid push notification and spam users. The most common certificate you would create signs the key you use to deploy your application to a device or submit it to the App Store.
Moreover, when you create a certificate through Apple’s developer portal, you have to create your key pair and send a “Certificate Signing Request” in the keychain app on your macOS.
In addition, if you visit the developer portal, you’ll find you can create certificates for Development or Distribution.
Probably the most confusing component in the system, a provisioning profile indicates the devices for which a correctly signed application. If you visit the developer portal, you’ll notice you can create two types (again called Development and Distribution). Provisioning profiles say “applications with this Identifier signed with this Certificate’s private key are okay to run on these devices.” Therefore, a provisioning profile ties a certificate, that’s why you have to decide whether to create a Development or Distribution profile. Distribution profiles can either be Ad-Hoc or App Store distribution profiles. I am not sure whether Ad Hoc profiles have device limits.
You might ask, then, why not always use a Distribution profile? It can deploy to an unlimited number of devices and still attach to a certificate owned by the developer. Another piece of Apple’s security puzzle is Entitlements. In an iOS application’s bundle, you’ll find Entitlements.plist, which is a list of capabilities that an application wants. When signing your application using a distribution certificate, Xcode will not allow an entitlement with get-task-allow being YES. This is because get-task-allow is what allows a debugger to connect to a process, and Apple doesn’t want that happening on apps meant for distribution.