在 Xcode 中采用 Swift 软件包

下午好 我叫 Anders 我在 Xcode 工作

在这次会议中 我和我的同事 Balraj 将谈一谈如何从 Xcode 项目 使用 Swift 包

Swift 包管理器 是 Open Source Swift 工具链的一部分 它在 Swift 3 中被引入 之后 有很多 Swift 包 被创建出来

同时 也有很多 Open Source 函数库 被写入其他包管理器 被改编得与 Swift 包管理器相兼容 Swift 包让你可以 管理你依赖的版本 保证你依赖的包更新时 你在不需要 将代码受制于 源分解改变的情况下 修复 Bug

Swift 包对于你自己来说也是一个很好的方法 可以在你自己的 App 中分享代码 不管是在一个小团队内 一个大组织内 或者在你自己开发的 App 间

现在在 Xcode 11 中 你可以直接从 Xcode 项目 获取访问 Swift 包的权限

我们也很激动 在这次会议中 我们将首先谈谈 如何使用一个包 以及如何通过使用一个包 扩展 App 的功能 然后我们将谈一点 关于包中到底有什么 它们如何构建 数据储存中有什么 在文档形式的包中

当我们谈论包解析时 就是关于 Xcode 如何 取得包的正确版本 并将其嵌入你的 App 中 然后我们将谈一点 关于如何更新包的事情 当包的一个更新版发布时 会发生什么 你又该如何 利用这一点 我们还将谈论 解决在你更新包时 可能发生的 任何版本的冲突

所以让我们 从扩展 NAP 功能 来利用包开始

在这里 我们有一个小的 iPhone App 简单地展示了 在我工作的附近的 咖啡厅的午餐菜单 我们看到这里有两个入口 这是一个 SwiftUI App 我不需要运行我的 App 就可以看到预览和 Xcode

所以我们可以看到 两个不同地方的午餐菜单出现了 在这个 App 真实的版本中 我们可以在网络上提取这个数据 但是在这个演示 App 上 我只是在我的源中将其作为本地文件 所以你也可以说这个菜单是本地采购的 所以这两个 JSON 文件 出现得很好 但是这里的这个咖啡馆 更加现代和高档 所以他们有一个 YAML 菜单 对吗 我们不能解析它 我们不再看这个了 我们来看一看加载这个数据的源代码 我们看到在这里我们处理 JSON 但是不处理 YAML 幸运的是 我知道一个函数库可以很好地解析 YAML 它也有一个很好的 Swift 界面 被称为 Yams 我将使用它

为了使用它我下拉了文件菜单 我来到这个新的 Swift 包子菜单 添加包依赖 现在这个子菜单 有很多其他菜单命令 一旦包出现在你的 App 中 它们就可以处理 但是你说到包依赖 在这里 我看到 因为我为 Xcode 的偏好 添加了我的 GitHub 账号到 Swift 我在那个账户中 看到了所有的包仓储 我还可以看到其他 我标星的仓储

在这个例子中 我将 Yams 标星 但是我还可以 如果有针对一个包的 URL 我可以将其输入这里

在这个例子中 我将 点击说明链接 00:04:01.736 --> 00:04:04.056 A:middle 然后来到 Yams 项目的主页

这个看起来不错 我将看一眼 API 这看起来是我需要的 现在 当然了 当你使用一个 Open Source 函数库时 你将把其他人的代码 代入你的 App 所以有很多你需要仔细处理的事情 你要保证你信任 那个包的源 你想要保证 你明确知道函数库在做什么 所以你不会有任何惊讶 你还想要保证 这个 Open Source 函数库的许可证 与你的 App 的许可证是兼容的

这些我都完成了 我将要回到 Xcode 在这里我将要点击下一步 我们将添加一个引用 一个在 Yams 上的依赖

现在 Xcode 向我展示了可用的版本 它自动将我设定为 使用包的最新版本 在之后我们将更多地谈到 关于这个选项的细节 但是通常来说 这里的默认选项往往是你想要的那个 它使用了版本 2.0.0 一直到 但是不包括 下一个主要的版本 我将要点击下一步

现在 Xcode 在提取 Yams 包的内容 它为我预选了单一的产品 有些包可能会有超过一个产品 这个例子中就只有一个 这是一个函数库 和包的名字一样 如果在你的项目中 有超过一个的 App 你可以选择你想要超链接的地方 在这个例子中 就只是这个一个 所以我将把它链接至午餐 App 我点击完成

