The Provisioning Profile Crash Course – Part 4

The previous posts from this series are Part1, Part2 and Part3.

Profile management

Just to summarize the dependency graph for the different type of provisioning profiles here is the graph:

The Developer Profile depends on / consist the following

• Team identifiers,
• Developer certificates,
• Devices,
• Entitlements/capabilities, which is also part of the Identifier,
• Apple Certificates.

The Distribution Profile depends on / consist the following

• Team identifiers,
• Distribution certificate,
• Entitlements/capabilities, which is also part of the Identifier,
• Apple Certificates.

Changes on those elements most probably causing the Provisioning profile to be invalidated. Let see what are the changes that we need to handle.

Certificates

Apart from that both the Developer’s certificate and the Distribution certificate has an expiry, and after that expiry it can not be used, so it is invalidating the respective Provisioning profile, the most common task here is to handle the movement of the developers in the project. If your organization is stable and there is not too much movements in the workforce, that is not a big issue. However, if there is a big fluctuation in the people, and you want to follow the security best practices, then each time when a developer leaves her certificate must be revoked. In the event of new joiner to our dev team, the new-joiner developer certificate needs to be added to the respective profile.

Devices

Apple only allows to remove devices from your list only once in a year, at the annual renewal of you developer account membership. All of the device code which are not used anymore should be removed this time. There is a limit of registered devices (100 per device types at the time oof writing), so that could be also good occasion to do the clean up. If your new-joiner needs to add her device, then the profiles needs to be adjusted after adding the device.

Entitlements and capabilities

That is more frequent as you might think. Adding any new capabilities to the app identifier will result the invalidation of the provisioning profile. Actually you got a pop-up about that fact when you are making changes in the Identifier section.

And the rest…

Usually the other parts of the Provisioning profiles are changing in rare cases. The team identifier might change when the app is transferred to another developer account. The Apple certificate change happened in 2022, I think we are safe for few years, but that one also required the re-generation of the profile.

Troubleshooting

Actually the troubleshooting of why do you have issues with the provisioning profiles can be really just going down to the basics in this series, like:

• The right type of profile is being used?
• All of the included items (certs, identifiers, devices, capabilities) are correct and valid (not expired or revoked)?
• The correct distribution certificate and password is supplied (in case of CI/CD)?

Apart from those basic things I would highlight only one issue, that I sometimes facing, and that is about how many active certificates we are keeping on the local Keychain Access. So, here it is my tip: If it is possible, keep only one copy of the development and the distribution certificate in your Keychain Access, and save the unused ones to a .p12 file somewhere else. Based on my experience it seems that Xcode doesn’t try to match all of the local certificates to the one included in the provisioning profile, but only tries with the first one found  in the Keychain Access.  

That is a very frustrating issue, and I spent  little bit of a time t figure out, so I decided to share with you, maybe it helps you as well.

If you like my articles, or you think that you can add more value to them, feel free to say “Hi!” to me on Twitter, or get in touch on LinkedIn.