今天又折腾了下 Swift 包管理。
目前是用 CocoaPods，其实也没太大问题，但总觉得 对代码的侵入太强。这不，iPaste for iOS 起了个新项目，想换个清爽点的，于是就又折腾了下。
除了 Pod，主要有 2 个选择：Carthage 和 Swift Package Manager. 后者现在还太嫩，仅适合 Swift 项目，很多第三方并不支持，遂放弃。
那就来到了 Carthage；其实 Carthage 并不复杂，实质是下载第三方库的源码、本地编译为 Frameworks. 剩下的事情，就要开发者自己手动操作了。其实手动也没什么，就是把 Frameworks 作为 Linked Frameworks 加入项目中，并在编译时复制入 .app.
为什么不用 Embeded 方式呢？因为毕竟第三方库是会变的，如果用 Embeded 相当于写死了版本，后续升级时有些麻烦。当然，也是可行的。
这里就可以看出 Pod 和 Carthage 的二点不同：
-
Pod 实质是使用源代码集成
- 好处：在写代码时可以方便跳转至第三方库的源码中
- 坏处：编译速度慢，尤其是全新编译或打包时
-
Carthage 实质是使用 Framework 集成
- 好处与坏处，正好与 Pod 相反
- 不过，在集成 dYMS 后，也可以在调试期间跳入第三方库的源码中，但依然不能在写代码时跳转
Carthage 这里有个坑：Swift 编译器版本。
- 如果你电脑上仅有一个 Xcode，没什么问题。而如果你同时安装了 Xcode Beta、又恰巧要为 Xcode Beta 的项目添加依赖，就有问题了。
- Carthage 默认是用
xcrun swift --version所得到的 Swift 版本进行编译的。而默认情况下，这个肯定是 Xcode 而非 Xcode Beta 的运行环境。再来个而，Swift 3.2 的项目，是无法引用 Swift 3.1 编译器编译出来的 Frameworks 的。 - 解决方案也很解决，使用 Xcode Beta 中的编译器即可。只是，貌似 Carthage 并没有相关的参数方便地切换（比如，我试了
TOOLCHAINS=com.apple.dt.toolchain.Swift_3_2 carthage update --platform iOS来指定 Swift 编译器版本，不过貌似并没有干活），最后比较土的先将 Swift 默认编译器改为 Xcode Beta 版本，编译后再改回来。
sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer
carthage update --platform iOS
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
Carthage 这么简洁美好，万万没想到，最后还是倒入了 Pod 的怀抱。
因为 Firebase 只支持 Pod 方式集成？！
根本原因是，Firebase 并没有完全开源，部分代码只能用静态库的方式发布。而 Carthage 目前对静态库的支持并不好（虽然网上也有人成功了，但毕竟不是官方支持，有些麻烦，放弃了）
早说嘛，我就不折腾 Carthage 了，何必呢？
另外，还折腾了 iOS 与 macOS 项目间共享代码。因为我不想将二者放在一个工程里，怕同时调试时麻烦，就分为 2 个项目了。现在看来，主要有如下方式集成：
- 创建本地 Pod 项目
- 好处是可以方便跳入源码，道理和上面介绍的一样
- 坏处是，创建本地 Pod 项目，麻烦啊
- 最后，还是用了这个方式
- 使用 Frameworks + Carthage 集成
- 好处是集成简单
- 坏处也是 Carthage 本身的限制：看源码麻烦
- 共享相同的源码文件
- 由于我是自己写代码，不需要和别人共享，这也不失为一条路。
- 而且，这个方式最简单。
总算，这个事情有了结论，明天可以静心地优化 iOS 与 macOS 间的数据同步了。
博客原文：0830 - 迂回于 Swift 包管理