现在我们看到这里有一些东西 在我的项目编辑器中 Xcode 为 Yams 包依赖 添加了对新的 Swift 包标签的引用

我们还可以看到 Yams 包 在 Swift 包依赖部分下方出现

我们不会现在就去看那个包 我们晚一点再来看 我们接下来要做的 就是再次回到食物菜单 现在 我们将要在我们的代码内利用它 所以我将在这里输入 “import Yams” 我们可以看到我们有针对输入名字的 代码完成 我还可以按住 Command 键点击 这个输入陈述 我可以跳至定义 这里我们可以看到 对 Yams 项目的界面文档的 渲染版本

所有这些都来自于 包含在包中的 源的文档评论 所以我回到我的代码 我将在这里加入另一个例子 case "yaml"

我将输入 YAMLDecoder 我有对于所有的函数库方法的 代码完成 我还有快速帮助 因为包将其包含在内 根据你得到支撑的质量 这个看上去和感觉上就像是 嵌入 API 我将使用这个方法 我将使用 JSON 例子中相同的最初的参数 现在这个 API 似乎获取了字符串 而不是数据 所以我将使用这个 我不需要第三个参数 因为我将只使用默认数值 所以现在我再次重新回到列表视图 因为这是一个很大的变化 导入一个新的模块 我将点击继续 Xcode 将在后台重新构建 App 我将在这里看一下预览 现在我们可以发现 我也可以看到在 YAML 数据文件的内容 好的 现在我要把这个 指派到我的仓储

我们可以看到我们期望的东西 我们看到了源变化 让我把它变得更大一点 我们可以看到我做的源变化 当然这也是 指派表单的一部分 我们也看到项目文件改变了 因为我为 Yams 包 添加了引用 我们还在这里看到了另外一件事 那就是 Xcode 创建了一个 名为 SwiftPM 的目录 这是针对 Swift 包管理器的 在共享的数据之下 在工作空间之下 你想要将其记录 因为我们之后 会讨论在这里面究竟有什么 但是 Xcode 存储了 解决的包版本的信息 你还想要检查 这样你团队中的人 就可以得到相同的版本 好的 现在我们检查然后输入 Use YAML Menus

好的 现在让我们回到幻灯片

好的 我们已经快速地看了一下 如何从一个项目中 使用一个开源包 我们再仔细看看 YAML 包中有什么

这个包是一个 包含 Swift 包清单的目录 这个清单是一个名为 Package.swift 的 文件 它将那个目录 定义为 Swift 包 它还包含了源 当然了 为了保证这些源能够 继续运行良好 还包含了单元测试

在源之下是针对 包中每个分别的目标的子目录 这些是包中 分别的可构建的成分

相似地 在测试目录之下 还有针对每个测试程序组的子目录

所以 让我们仔细看看 在目标目录之一中有什么 每个目标都可能有 C 语言或者 Swift 的实施 在 YAML 的例子中 还有一个核心的 CYaml 解析 是由 C 语言写成的 它可以包含 Objective-C++ 文件 在分别的目标中 还有一个 Swift 界面 除此之外 它会调用 CYaml 代码 然后这些单元测试被写入在 Swift 中

如果我们看到 Swift 包清单的内容 这里的第一行是 包需要的工具版本的声明 这说明了可以解析这个包的 最低版本 可以清楚显示

包描述 API 是一个由包管理器的包描述函数库 提供的宣告型 API 通过导入它 这个文档剩下的内容 可以宣告包的特点

这包含了包的名称

它还包含了 列出了包向客户出售的 产品名单 所以包可以控制 哪个代码的部分 可以直接由客户导入 在这个例子中 有一个函数库的名字和包一样 叫作 Yams 之后我们会谈到 目标部分 它基本上说明 这个函数库 为客户发布了 Yams 目标

目标部分列出了 包中的个别的可构建的部分 正如我们在这里看到的 在源文件夹和目标之间 有一个一一对应的匹配 每个源文件夹 都可以拥有针对有组织的目标的 子文件夹 但是源下的最高等级是 一个包一个文件夹 一个目标一个文件夹

