De-Mystifying Apple's iOS Provisioning

January 6, 2015 Appirio

by Brandon Jones


When developing for the iOS Platform, the provisioning system is one of the biggest stumbling blocks for new developers. The provisioning system is great because it provides users the security of knowing that the applications installed have verified certificates. But developers are often challenged by the different methods to get their apps to the users’ devices. So, in the interest of helping solve these challenges, here is an in-depth guide.

But First, Some Terms…

In order to truly understand all components of this flow, the following components/terms are necessary to know:

Provisioning Profile – A document specifying what combination of certificates, identifiers, and entitlements are allowed by Apple to make it onto a device.

Developer Certificate – An Apple-Signed Certificate, with a private key generated by Keychain Access, that is unique to an individual developer for signing applications in XCode. You can have one per member of an Apple Developer Account.

Device UUID – A universally unique identifier for an iOS Device that gets registered in an Apple Developer Account, for use with Ad-Hoc and In-Development applications.

App ID – The unique identifier of an Application in the Apple Developer Account. These correspond to a certain set of service entitlements such as Push Notifications, HomeKit, HealthKit, Passbook, etc. Unless otherwise required by a service entitlement, these can be applied with a wildcard – e.g., “*” which will apply to “” AND “” – or may be set explicitly – which will ONLY apply to “” if that is the corresponding ID.


Development Provisioning Profile


The Development Profile is a provisioning profile for a single Apple Developer Account member to build and run applications on a device from XCode. It utilizes a Developer Certificate for code-signing. As you can see in the diagram above, this Profile requires that UUIDs are specified for devices in the Apple Developer Account, and set on a profile-by-profile basis. Development profiles can use either a Wildcard ID or an Explicit App Id. Two different development profiles may use the same App ID, but have a different subset of devices they can build for.


Ad-Hoc Distribution Profile


The Ad-Hoc Distribution Profile is similar to the Development Profile. It requires a specific set of UUIDs to be defined, it can use a wild-card or an explicit App ID, and it will use a Developer Certificate for code-signing. The difference is that it requires the app to be archived from XCode, and distributed as an IPA installed via iTunes.


In-House (Universal) Distribution


In-House Distribution is a pretty big departure from the Ad-Hoc distribution standard that was in place before Apple created Enterprise developer accounts. For this distribution type, UUIDs are not required. Furthermore, this can be used with wildcard or explicit App IDs. It does require use of the Account Distribution Certificate, however, which can be a headache. As there are only two Distribution certificates per Account, you will need to make sure the certificate with the private key accessible for any developer who will be doing a build with the account.

One big issue that can arise from utilizing an In-House Distribution model stems from the Distribution Certificates associated with the Apple Enterprise Developer Account. At any point-in-time there can be only two Distribution Certificates. Because Apple verifies the provisioning of the installed applications, users won’t be able to run applications built with expired or revoked certificates. They also will not be able to download them from your distribution page. You will have to re-build your application with a new Distribution Certificate in order for users to be able to download and install the application to their device.


App Store Distribution Profile


The App Store Distribution profile is required for putting an app for download on the official App Store. It requires a standard Developer Account, as opposed to an Enterprise Developer Account. It also requires that App IDs be explicit, and will also require the Account Distribution Certificate for the archive signing. Apple recently announced a partnership with Test Flight that allows this profile to be used for “pre-release builds.” This will allow Accounts to beta-test their applications, or distribute to up to 1,000 accounts without having to release to the App Store. For more information on the specifics of setting up iTunes Connect to actually use this distribution profile’s builds, consult Apple’s official Test Flight developer page.

Hopefully this guide to Apple’s provisioning system will alleviate some of those early development headaches related to developing for iOS, so that you can tackle the bigger problems in development. Like mastering constraints and auto-layout, properly using Grand Central Dispatch for asynchronous calls, or just utilizing some of the cooler APIs like Metal to make your app awesome. If you need some ideas to work on in order to learn, why not try your hand at Objective-C or Swift on Topcoder? There’s a whole lot of interesting and challenging tasks to work through with the iOS platform, don’t let provisioning for devices be one of them.

mobile_apps (1)

Previous Article
Strategies for Building Customer Facing Salesforce Apps
Strategies for Building Customer Facing Salesforce Apps

There comes a time in almost every Salesforce org’s life when you want to get some data from your org on to...

Next Article
Sending Emails without a targetObject ID in Apex
Sending Emails without a targetObject ID in Apex