Xcode13如何通过Swift Package Manager从现有项目创建Swift包

可行性结论 #

完全支持，且是Xcode 13版本重点优化的官方能力，完美适配UIKit技术栈，不需要对现有业务代码做SwiftUI迁移，就能实现迷你应用架构拆分，对大项目构建耗时的优化效果明确。

落地操作步骤 #

• 不需要从零搭建独立包工程：打开现有UIKit项目后，直接在项目导航栏右键选择 New > Package，即可在当前工作区创建本地Swift Package，直接把对应模块的Swift/OC代码、xib、图片、本地化等资源拖入包目录即可，Xcode 13已经修复了早期SPM版本不支持UIKit资源加载、混编的问题。
• 依赖配置成本极低：拆分出的包如果依赖UIKit、Foundation等系统库，只需要在Package.swift中声明对应系统框架依赖即可，主工程Target的「Frameworks, Libraries, and Embedded Content」面板会自动识别工作区内的本地包，直接勾选关联即可，不需要配置远程仓库地址，本地开发时修改包内代码Xcode会自动识别变更。
• 构建优化效果：拆分完成后，没有代码改动的SPM模块不会参与每次全量编译，Xcode会持久化缓存模块的编译产物，对于10万行代码以上的中大型UIKit项目，日常增量构建速度普遍能提升40%以上。

落地避坑提示 #

• 混有Objective-C代码的模块也可以直接拆分到SPM，只需要把需要对外暴露的OC头文件放到包目录下的include文件夹，在Package.swift中配置正确的头文件暴露规则即可，不需要额外编写编译脚本。
• 主工程中自定义的编译宏、Build Setting参数不会自动继承到SPM包，需要在Package.swift的swiftSettings、cSettings字段中单独声明对应编译标记，避免出现符号找不到、条件编译失效的问题。
• 包内的xib、图片资源加载需要调用SPM提供的Bundle.module接口获取资源包，不要直接用Bundle.main加载，否则会出现运行时资源找不到的问题。

可选模块化方案对比 #

如果要选当前环境下的最优路径，可以根据项目现状判断：

• 没有历史CocoaPods组件包袱的项目，优先选本地SPM做模块化，是Xcode 13环境下集成成本最低、和IDE适配最好的方案，不需要安装第三方依赖管理工具，也没有额外的脚本执行耗时。
• 已经用CocoaPods做了部分组件拆分的项目，不需要强行全量迁移到SPM，Xcode 13支持两种依赖管理方式混用，可以先把迭代频率低、代码稳定的基础模块迁移到SPM，逐步降低全量编译范围，迁移成本最低。
• 不推荐用Xcode原生Embedded Framework做模块化，Framework的签名、资源拷贝阶段会增加额外构建耗时，增量编译的缓存命中率远低于SPM包，长期维护成本更高。

内容的提问来源于stack exchange，提问作者Tar journey