在这个例子中 我们可以看到 CYaml 目标没有依赖的被列出来 而 Yams 目标则 依赖于 CYaml 目标 这意味着当产品 涉及到 Yams 它将反过来间接地引进 CYaml 这里有一个针对单元测试的 测试目标 这个代码不会链接给客户 但是有必要确保 你的函数库正常运行 在这个例子中 Yams 包清单 同样也列举了 一些与代码相兼容的 更旧的 Swift 版本 这也有其他你可以 在这个声明性语言中 指定的特点 这些我们之后会谈到 当你构建和运行你的 App 时 这个是如何 链接到你的 App 的呢 你的项目由源文件构成 这个可以是 Swift 也可以是其他语言 你依赖的包 它们也同样是源文件 Xcode 做的就是 拿下所有的这些的源文件 遵守它们 尤其是以 与你项目中的 App 代码 相兼容的方式遵守包代码 所以这个包含体系结构平台等 如果需要的话 它会根据你的 App 的需求 重新编译多次 然后将其链入 然后把所有这些都融合在 App 中

包函数库在默认情况下是静止的 所以所有的代码 都链接在了一起

在你项目中 使用相同包的多种 App 也重复这个过程 如果你有一个 iOS App 和 watchOS App 它们使用 相同的包 Xcode 可能会 根据需要为每个 App 构建代码

现在 我们看到了一个 项目可以依赖于包的例子 我们也看到了这个在 目标编辑器中的包依赖部分展示 但是一个包同样可以依赖于其他包 它也可以通过 包清单完成

所以 Yams 曾经没有的 包清单的一个部分是 依赖部分 之所以没有是因为 它实际上并不依赖于其他包 但是你有的一些包可能需要 所以包依赖图表 可以包含直接和间接依赖

之前我提到了 你可以用包管理器 来管理你的版本了 这里使用的是 Semantic Versioning 这是一个广泛运用的策略 它将语义指派到 三部分版本的 每一个成分

在这个例子中 比如说 当 API 发生了破坏性的变化时 主要的版本都会增加 所以这是会让 客户进行改变的事情 比如说 如果你重命名一个方法 或者移除一个方法 或者如果一个包 做出了一个语义变化 让现有的客户必须去适应

这就是为什么 限制的初始版本 一直上到但是却不包括 下一个主要版本的数字

一个包较小版本的数字 在功能不破坏现有客户的 情况下添加时会被增加 比如说 这个可以添加一个方法

最后 补丁版本是 没有语义变化 语言意义变化时 Bug 被修复 包可以很安全地 更新至 Bug 修复 在不改变 App 语义时 将 Bug 修复嵌入

好的 我们已经看了如何使用包 我们也仔细看了那些包 现在我要邀请我的同事 Balraj 来到台上 从细节上讲述一下包解析 谢谢 Anders 包解析是 Xcode 选择在你的工作空间 应该使用哪个版本的包时 经历的过程 我们将更仔细地 看一看它是如何 在早前 Anders 展示的午餐项目中工作的

所以在 Swift 包标签的 项目编辑器中 我们可以看到 我们的午餐项目对 Yams 的依赖 使用版本 Rule 2.0.0 - Next Major 也就是 Yams 从 2 开始往后的版本 但是不包括 3 在项目导航器的 Swift 包依赖部分 我们可以看到 2.0.0 版本的 Yams

我们再仔细看看这个

午餐项目选择 2.0.0 版本的 Yams 因为它的版本要求 2.0.0 直到 下个主要版本

如果版本 2.1.0 存在 Xcode 会选择它 因为 2.1.0 是适合 我们版本要求的最新版本

然而 如果版本 3.0.0 存在 Xcode 不会选择它 因为它不适合 我们指定的限制

在这个例子中 2.1.0 和 3.0.0 都是假设的案例 在接下来的演示中 你还会看到 Yams 继续 在版本 2.0.0 中解析

在这个例子中 还有一个有一个版本的包 可以用来选择 让我们看些更有意思的例子 在这里 包解析 可以变得更加的复杂

这就是我们今天要讲的午餐 App 它有一个很基本的 UI 正如我们刚刚所说 它只使用一个包

我的团队 全力以赴地 为我们的 App 添加了更多的包 它们用这些包 在我们团队所有的 App 中 展示相同的设计主题 当我们回到午餐 App 在几周之后 我们可以看到 UI 已经更新了 在我们的工作空间内 还有三个附加的包

这三个包是 DesignFont DesignTheme 和 DesignColor 它们都在它们分别的版本中解析 所以 Xcode 在选择这些 包的版本方面 为我们做了很多工作 但我想要知道 为什么这些包解析这些版本 为了这样做 我回到项目编辑器

