Force create new Provisioning Profiles with existing Certificates on fastlane

Why bother generating a new Certificate each time you create a Provisioning Profile? It can be rather redundant, as fastlane’s ‘match’ command might insist on generating new Certificates, even when you already have suitable ones that can be used for these new Profiles. This article will provide the safest and quickest way to generate new Provisioning Profiles without breaking down anything else.

Image by @ios_memes

The issue

Fastlane’s match tool is a significant improvement for handling code signing, particularly in team environments. It works by creating a single source of truth for your Certificates and Provisioning Profiles, storing them securely and ensuring that everyone on the team uses the same credentials for building and signing apps. This approach simplifies many of the complexities and headaches associated with code signing.

match is indeed designed with the intention of creating a fresh, shared set of Certificates and Provisioning Profiles. It's primarily aimed at simplifying code signing by creating a single source of truth that can be used across a development team. This can sometimes be interpreted as not working well with pre-existing Certificates.

While match focuses on creating new resources, it does offer a way to import existing Certificates. However, this process is not as straightforward as the default behavior of creating new ones. Developers who want to use existing Certificates need to manually import them into the match repository. And even with that sometimes it ends up creating new Certificates for new Provisioning Profiles when unnecessary — you end up having multiple Development and Distribution Certificates, with ones intended to be used for any platform (Apple Development and Apple Distribution), and others are e.g. iOS platform specific (iOS Development and iOS Distribution).

For the sake of simplicity and flexibility, we want a single Certificate for development and a single Certificate for distribution, not multiple ones for multiple platforms.

So instead of this:

Simplified chart

We will end up having this (our desired result):

Simplified chart

Today we will be using fastlane’s sigh instead as it is optimized for Provisioning Profiles management workflows.

Initial setup

So let’s say, you have set up your project’s Certificates and Provisioning Profiles with fastlane match command. In detail, everything is going well — you have appropriate and not limited to a specific platform Development and Distribution certificates, and you have Development and App Store Provisioning Profiles. For this tutorial, all code signing resources are stored in Git repository.

An example of ‘that’ clean initial result:

Certificates for both Development and Distribution (not limited to a specific platform)

Provisioning Profiles for both Development and App Store distribution of your application

Creating new Provisioning Profiles

Now imagine that you are asked to create widgets for your mobile application. Widgets extension target needs to have its own Provisioning Profiles (as well as it has its own Bundle Identifier, e.g. com.yourName.yourProduct.yourProductWidget).

Usually, you do this:

fastlane match development -app_identifier "com.yourName.yourProduct.yourProductWidget" -verbose
fastlane match appstore -app_identifier "com.yourName.yourProduct.yourProductWidget" -verbose

And then you sometimes end up with all that unintended Certificates management… You end up revoking everything and setting up it all again.

We do not need to create new Certificates as our existing Certificates are already valid for new Provisioning Profiles:

Using fastlane sigh

Unlike match, sigh doesn't handle certificates. This makes it a good choice if you want to use your existing certificates. You can manage your certificates separately (manually, using match, or other tools) and let sigh take care of the Provisioning Profiles alone.

So what do we need to do to make sure it does not create new Certificates in addition to new Provisioning Profiles, but rather create new the Provisioning Profiles with existing Certificates only for our widget target instead? Well, we can use fastlane sigh command:

fastlane sigh -app_identifier "com.yourName.yourProduct.yourProductWidget" - cert_id "XXXXXXXXXXX" -development false -force true
fastlane sigh -app_identifier "com.yourName.yourProduct.yourProductWidget" - cert_id "XXXXXXXXXXX" -development true -force true

It needs Certificate identifier. We can get it from our Git repository where we store Certificates and Provisioning Profiles in:

Opening either development or distribution folders will display certificate identifiers as names. In our case it is XAV84718LE:

Now, we can fill the missing data (Certificate identifier) in our fastlane sigh command:

fastlane sigh -app_identifier "com.yourName.yourProduct.yourProductWidget" - cert_id "XAV84718LE" -development false -force true
fastlane sigh -app_identifier "com.yourName.yourProduct.yourProductWidget" - cert_id "XXXXXXXXXX" -development true -force true

We do the same for the Distribution Certificate identifier (where I wrote XXXXXXXXXX in the last code snippet).

The result

Executing the commands will create new Provisioning Profiles (for our widget target) on App Store Connect:

And will import them into Git repo:

Nevertheless, it will also import them to your Xcode. You can choose those newly created Provisioning Profiles for your widgets target. For both Debug (Development) and Release (Distribution) signing:

That’s all! It is probably the simplest and safest way to generate new Provisioning Profiles without breaking down anything else.

Thank you for reading and good luck automating the code signing! :)

More about me and my experience here.