What is a Provisioning Profile? Part 2

Written by: on April 26, 2013

Part #1 of this series introduced you to file format of the Provisioning Profile. In this post, I will dig into the actual contents of Provisioning Profiles.

I mentioned before that the Provisioning Profile is just a plist. Let’s start at the top and look at the key/values of this plist. I have a sample Provisioning Profile .plist posted for you to follow along with:

  1. The first item in the dictionary is “AppIDName.”  This is the name you gave your App ID in the iOS Provisioning Portal.

  2. Next is “ApplicationIdentifierPrefix.”  This is the 10 character string that the provisioning portal generated for you when you created your App ID. It is known as the Bundle Seed ID (App ID Prefix) in the iOS Provisioning Portal.

  3. “CreationDate” is the date-time stamp for when this Provisioning Profile was created.

  4. “DeveloperCertificates” is interesting for a few reasons. First, it is an array, so it can contain multiple certificates. However, I have only ever seen one certificate in here. Second, it is the base64 encoded developer certificate. You can copy the text inside the <data> tags and paste it into a file between the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines. You will get something like this:


Using the command openssl x509 -text -in MassivelyOverrated.pem allows you to inspect all of the certificate’s information, which will look like this:

Apple and iOS use this certificate to verify the code is signed by the appropriate developer.

  1. Next is “Entitlements.” This is a dictionary that can contain many key values pertaining to iCloud, Game Center, Push Notifications and attachment of a debugger to the app. Going into all the possibilities is outside the scope of this post. However, if you ever get the error, “The executable was signed with invalid entitlements,” you can copy this dictionary and paste it into your app’s Entitlements.plist file to make sure that the app’s and the Provisioning Profile’s entitlements are an exact match.

  2. “ExpirationDate” is the date this Provisioning Profile expires.

  3. “Name” is the name you gave this Provisioning Profile in the iOS Developer Portal.

  4. “ProvisionedDevices” is an array of all the device UDIDs on which the app associated with this Provisioning Profile can be installed.  I consider this to be the meat of the file. 90% of the time when I am opening a Provisioning Profile, it is to determine if a UDID is included in this array.

  5. “TeamIdentifier” is another array, but I have only ever seen one value in here. This is the identifier for the team to which this Provisioning Profile belongs.

  6. “TeamName” is the Team to which this Provisioning Profile belongs. I find it interesting that “TeamIdentifier” is an array, yet “TeamName” is not.

  7. “TimeToLive” is the number of days that this Provisioning Profile is valid. Apple sets this to 365.

  8. ”UUID” is interesting because the value can often find its way into your Xcode project file. This UUID changes every time you generate an updated Provisioning Profile. If you ever select a specific Code Signing Identity in Xcode, instead of the more generic “iPhone Developer” or “iPhone Distribution,” this UUID gets set into the “PROVISIONING_PROFILE” section of your Xcode project.pbxproj file. Your SCM diff will look like this when you change from one Provisioning Profile to another in Xcode:

+ PROVISIONING_PROFILE = "9B44F36C-328F-45C0-BC62-4A272CB9DAD7";

  1. “Version” is the version of this file data format. Apple sets this to 1.

I mentioned above that 90% of the time when I check a Provisioning Profile, it is to inspect the “ProvisionedDevices” array. The other 10% is almost exclusively to inspect the “Entitlements” and the “UUID.”  If you work with Apple’s Push Notification service, the “Entitlements” field holds the value for the “aps-environment.” This value can either contain “production” or “development,” and shipping an app with these values mixed up, or not set at all, guarantees that Push Notifications will not work in your app. I am extremely paranoid that I will ship an app to Apple that has the “aps-environment” not set to production. Therefore, I manually inspect the Provisioning Profile “aps-environment” of each app before I submit to iTunes Connect.

I use the “UUID” to force Xcode to build with the specific Provisioning Profile. I like being able to have full control over this instead of relying on Xcode to automatically choose the right one, which it often does not do correctly. With automated builds, Jenkins makes it very easy to override the “UUID” using an .xcconfig file. You can expect to hear more about that soon.

Jay Graves

Jay Graves

Jay is the Chief Technology Officer for POSSIBLE Mobile, a leading mobile development company. Jay’s expertise developing apps for some of the world's top brands has made him a respected leader in the space, with his work being featured on television, in iTunes and on devices inside Apple retail stores.

Add your voice to the discussion: