Continuous Integration Server上的代码签名iOS应用扩展

添加应用扩展程序是在用户需要的地方放置应用程序功能的绝佳方法。 自Apple推出应用程序扩展名以来，将其扩展到iOS应用程序中已变得非常普遍，例如iMessages扩展名非常常见。 在开发iOS应用程序时，扩展程序必须是iOS应用程序中的单独目标，并且在将应用程序分发到应用商店时，我们必须与主应用程序一起对其进行代码签名。

Xcode具有自动对应用程序进行代码签名的新功能。 Xcode会处理所有事情，包括为所有目标下载正确的配置文件并在归档iOS应用时对它们进行代码签名，但是这种方法不适用于持续集成环境（即CI服务器）。 在CI服务器上，我们必须编写所有这些代码签名任务的脚本。 在为带有扩展名的应用程序设置连续交付时，用脚本手动编码所有扩展名的应用程序具有挑战性，但是Fastlane工具非常容易对应用程序扩展名进行代码签名。 在本文中，我们将看到如何使用Fastlane工具在CI服务器上编写符号应用扩展的代码。

应用程式额外资讯

在对带有扩展名的应用进行代码签名时，我们应该考虑以下几点。

• 应用程序扩展是iOS应用程序中的单独目标
• 应用扩展程序具有单独的捆绑包标识符和配置文件
• 应用扩展程序与主应用程序一起构建。

这意味着，我们必须为每个捆绑包标识符下载预配置文件，并使用脚本将下载的预配置文件应用于每个目标。 在这种情况下，让我们考虑具有包标识符com.xyz.main的主应用程序具有带有包标识符com.xyz.main.iMessage的 iMessages扩展名，以与应用程序一起进行代码签名。

叹气下载配置文件

我们必须为每个应用程序标识符下载配置文件，在我们的情况下将是两个捆绑包标识符。 Fastlane具有叹气工具，可以从Apple开发人员门户下载配置文件。 我们还可以保存配置文件，其含义是文件名，但这是可选的。 示例代码如下所示。

  叹（ 
     app_identifier：“ com.xyz.main”， 
     文件名：“ com_xyz_main.mobileprovision”， 
     skip_certificate_verification：正确 
    ） 
  叹（ 
     app_identifier：“ com.xyz.main.iMessage”， 
     文件名：“ com_xyz_main_iMessage.mobileprovision”， 
     skip_certificate_verification：是 
  ） 

请注意，Sigh会将配置文件下载到当前工作目录中。 成功下载预配置文件后，我们应该在项目的根目录下载两个文件com_xyz_main.mobileprovision和com_xyz_main_iMessage.mobileprovision 。

更新每个目标的配置

现在，我们已经为iOS应用程序和扩展下载了相关的配置文件。 现在是将它们应用于特定目标的时候了。 在此阶段，我们可以采取两种方法。

• 通过将供应配置文件设置为与我们将在CI服务器上下载的名称相同的名称，在.xcodeproj文件中应用手动代码签名 。 我们可以在源代码管理中检入该文件，以便CI服务器将查找这些文件。 这将是非常简单的方法，因为我们不需要在CI服务器上修改Xcode项目文件。
• 在.xcodeproj中应用自动代码签名 ，并通过使用脚本更新Xcode项目文件将其更改为手动代码 。 最好在开发人员的本地计算机上保持自动签名并在构建时更改CI上的文件，但是这需要对构建设置有深刻的了解，并需要使用脚本以编程方式更新Xcode项目

您的团队将根据技能集决定哪种方法适合他们。 两者都有其优点和缺点。 开发人员更喜欢在本地计算机上进行自动代码签名 ，因为过去在Xcode 8之前，他们可能曾经历过整理证书和置备配置文件的痛苦。为了CI失去它。

让我们看看如何在本地计算机上保持自动签名并以编程方式更新Xcode项目文件以使用扩展名对iOS应用程序进行签名。 Fastlane通过update_project_provisioning操作使其非常简单。 此操作使用给定的配置文件更新了每个目标。 我们甚至可以使用正则表达式过滤目标。 您可以在此处阅读操作的示例和参数。 我们可以使用下面的代码，使用针对特定目标的下载配置文件来更新.xcodeproj。

  disable_automatic_code_signing（ 
     xcodeproj：“ / path / to / xcodeproj”， 
   ） update_project_provisioning（ 
    xcodeproj：“ / path / to / xcodeproj”， 
    个人资料：“ ./ com_xyz_main.mobileprovision”， 
    target_filter：“ .main。*”， 
    build_configuration：“发布” 
   ） update_project_provisioning（ 
    xcodeproj：“ / path / to / xcodeproj”， 
    个人资料：“ ./ com_xyz_main_iMessage.mobileprovision”， 
    target_filter：“ .main-iMessages。*” ,, 
    build_configuration：“发布” 
   ） 

此代码将首先禁用自动代码签名，并将下载的配置文件应用于每个特定目标。 现在，我们应该能够对带有扩展名的iOS应用进行编码了，没有任何问题。

清理你的狗屎

现在，我们通过更新不同的供应配置文件弄乱了.xcodeproj文件。 我们也将签名从自动切换为手动，以构建带有扩展程序的应用程序。 成功归档构建后，我们可能必须还原一些更改。 您可以根据构建结束时的需求采用不同的方法。 这是构建成功上传到iTunes Connect后采取的一些常见方法。

• 我们可以重新启用Xcode自动签名，这将通过使用Fastlane操作来还原大多数事情。

  enable_automatic_code_signing（ 
     xcodeproj：“ / path / to / xcodeproj”， 
  ） 

这会将Xcode项目设置为针对每个目标自动签名。

• 使用git reset命令重置您在构建期间所做的所有更改。

  sh“ git reset --hard” 

我们还可以使用危险的Fastlane操作reset_git_repo来重置Fastlane弄乱的所有内容。 我不建议您执行此操作，但在某些情况下可能会有意义。

上面的两种方法都会重置在构建期间所做的所有更改，如果您想使用commit_version_bump动作或要在github上推送的其他内容来为版本号提交版本凹凸，则可能没有用。

• 确保以干净的git状态开始构建，以免以前的构建遗留下来。

  before_all做|车道，选项| 
      sure_git_status_clean 
  结束 

这将确保每个构建都以干净状态开始。

结论

CI服务器上的iOS应用程序代码签名很痛苦，如果我们有应用程序扩展或复杂的目标，它将变得更加痛苦。 Fastlane工具使我们的脚本编写工作变得更加容易，以确保CI服务器上的内容正常运行。 只需编写少量脚本，我们就可以完全控制iOS应用和扩展程序的代码签名。

像XCBlog的 XCTEQ 发布的帖子一样 ？ 您可能还喜欢我们的一些服务，例如访客博客或Mobile DevOps（CI / CD）或测试自动化。 在 Github 上 搜索我们的 服务 ，开源项目， 或者在 Twitter ， Facebook ， Youtube 和 LinkedIn 上关注我们 。 下载我们的 XCBlog iOS应用程序以离线阅读博客。

X CTEQ 是一家专门从事基于Mobile DevOps，CI / CD，Mobile，AI / ML的测试自动化Checkout XCTEQ产品和服务的公司， 网址 为 http://www.xcteq.co.uk 或写信给我们[e-mail]。英国..