Swift Package Manager (SPM) 已经被苹果放置于一个很重要的位置,在历史文章中对其做了一定的分析,Package 目前的定位和 Xcode Project .xcodeproj
同级别。SPM 不仅仅用于替代 Cocoapods,而是 Apple 后期语言研发生态的一部分。
鉴于 Xcode 对 Package 的支持,可以很方便的将项目中的代码进行组件化设计,做一定的逻辑分析即可拆分成多个 Package,这在开发过程中非常有利于项目的架构、单测、可持续性。
以前若这样做,需要对 Cocoapods 有深入的了解,这是一个比较复杂且细节的过程。通过 SPM 只需要 New - Package
即可,将复杂度从项目级别压缩到文件级别。
SPM 出现后,很多 Pods 模块通过增加 Package.swift
配置文件可以很方便交由 SPM 管理。但对于直接通过 Package.swift
创建的独立库,并没有方便的方案转为 Pods 管理,还是需要走一遍 Pods 的流程。
不过,这里做一个预言,Pods 终将被 SPM 取代,因为 SPM 是更具有可持续性和生态深度耦合,在 Xcode 整合 (编辑 / 搜索 / 联调等)、多平台兼容,源码管理、二进制库 / 仓库管理、CI 等方面,都具有得天独厚的优势。
相比 Pods 完善的脚本自定义能力 (基于 ruby 的生态),SPM 是有一定的短板,但不推荐。
很多大公司在做统一基建的时候,会深度魔改 Pods。简单的东西越做越复杂的原因,除了增加一些” 又不是不能用” 的功能,还有就是在复杂度提升后打的各种补丁。
虽然这么说,Pods 完善的自定义能力,SPM 也一样可以做到,毕竟这些能力很大部分都属于扩展能力,如插件。执行流程中大家都可以在 xcodebuild 等相关命令的任意位置,随时可以写一些定制脚本做插入执行。
初期,Swift Package 只能做源码 (开源) 共享,后面增加了 binaryTarget
能力,可以在提供了二进制库 (framework/xcframework) 的情况下,直接通过 SPM 做分发。(闭源共享)
但二进制库从哪里来,普遍的方案还是通过 .xcodeproj
的形式编译导出 framework/xcframework 库。
Swift Package 虽然支持导出动态库和静态库,但流程上还不彻底,并不能直接交付使用,下面对此做一些解释说明。