If you’ve worked with Apple platform development (iOS, watchOS, tvOS, or macOS) long enough, then you’ve probably encountered this mystifying process known as app provisioning. This is the process by which you can get your apps outside of the iOS simulator and move them onto production devices through direct (or “development”) installation or App Store distribution.

In this series of articles, I want to help demystify this process, bringing to light exactly what provisioning is, how it’s done on large teams, what provisioning profiles and certificates are, and how to wire up everything inside of Xcode.

In this first article, we’ll explain certificates and provisioning profiles, and debunk the myth that Xcode is the best way to manage profiles.

What’s the point of provisioning?

iOS started its life as a secure operating system, and Apple remains focused on making some of the most secure devices on the planet. In 2008 when Apple released the first iPhone SDK, they were faced with a dilemma: how do they continue to make a secure device, but also give access to the OS and hardware to developers.

Their plan was to create a system by which developers had to register to write apps for their platform, and made a secure system which required those registered developers to sign their apps to submit the apps to Apple. Developers could not release apps to the public on their own and bypass Apple’s review process on the App Store, making for an even more secure system.

This process allows Apple to be the gatekeeper for their system, and gives them the sole power to disable developer accounts and revoke certificates if developers go rogue, to disallow a particular developer’s apps from being installable on devices.

In addition, this lets developers manage the services and portions of the OS their apps use.

What is a Provisioning Profile?

A provisioning profile is used by iOS and Xcode to determine if the app can be installed on a particular device, what services from iOS the app will have access to (iCloud, Keychain, Push Notifications, etc), and some other information to get the app installed on the device or shipped to the App Store.

There are several types of profiles, depending on the app destination:

With the exception of an in-house distribution profile, all of the profiles expire each year from the date of creation of the profile. This means that the profiles must be re-generated yearly to keep distributing apps to devices or the App Store.

Each profile type is registered with a certificate as well, and the profile and certificate pair are used to sign the app binary in a way that the app is installable on an iOS device.

What is a Certificate?

A certificate is generated from the provisioning portal in your developer account, and like provisioning profiles, has the same types depending on if the app is destined for a debuggable build, in-house distribution, ad-hoc, or App Store.

The certificate is used during the build process to sign the app binary. The signed app binary helps Apple to ensure the binary hasn’t been tampered with and that it’s the exact app that you shipped to them for distribution or device installation.

This is a standard certificate that includes a private and public key pair, and Apple never stores or maintains your private key to ensure that the developer retains the only copy to verify their identity when signing the app.

A certificate must be tied to a provisioning profile when creating the provisioning profile. In the next article in this series, we’ll delve into creating profiles, certificates, and more.

Why not just use Xcode to manage everything?

This is the “oh, my!” part of this article. Xcode has offered the ability to “fix” provisioning issues for a few years now, and with each release of Xcode, this functionality gets better. Xcode 8 has some of the best automatic provisioning functionality, but it’s still not the best. Xcode’s provisioning tools work stellar if you are the sole developer on a team; however, when you add multiple team members, things can get a little messy.

From duplicate provisioning profiles, mismatched certificates, and more, problems are bound to happen in an environment where multiple developer’s accounts are messing with the provisioning settings.

For larger teams (with more than 2 people performing debug device installations or builds), we at MartianCraft use a system whereby one developer on the team is given the title of “provisioning master.” It’s their job to create provisioning profiles, be the keeper of certificates, and update the provisioning profiles whenever a new team member is added.

We generate one set of provisioning profiles and certificates that is used by everyone on the team. Each provisioning profile and certificate pair match the scheme type that is being used in Xcode:

These certificates and profiles are then assigned to the various targets in the Xcode project so that when Xcode builds, it automatically uses the certificates and profiles to sign the app for distribution.

When a developer joins the team, they need only to install the profiles and certificates that are inside of the repository along side of the code to perform all of the debugging and build functions for the project. This makes life much easier for a larger team.

What’s next?

Be sure to stay tuned. The next installation of this article will cover how to generate certificates and profiles, how to install them in Xcode, and how to handle multiple schemes inside of Xcode.

Cory Bohon

Team Lead Engineer
MartianCraft is a US-based mobile software development agency. For nearly two decades, we have been building world-class and award-winning mobile apps for all types of businesses. We would love to create a custom software solution that meets your specific needs. Let's get in touch.

Bring your ideas to reality.

Get in touch

© 2024 MartianCraft, LLC