10

Before you get mad at my question, I know there is not one best way to setup Fastlane, but I would like to understand better the different approaches that you can take when you start using it.

I am setting up Fastlane for a project. Now I only have it on my local machine but I would like to set it up on a CI environment (in my case GitLab-CI, but I guess it is not that important).

Disclosure, I am not only newbie on setting up Fastlane but also on setting up by myself a CI (I have used both of them though, )

After reading the documentation for code sign (https://docs.fastlane.tools/codesigning/getting-started/) I can see the different alternatives but I am not sure what are the limitations of each of them on a CI environment. In summary, what would be good practice to sign the builds when: submitting to Testflight, running unit tests, submitting to the AppStore, and so on.

The options are:

  • match
  • cert and sigh
  • Xcode's codesigning feature
  • Manually

My dissertation so far:

  • match:

    • Setup and the use is more difficult than other options, but there is a guide: https://codesigning.guide/
    • It looks to me the most "professional" option.
    • I know that with existing project it revokes the current certificates.
      1. Does it mean only the first time?
      2. What are the pitfalls of current certificates being revoked if Fastlane already uses the new ones? I see a lot of people trying to prevent this (for example this). However, now it is only me as developer and we don't have any CI in place, so I am guessing it will not affect me much. However this is handy to know for other project setups.
    • For this setup you need a private repo to store the encrypted certificates.
      1. When I was discussing this with my Android colleague he was very surprised to use a versioning system to store certificates.
      2. What is exactly the reason for that? My understanding (maybe I'm wrong) is that in this way all developers from the team can benefit from match to have a working development profile. Not sure about the benefit to release to Testflight/Appstore.

  • cert and sigh:

    • To use it just requires a couple of lines before build_app:

      get_certificates         # cert
get_provisioning_profile # sigh
build_app

    • It downloads the certificate and profile in the root of the project.

      1. I guess there should be a way to specify where to put them instead of there, maybe?
      2. We should ignore this files or clean the repository after that. I don't think they should be commited to the repository.
      3. It requires this Appfile with app_identifier, apple_id and so on, or at least that what Fastlane creates automatically when I set up Fastlane for the first time.

  • Xcode codesigning feature:

    • Give to the build_app extra parameter:

      build_app(workspace: "Chordify.xcworkspace", scheme: "Chordify", export_xcargs: "-allowProvisioningUpdates")

    • This is equivalent as having Automatically Manage Signing on Xcode (but on command line is disabled by default)

      1. Does this setting make sense for a CI?
      2. I guess it also requires this Appfile with app_identifier, apple_id and so on.

  • Manually:

    • My only conclusion on this one is that it's not easy to set up manually. I'm not sure what I was doing wrong but I couldn't build (from Xcode even) with this setup so I abandoned this option.

Fastlane has a set of real examples so you can see their Fastfile, Appfile, Gymfile, Metadata, ... (https://github.com/fastlane/examples). This is awesome, however, there is no common pattern and I cannot see the reasons they went for this or that approach.

Other general questions I have regarding code signing with Fastlane:

  • Do we need the Appfile with apple ID to be there? In that case it would make sense to create a specific ID just for this purpose, right? A developer role, for example?

  • Security vs practicality vs ease of use/setup. Are these concepts tight to one method or the other?

  • What is best in what context? (think of big vs small teams; everybody should be able to use it vs there should be some security constraints; need of CI integration; ...)

  • Last but not least... Are there any special considerations for a CI environment regarding code signing?

    • I was prompt once for the credentials of the apple id I was using. Of course on an CI environment you cannot prompt for any credentials since it is running on a build server somewhere
Elena
  • 171
  • 9
  • It is so sad that you have no answers or even comments on this post. My guess is that there are way too many questions here for a single answer to make sense. My first thought is that, for `match`, you asked "why have a repo?", and the answer is sort of the opposite of what you suggested. With certs in a repo, all developers who have access to the repo can make app store (or TestFlight) builds. Match handles downloading the certificates (stored in git) and installing them on the builder's machine. AFAIK, match is by far the easiest way to share that burden. – livingtech Mar 03 '20 at 16:23
  • Did you go with Match in the end? Your question is exactly what I want to know... From what I understand passing the extra export args to allow automatic signing still required exporting the development cert from your machine and using that on the CI machine? That's not great. I think some people hate Match as it's a black box that does stuff and we hope it just works... but it really does seem like the best (at least the easiest) solution to this – Simon Feb 23 '22 at 17:27
  • Yes, in the end I decided to go for Match and now that we are several team mates, it is convenient – Elena Mar 23 '22 at 08:16

1 Answers1

1

Even though this was asked a long time ago and the question is very broad, I suggest reading this article I've written that cover most of your questions: https://medium.com/revelo-tech/setting-up-automatic-ios-release-with-fastlane-and-match-on-ci-cd-server-16c3f1d79bc5

But let me highlight a few of the questions and answers:

I know that with existing project it revokes the current certificates. Does it mean only the first time?

Usually yes, but you can regenerate them anytime you want or need (such as when, for example, your certificates are leaked).

What are the pitfalls of current certificates being revoked if Fastlane already uses the new ones?

This is not a big deal. These certificates don't work the same as the Android signing Keystore, and they can be easily swapped.

When I was discussing this with my Android colleague he was very surprised to use a versioning system to store certificates.

It seemed weird for me as well, but the above answer helps to explain it. The android signing config doesn't change often and it's not easy to replace it in case it leaks. Besides that the iOS certificates work differently because they need to be regenerated if a new device is added to the list of allowed devices to install the app.

I guess there should be a way to specify where to put them instead of there, maybe? We should ignore this files or clean the repository after that. I don't think they should be commited to the repository.

"The provisioning profiles are installed in ~/Library/MobileDevice/Provisioning Profiles while the certificates and private keys are installed in your Keychain." (from the fastlane docs) Hence there's no need to clear the repo or worry about it.

Xcode codesigning feature:

The best way when using fastlane match is to use manually configured signing and refer to the article above. Basically after getting the certificates from the repo, you can select them on the Xcode. It usually starts with match ...

douglas.iacovelli
  • 1,346
  • 2
  • 14
  • 12