这是 Swift 包依赖部分 我们可以看到 在 DesignTheme 上的新依赖 伴随着版本 Rule 1.0.0 - Next Major

Xcode 在这个例子中 在 Version 1.0.0 选择了 DesignTheme 因为它从 1.0.0 一直解析到下一个主要版本

所以我们可以看到 在 Yams 上的依赖还是一样的 你可能会想 在这个例子中 DesignFont 和 DesignColor 在哪呢 我们看向项目编辑器 但是却没有在里面找到它们 好的 这个的原因是 项目编辑器 向我们展示了 午餐 App 和它的直接包之间的直接依赖

为了看我们包的依赖 我们想要去看一下 DesignTheme 包 这是因为它是最新的 加入到我们的工作空间的包 假设它们不是来自 Yams 也很安全 为了这样做 我们回到高级的 Xcode 视图 在 Swift 包依赖部分下来看 我们可以看到我们的 包 DesignTheme 我们显露了包 然后看到了包内所有可用的内容 在这个例子中 我们想要看一下 Package.swift 清单文档 因为在这里我们会看到 所有关于这个包的 依赖信息

所以我们来看这个文件 在依赖阵列 我们看到了 DesignFont 和 DesignColor 还有它们的版本要求

DesignFont 根据我们之前看到的 进行解析 从 1.0.0 一直到之后的主要版本 所以 Xcode 会选择 版本 1.2.0 因为它是包的最新版本

DesignColor 的解析则有一点不同 它使用的是 1.0.0 版本 一直到下一个次版本 这意味着从 1.0.0 到设计颜色的版本 然后一直到但是不包括 1.1.0 这通常用于当包想要 比它们在更新的时候 获得的新版本 更加保守一些 所以 Xcode 选择了 DesignColor 包的 1.0.1 版本 所以这是添加的包 以及为什么它们 要在这个版本解析的全视图 你会记住 Anders 在之前的展示中 的最后一步就是导入 Yams 然后使用它的 API 让我们来看看它是如何运行 以及它如何与包解析相关联

我们所有的包都是有相同名字的生产函数库

我们可以看到午餐 App 从 DesignTheme 导入内容 也从 Yams 导入内容 DesignTheme 函数库同样也从 DesignFont 和 DesignColor 导入内容

如果我们完整地看这个图表 我们可以看到 它与包解析的工作过程 是很相似的 这是有意的 当我们在我们的包上 添加直接的依赖时 我们也不再导入它们的内容 同时实际上在我们的 App 中 使用 API 但是如果我想要 从一个子依赖中 导入内容到我的项目怎么办呢

让我们谈谈如何这样做

我们有依赖于 DesignTheme 的午餐项目 DesignTheme 依赖于 DesignFont 包 DesignFont 包 生成了一个有相同名称的函数库 在这个环境中 我们不想立刻从 DesignFont 导入内容到午餐 App 因为如果 DesignTheme 失去了对 DesignFont 和 Update 的依赖 Xcode 也会失去 对 DesignFont 的引用 所以现在 我们不能 使用 DesignFont 函数库

所以这样做的一个更好办法 我们回到例子的开头 就是创建一个 在午餐项目和 DesignFont 包之间的 直接包依赖 然后我们可以从 DesignFont 导入内容至午餐 因为如果 DesignTheme 在更新中 失去了对 DesignFont 的依赖 我们还是会保持 对 Xcode 内的函数库的引用

这就是 Xcode 如何 选择你的包的不同版本 我们来看看你如何开始 获得这些包的新版本 它提供了 API 提升和 Bug 修复

某天 我与维护 DesignFont 团队 共进午餐 他们告诉了我一个 DesignFont 包的新版本 它有一些小的 Bug 修复 版本 1.2.1 当我回去的时候 我发现 DesignFont 在使用版本 1.2.0 午餐项目在版本 1.2.0 使用 DesignFont

所以我想要更新这个包 为了实现这一点 我点击了文件 Swift 包 在这里 关于 Swift 包 我有很多选项 在这个例子中 我想要更新至最新的包版本

所以继续然后点击这个 更新运作开始了

我们现在使用 DesignFont 版本 1.2.1 那么更新的包版本 到底都做些什么呢 在更新运作中会发生什么呢

有一个文档名为 Package.resolved 对于这个是很重要的

Package.resolved 记录了 你的工作空间内的 所有包的版本信息 当你完成更新 这个文档被更新了 那么 Xcode 会为你拉下新的版本

