今天又折騰了下 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 包管理