title: Best way of code sign using Fastlane on CI
body: <p>Before you get mad at my question, I know there is not <strong><em>one best way</em></strong> to setup Fastlane, but I would like to understand better the different approaches that you can take when you start using it.</p>
  
  <p>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). </p>
  
  <p>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, )</p>
  
  <p>After reading the documentation for code sign (<a href="https://docs.fastlane.tools/codesigning/getting-started/" rel="noreferrer">https://docs.fastlane.tools/codesigning/getting-started/</a>) 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.</p>
  
  <p>The options are:</p>
  
  <ul>
  <li><code>match</code></li>
  <li><code>cert</code> and <code>sigh</code>   </li>
  <li>Xcode's codesigning feature   </li>
  <li>Manually</li>
  </ul>
  
  <p>My dissertation so far:</p>
  
  <ul>
  <li><p><code>match</code>:</p>
  
  <ul>
  <li>Setup and the use is more difficult than other options, but there is a guide: <a href="https://codesigning.guide/" rel="noreferrer">https://codesigning.guide/</a></li>
  <li>It looks to me the most "professional" option.</li>
  <li>I know that with existing project it revokes the current certificates.
  
  <ol>
  <li>Does it mean only the first time?</li>
  <li>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 <a href="https://medium.com/@jonathancardoso/using-fastlane-match-with-existing-certificates-without-revoking-them-a325be69dac6" rel="noreferrer">this</a>). 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.</li>
  </ol></li>
  <li>For this setup you need a private repo to store the encrypted certificates.
  
  <ol>
  <li>When I was discussing this with my Android colleague he was very surprised to use a versioning system to store certificates.</li>
  <li>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 <code>match</code> to have a working development profile. Not sure about the benefit to release to Testflight/Appstore.</li>
  </ol></li>
  </ul></li>
  <li><p><code>cert</code> and <code>sigh</code>:</p>
  
  <ul>
  <li><p>To use it just requires a couple of lines before build_app:</p>
  
  <pre><code>get_certificates         # cert
  get_provisioning_profile # sigh
  build_app
  </code></pre></li>
  <li><p>It downloads the certificate and profile in the root of the project.</p>
  
  <ol>
  <li>I guess there should be a way to specify where to put them instead of there, maybe?</li>
  <li>We should ignore this files or clean the repository after that. I don't think they should be commited to the repository.</li>
  <li>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.</li>
  </ol></li>
  </ul></li>
  <li><p>Xcode codesigning feature:</p>
  
  <ul>
  <li><p>Give to the build_app extra parameter:</p>
  
  <pre><code>build_app(workspace: "Chordify.xcworkspace", scheme: "Chordify", export_xcargs: "-allowProvisioningUpdates")
  </code></pre></li>
  <li><p>This is equivalent as having Automatically Manage Signing on Xcode (but on command line is disabled by default)</p>
  
  <ol>
  <li>Does this setting make sense for a CI?</li>
  <li>I guess it also requires this Appfile with app_identifier, apple_id and so on.</li>
  </ol></li>
  </ul></li>
  <li><p>Manually:</p>
  
  <ul>
  <li>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.</li>
  </ul></li>
  </ul>
  
  <p>Fastlane has a set of real examples so you can see their Fastfile, Appfile, Gymfile, Metadata, ... (<a href="https://github.com/fastlane/examples" rel="noreferrer">https://github.com/fastlane/examples</a>). This is awesome, however, there is no common pattern and I cannot see the reasons they went for this or that approach.</p>
  
  <p>Other general questions I have regarding code signing with Fastlane:</p>
  
  <ul>
  <li><p>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?</p></li>
  <li><p>Security vs practicality vs ease of use/setup. Are these concepts tight to one method or the other?</p></li>
  <li><p>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; ...)</p></li>
  <li><p>Last but not least... Are there any special considerations for a CI environment regarding code signing?</p>
  
  <ul>
  <li>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</li>
  </ul></li>
  </ul>