这些文档存在于 xcsharedata 它一般由你的团队和源控制共享 所以需要注意的一个很重要的事情 就是我们运行的更新行为 是一个本地行为 为了在我的团队 分享这个更新 我必须指派和将我的变化 放至 Package.resolved 文件

如果你想要 自己寻找所有的东西 这个在 Xcode 项目文件中 但是请注意你不需要 自己编辑 Package.resolved 文件 Xcode 会为你做一切的事情

正如我之前说的 我们并没有与我们的团队分享这个更新 所以让我们来这样做吧 我们可以通过来到 源控制菜单和点击提交 00:23:46.576 --> 00:23:47.936 A:middle 在 Xcode 中完成这些

在这里面我们可以看到 对 Package.resolved 文档做出的所有变化 以及它是如何从我们之前使用的 版本 1.2.0 更新到 新版的 1.2.1 的 因为我想要推送 我继续然后点击了 左下侧的复选框 推送至 remote 端 然后我就可以指派和 推送我的变化了 我们成功地 在我们的团队中分享了这个更新

这些都没有回答问题 为什么我们需要一个 Package.resolved 文件

这个文件存在是 为了保证 我团队的人 在相同的指令中使用午餐项目 他们都能获得 相同版本的 DesignFont 如果这个文件 这个 Package.resolved 文件 并不存在 最终的情形可能是 你团队的多个人 都使用项目的相同版本 但是和你使用的包的版本 却不一致

所以在这里有个非常重要的事情 需要注意的就是 检查你的 Package.resolved 文件 不然 你可能最后会 在你的团队中使用 不一致版本的包 所以检查这个文件 是非常重要的

然后要确保去注意 你的包的新版本 然后就是有意地更新 不然的话 你可能会错过你的包提供给你的 一些关键的 Bug 修复以及 API 提升

这就是如何更新包 我们再仔细通过 更先进的例子 来看一下如何解决包冲突 这将我们今天 谈到的很多不同话题都带到了一起

所以我启动了这个项目 来改变午餐 App 中 价格的字体

我想要使用的系统字体 在版本 2.0.0 的 DesignFont 中 是可行的 这使我们团队 拥有的 App 可以使用一致的版本的字体 所以让我们这样做吧 为了使用 DesignFont 包 我们需要在午餐和 DesignFont 间 创建一个直接的依赖 因为版本 2.0.0 的 DesignFont 发布了这个新的字体 我们想要明确地使用那个版本

所以我们来到 Xcode 然后完成了添加包的工作流程 我们在收藏账户中点击 DesignFont 然后是继续 我们选择到下一个主要的版本 因为我们想要 通向任何更新 或者 DesignFont 发布的新版本 然后我们点击继续 在这里 我们遇到了一个 包解析错误 因为 DesignFont 从 2.0.0 到 下一个主要的版本需要新的依赖需求

所以让我们看看 这里在发生什么 同时对其进行调试 调试包解析时 有件需要记住的非常重要的事情 那就是要 看全景图

我们想要考虑到 影响到我们包的所有需求 而不是仅仅 限制于我们刚刚添加的

所以我们退回一步 来看看这个之前是怎么工作的 午餐 App 在版本 1.0.0 的 DesignTheme 有一个很好的依赖 而 DesignTheme 在 1.2.1 版本 直接依赖于 DesignFont 使用版本需求 1.0.0 直到下一个主要版本

然后 当我们添加 午餐 App 和 DesignFont 之间的 直接依赖关系从 2.0.0 直到 下一个主要版本时 我们遇到了 包解析冲突

你将注意到 DesignTheme 对 DesignFont 1.0.0 的要求 直到 但不包括 2.0.0 午餐 App 对 DesignFont 2 的要求 高至 3.0.0 但是又不包括 3.0.0 版本 不能选择一个 同时符合这两个要求的版本

因此 在将 SwiftPM 嵌入到 Xcode 中 你只能在工作空间中 有一个包的版本

这就解释了 为什么我们在这里看到了 包解析错误 Xcode 不可能选择一个 同时满足两个需求的版本

解决这个问题需要 具体问题具体分析 但通常 当我遇到 这样的包解析错误时 我希望查看 可用的包的更新的版本 然后我就查看这些 新版本是否 为它们的子依赖提供了任何更新

在这个例子中 我注意到 有一个 我们还没有 真正研究过 DesignTheme 的版本 2.0.0 所以让我们去 GitHub 看看 我们的 DesignTheme 主题的版本需求

