“Finally, the provisioning profile is for testing only, right? The distribution cert is what allows me to get the app released?”
Certificates and Provisioning Profiles have been a perennial source of developer confusion and frustration. A lack of easy-to-understand documentation from Apple on this topic adds to the problem. But it is still very important to learn about these topics as an iOS developer.
“I know this is a lot of questions but I feel overwhelmed and don’t know where to start, I’m currently trying to read through the documentation but there’s so much I don’t understand. Any help would be greatly appreciated.”
All developers will eventually run into needing to use and understand these, it is a requirement. You will save yourself a lot of frustration and make sure you don’t delay submitting your app by understanding the purposes for certificates and provisioning profiles.
“This is frustrating as it is holding my app’s launch back”
One of the worst things about these issues is that if they appear, it is almost guaranteed to happen at a stressful time: submitting your app to the store, trying to meet that important launch deadline, or delivering a crucial bug fix to your customers. This is the time when issues with your certificates or provisioning profiles might appear.
So save your future self from all that stress and worry by getting an understanding of these now, and you can thank yourself later 😇
Notes: This article will focus on regular Apple Developer Program accounts. The Enterprise Program is a different story. The focus will also be on apps for iOS (and therefore watchOS). Apps for tvOS are very similar. Apps for macOS have some important distinctions, but much of the understanding still applies.
Certificates provide many assurances for the app builds you create. There are two that are important to point out here:
- Certificates assure that your app was built by you or a team member. It is therefore important to protect the Signing Identity (private key) for your Certificates.
- Certificates are used to guard against the code of your app being changed after you build it. This is known as code signing. If the executable code of your app is modified after code signing, the signature will no longer be valid, and iOS devices will know not to run the code.
iOS App Development Certificate
Also known as the “Developer” or “Development” certificate.
This certificate is used to sign code in order to run it on the testing device connected directly to your Mac. Each developer on a team will get their own certificate. If that developer has multiple Macs you can share the same Developer certificate between those computers.
Because you will use this daily in your testing, it will immediately be brought to your attention if anything is wrong. Developer certificates expire one year after creation. When it expires, it doesn’t have any impact on your apps in the store or your ability to submit apps to iTunes Connect. You will need to create a new one to continue testing on your development devices, but it is fairly straightforward to do so. Xcode now even includes a one-click button to do it for you you.
App Store and Ad Hoc Production Certificate
Most commonly known as the “Distribution” certificate.
This certificate is used in a couple situations: for testing your app builds in an Ad Hoc manner; and for submitting builds to iTunes Connect for both testing on TestFlight and submitting for review to be approved for sale on the App Store. (More info on both Ad Hoc and submitting to iTunes Connect below.) Just like a Developer Certificate, a Distribution Certificate will expire one year after it is created. It is a good idea to stay on top of your Distribution Certificate before it expires. You will get a scary-sounding email from Apple 30 days before that happens, but don’t worry. More information on that here: http://bradfol.com/2017/01/ios-distribution-certificate-is-expiring-what-do-i-do/
Distribution Certificates are shared by the entire team. Most of the time you will have a single Distribution Certificate that is used for all apps and all developers that have permission to submit builds to iTunes Connect.
Provisioning profiles store a configuration of settings that allow your app to launch in certain circumstances. Depending on which stage of app creation you are in, different provisioning profiles will be needed.
In most cases Xcode now has the ability to create or update provisioning profiles for you. It is still important to understand what is happening. When Xcode does perform an action on your profiles, I would recommend that you log into the Certificates, IDs, & Profiles tool in the Developer Account website and take a look at the result. That tool will allow you to see and inspect all profiles created by Xcode (in addition to the ones created manually).
iOS App Development Provisioning Profile
This essential provisioning profile is used for the day-to-day development process of build and running your app on a device connected to your Mac.
Use this provisioning profile to specify which development devices you will be using to sign and run development builds of your app. This is used when you are running a development build while connected directly to your Mac. Xcode will maintain a debug connection to the app, proving live logs and further inspection tools of your running app.
The provisioning profile must match three things to be correct: the Developer Certificate that matches what is on your Mac, the App ID for the app you are trying to build, and the devices you want to run that app on. Note that for two of those requirements (certificates and devices), this type of Provisioning Profile allows for multiple selections. For example, you could have a single Development provisioning profile that specifies the Development Certificate for two developers, as well as all the iOS testing devices that the team uses. If any of those three areas of requirement change, a new provisioning profile will need to be generated. The most common example is wanting to test the app on a new development iOS device. If you get a new device you want to test, you will need to edit the provisioning profile and include that new device. The newly generated profile effectively replaces the previous one. In many cases, Xcode can automatically manage the process of generating new profiles for you. It is performing these same steps for you, and the same requirements apply.
App Store Distribution Provisioning Profile
This is a very important Provisioning Profile. It is used each time you upload a build to iTunes Connect. That includes uploading for both the purposes of testing using TestFlight, and submitting to App Store review.
There are two requirements that go into this provisioning profile: the App ID, and the Distribution Certificate. When Xcode uploads your app build to iTunes Connect, it includes a copy of this provisioning profile. The iTunes Connect system then checks that the App ID and code signing of your app build match what is specified in this provisioning profile. Additionally, that certificate must be a Production (a.k.a. “Distribution”) certificate, not a Development Certificate, and match what is specified in the provisioning profile.
Ad Hoc Distribution Provisioning Profile
The purpose of this Provision Profile was to allow developers to send their app out to a group of testers to receive feedback on the app before it is made available publicly on the App Store. However, this method of testing pre-release app builds has seen reduced importance over the last few years, due to the integration of TestFlight into iTunes Connect. TestFlight meets these testing needs for most developers, and takes much less time to manage than Ad Hoc Distribution.
As the name might suggest, “Ad Hoc Distribution” allows your app to be distributed in an ad hoc manner. To be more specific, the app build can be distributed to only the list of devices included in this Provisioning Profile, and only for the App ID specified in the profile. The build must be code signed using your Distribution certificate, also matched to this provisioning profile. Anyone with experience doing this type of app testing knows how much headache and difficulty it caused. Again, for most developers, it is now a better idea to use TestFlight. But this option still exists if you need it.