0830 - 迂回于 Swift 包管理

354 阅读3分钟

今天又折腾了下 Swift 包管理。

目前是用 CocoaPods,其实也没太大问题,但总觉得 对代码的侵入太强。这不,iPaste for iOS 起了个新项目,想换个清爽点的,于是就又折腾了下。

除了 Pod,主要有 2 个选择:CarthageSwift 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 包管理