当我们转到 GitHub 时 我们可以查看 Swift 包清单的 依赖关系阵列 这里 我们看到 DesignFont 的版本需求 已经从 1.0.0 更新到下一个主要版本 变成了 2.0.0 更新到下一个主要版本 这与我们 试图在午餐 App 和 DesignFont 之间 添加的版本需求相匹配 因此 如果我们可以 更新 DesignTheme 的版本需求 使其在版本 2.0.0 中得到解决 那么现在我们 就可以心满意足地 在午餐 App 和 DesignFont 之间添加 一个直接依赖关系

我们来开始这样做 更新一下 DesignTheme 的主要版本 以前 午餐 App 使用的是 DesignTheme 从 1.0.0 到下一个主要版本 我们想要改变它 使它现在使用 2.0.0 到下一个主要版本

回到 Xcode 现在 我们只需 单击项目编辑器中的 DesignTheme 包 然后 我们回到编辑版本规则表 在这里 我们之前指定了 1.0.0 直到下一个主要版本 但现在我们想把它变成 2.0.0 到下一个主要版本

我们只要把 1.0.0 换成 2.0.0 然后点击完成 现在 更新操作发生了 我们可以看到 DesignTheme 在版本 2.0.0 中 DesignFont 在版本 2.0.0 中

但这里发生了一件重要的事情 当我们从一个主版本 更新到另一个主版本时 我们会遇到构建失败 这是因为当 从一个包的一个主要版本 切换到另一个主要版本时 可能会发生 API 更改 这可能会潜在地 破坏项目内部的更改

这意味着当你 从一个主要版本更新到 另一个主要版本时 你应该准备 更改一些 API 或者改变 API 在新版本中的包中运行的任何方式

这可以是非常小的改变 也可以是更复杂的改变 在这种情况下 我们已经为你 做了所有的工作 让你在包上花费更多的时间 因此 当我们回到午餐 App 时 我们的构建错误得到了解决 我们成功地使用了版本 2.0.0 的 DesignTheme

所以我们的构建现在成功了 我们想在午餐 App 和 DesignFont 之间 添加一个直接依赖关系 因为现在我们 处于 DesignTheme 的版本 2.0.0 我们可以添加我们想要的版本需求

回到 Xcode 我们 来看看添加包工作流 我们选择 DesignFont 我们选择 2.0.0 到下一个主版本 现在 我们可以将 DesignFont 库与我们的 App 链接起来 现在在项目编辑器中 我们可以看到 我们成功地使用了 DesignFont 从 2.0.0 到下一个主版本

现在我们已经完成了这一步 我们现在可以导入 DesignFont 内部的内容 成功地使用它的函数库 然后 通过一些小小的代码更改 来更新价格的字体

现在我们已经成功地 做到了这一点 并解决了包冲突 我们已经更新了包的 版本 并且我们成功地 讨论了如何在 Xcode 中 调试包解析

所以我们今天讨论了 很多事情

我们讨论了如何 开始在项目中 开源包并快速开始 使用它的 API

我们进一步了解了什么 是包 以及 Package.swift 清单是如何打包的

我们讨论了 Xcode 如何选择在项目中要使用的 包的版本

然后 我们讨论了 如何保持这些版本的 更新并且不断获得 包的新更新

然后 我们看了一个 关于如何解决包冲突的 最新例子 它教会了我们如何调试包 以及如何更新包的版本

今天在 GitHub 上 已经有很多包可用了 我们建议你 仔细查看这些包 看看可以在哪里将它们 合并到现有的 App 中

但我们还没说完 明天 我的同事 Ankit 和 Boris 将做一个演讲 讨论如何创建 Swift 包 这个演讲将更详细地介绍 包是什么 如何编辑包 SwiftPM 开源工具等等 这个演讲会帮助你 在包如何在 Xcode 中工作方面 成为一个专家 你不会想错过的 如果你对于 SwiftPM 团队 有更多的疑问 我们会在这个会议之后的 Swift 公开时间实验室等你们 00:33:04.186 --> 00:33:05.276 A:middle 还有就是

这个星期还有两个会议 一个是周四十二点 在 Swift 包实验室 00:33:09.716 --> 00:33:11.096 A:middle 另一个是周五十二点

有着相同的名称的会议

谢谢你们今天的光临 希望你们能够 度过愉快的一周 谢谢 [掌声]