Swift Package Manager 系列 01｜SPM 的定位与重要性

很多 iOS 开发者第一次真正接触 Swift Package Manager，往往是因为“要接一个第三方库”。 于是很容易得出一个过于狭窄的结论：

SPM 不就是 CocoaPods 的替代品吗？

这个结论只对了一部分。

SPM 当然能装依赖，但如果只把它理解成依赖管理器，就会低估它真正改变的东西。 它正在改变的，其实是 Swift 项目如何定义模块、如何组织依赖、如何建立工程边界。

所以这篇文章我想先把一个前提说清楚： SPM 的价值，不只是“更方便地拿到代码”，而是“更标准地组织代码”。

一、SPM 首先是 Swift 官方的模块系统入口，而不只是一个下载器

很多工具的核心价值来自生态，有些工具的核心价值来自“是不是官方路径”。

SPM 更接近后者。

它的重要性首先来自三个事实：

• 它是 Swift 官方支持的包管理和模块化方案
• 它和编译器、工具链、Xcode 的演进方向是一体的
• 它不只是管理第三方代码，也天然支持管理自己的代码

这三点合在一起，意味着它是在逐渐变成 Swift 工程组织的默认语言。

这和“多一个安装依赖的命令”完全不是一个量级的变化。

二、它真正碰到的是“边界”问题

一个成熟项目真正难管的，从来是这些问题：

• 哪些代码应该独立成模块
• 哪些能力应该被宿主工程直接依赖
• 哪些模块之间可以互相引用，哪些不该引用
• 公共能力和业务能力的边界在哪里

SPM 一旦进入项目，这些问题就会变得更具体。 因为不再只是“在文件夹里分目录”，而是在真正定义：

• 一个模块的公开接口是什么
• 它依赖哪些模块
• 它被谁依赖
• 它应该如何被测试

因此我说 SPM 的核心是逼着更认真地思考模块边界。

重要性上升的原因

很多小项目一开始都能靠“一个 App target + 一堆 group”活得很好。 但项目只要进入中型规模，问题就会开始出现：

• 编译速度越来越慢
• 公共能力和业务代码混在一起
• 模块依赖方向不受控
• 一个改动会触发大量无关代码重新编译
• 很难判断哪些代码是真正可复用的

这时会发现，问题已经是“工程边界不存在”。

SPM 之所以越来越重要，是因为它提供了一条比“继续在主工程里堆目录”更标准的路径。 它让模块边界可以从一种约定，变成真正的工程结构。

四、SPM 和旧时代依赖工具最大的差别，不只是体验，而是角色定位

以前常见的情况是对依赖管理工具的期待很单纯：

• 帮我把第三方库装进来
• 帮我处理版本和集成

但 SPM 很快会把带到另一个层面： 它不仅管理“别人写的库”，也非常适合管理“自己拆出来的模块”。

这个变化非常关键。 因为一旦开始把自己的代码组织成 Package，SPM 的角色就从“安装器”变成了“模块系统”。

这个时候关注的问题就不再只是：

• 能不能装上

而是：

• 模块接口怎么定义
• 内部实现怎么隐藏
• 依赖关系怎么保持单向
• 哪些模块值得独立测试

这正是工程成熟度开始提升的地方。

五、很多团队迟早会走到 SPM

表面上像是它“更新”，实际更接近它更符合现代 Swift 项目的组织方式。

一个团队只要开始认真做这些事，就会天然靠近 SPM：

• 想做更清晰的模块拆分
• 想把公共能力抽离出来
• 想减少主工程过度膨胀
• 想让依赖关系显式化
• 想让模块测试更自然

换句话说，很多团队是在追求工程边界的过程中，最终发现 SPM 是最顺手的承载方式。

六、但它的价值不在“用了就高级”，而在“边界终于能被认真定义”

这里也要防止另一个误区： 这个话题一提起来 SPM，就容易把它和“模块化成熟团队”画等号。

这其实不准确。

SPM 本身不会自动带来好结构。 如果本来就没有想清楚：

• 这个模块为什么存在
• 它暴露什么，不暴露什么
• 它和宿主工程是什么关系

那只是把原来的混乱从主工程目录里搬到了 Package 目录里。

所以 SPM 的价值不在于“用了就现代”，而在于它让很多原本可以含糊过去的边界问题，终于不能继续含糊。

七、它不会自动解决什么

这一点也很重要。SPM 不会自动帮助解决：

• 模块拆得是否合理
• 命名是否清晰
• 依赖方向是否健康
• 某个公共模块是不是抽得太早
• 业务层和基础层有没有混在一起

也就是说，SPM 不是架构师，它只是一个更适合承载良好架构的工具。

如果团队本来就没有边界意识，SPM 最后也可能只是把问题包装得更“现代”。

八、结论：SPM 越来越重要，表面上像是它能装库，实际更接近它更适合承载模块化工程

换个更短的说法，我会说：

SPM 之所以越来越重要，表面上像是它终于让我们少装一个 CocoaPods，实际更接近它让 Swift 项目更容易把模块边界、依赖关系和工程结构变成显式设计。

所以它真正重要的地方，从来不只是“依赖管理”，而是：

• 模块化
• 标准化
• 边界显式化

这才是它越来越值得认真对待的原因。