以前的作法

在以前要用 Auto Layout 來設置 UIScrollView 的 sub views 並不是一件讓人愉快的事情，雖然不複雜，但步驟就是有點麻煩。因為 scroll view 自身的特性，所以必須設定它本身的位置與尺寸，然後設定 sub views 的位置與尺寸，最後算出 contentSize 的尺寸。總結來說大概分成以下幾步：

1. 設定 UIScrollView 本身的位置與尺寸
2. 建立一個 contentView 並加到 UIScrollView 的 sub view
3. 設定 contentView 的位置，通常是四邊都貼齊 UIScrollView
4. 可以滾動的 sub views 都加到 contentView，然後用 auto layout 設定這些 sub views 的位置與尺寸
5. 如果設定無誤的話，contentView 就可算出正確的尺寸，這就是 UIScrollView 的 contentSize

最讓人困惑且忽略的就是第三點，因為它很不自然，但在 UIScrollView 卻又是必須的。另外就是第四點，一定要有明確的位置跟尺寸，這樣才有辦法算出 contentSize 給 UIScrollView 使用。

現在的作法

從 iOS 11 開始，UIScrollView 多了 frameLayoutGuide 跟 contentLayoutGuide 這兩個方便的屬性，讓我們不必再用不自然的方式去設定 content 的 auto layout。

1. 可以使用舊有的方式或是使用 frameLayoutGuide 設定 UIScrollView 本身的位置與尺寸
2. 不需要額外的 contentView 了，直接把內容加到 sub view
3. 這些 sub views 與 contentLayoutGuide 建立 auto layout constraints

整個設定流程變得自然許多，也更不容易出錯。現在我們只要確定 sub views 有設好明確的位置與尺寸，讓系統能夠算出 contentSize 即可。

我們的 codebase 有用到放在 GitHub private repo 的 Swift package，為了讓 Xcode 能夠存取 private repo，必須讓 Xcode 認得 SSH key 才行。

因為 Xcode 只支援 RSA / DSA / ECDSA 這三種演算法的 SSH key，但 GitHub 不支援 RSA 跟 DSA 了，所以我們只剩下 ECDSA 可以用。

如果當時按照 GitHub 的文件建立 SSH key，它很有可能是 ED25519，這個演算法 Xcode 認不得，所以我們要新增一個新的 SSH key。

最近剛好有機會要整合 Unity 到 SwiftUI 開發的 app 裡頭，整個過程不算難，但是蠻繁瑣的。網路上的資料絕大部分都是跟 Objective-C / UIKit 的整合，比較少 Swift / SwiftUi 相關資料，所以趁著記憶猶新的時候把它記錄下來，希望可以幫助到其他人以及未來的自己。

從 Unity 2019.4 的版本開始，它提供了 UaaL (Unity as a Library) 功能，可以把 Unity 專案匯出成 framework 讓其他程式使用，開啟了原生平台與 Unity 互動的更多可能性。你可以只用 Unity 開發遊戲或其他精美畫面的部分，剩下的則是使用原生平台（例如 iOS 或 Android）開發。

我使用的開發環境是 Xcode 12.5 + Unity 2020.3.15f2 LTS，預期達成以下目標：

1. 在 SwiftUI 顯示 Unity 的畫面
2. iOS 跟 Unity 可以雙向傳遞訊息

先附上 sample code。這篇文章會有大量程式碼，也會假設你對 Xcode 跟 Unity 的操作有基本的認知，廢話不多說，讓我們開始吧！

好幾年前我曾經寫過一篇讓 Xcode 專案易於版本控制的方法，它非常的好用，我也在多個專案裡頭使用這樣的配置用了好多年，都沒有出過什麼問題。

直到最近遇到了 SwiftUI 的 Preview 功能。

猜測可能是因為原先的設定是在 Build phase 去執行排序的 script，導致它破壞了 SwiftUI Preview 的一些機制，我想到了幾個解法，像是

• 不要放在 Build phase，放到 Run phase 去執行。
• 改用 XcodeGen 之類的工具產生 project file。
• 使用 git hook 的 pre-commit 來執行排序。
• 不要用，等真的遇到 merge conflict 了再說 lol

最後我選擇了 pre-commit 的做法。

下載

不要透過 AppStore，因為速度太慢太不穩定了，要去官方網站下載才快。但是我們還有更快的方法，可以透過下載軟體同時開啟多條連線下載，我推薦使用 XcodesApp 或 Downloader-for-Apple-Developers，前者比較漂亮，後者還可以下載 WWDC 的影片。

安裝

不要直接解壓縮 xip 檔，這樣會花很長的時間。下指令去解會快很多：

xip -x Xcode.xip

管理

可以放多個不同版本的 Xcode 在 Applications 資料夾，只要名稱不一樣就好了，記得要下指令來指定要使用哪個版本。

sudo xcode-select -s /Applications/Xcode.app

時間久了之後，會產生很多沒再用的檔案佔用空間，我們可以使用 DevCleaner for Xcode 或 XcodeCleaner-SwiftUI 來幫忙清理，效果非常的好！

參考資料

安裝 Xcode 的正確姿勢

在 WWDC 2018 蘋果推出了 Create ML ，讓開發者可以輕鬆的建立並訓練適合自己需求的機器學習模型，它支援圖片、自然語言、表格資料的學習。最近這幾天我就想到要訓練一個自家的模型，用來檢查使用者是否打算上傳不恰當的圖片。

最近升上 Swift 4.2，發現我用到的 Pods 有些還沒支援 4.2 導致編譯錯誤。解決方法也很簡單，只要指定每個 Pod target 的 SWIFT_VERSION 為 4.0 即可。

但是我們不能手動在 Xcode 裡頭調整，因為 CocoaPods 會把 Pods 的 SWIFT_VERSION 設為跟你的 project 一樣，所以下次 pod install 又會被改掉。

蘋果在 WWDC 2015 上發表了 App Transport Security (ATS)，大力推廣網路安全連線。對於這樣的發展，我個人是樂見其成的，也相信在蘋果的影響力之下，安全連線也會進一步的普及。

不過對工程師來說，這代表你又要修改程式，以便符合蘋果規範了。在修改的過程中，我就遇到了一個問題：Release 版的 app 是會走安全連線的，但在 Debug 的時候它是連到本機(localhost)，這不是安全連線。該怎麼讓它在 Release / Debug 都能正常連線呢？

這個方法的步驟如下：

1. 建立一個 .gitattributes 檔
2. 輸入 *.pbxproj merge=union
3. commit 這個 .gitattributes 檔

這些動作告訴 Git 「針對 .pbxproj 檔要使用 union 的 merge 策略」，翻成白話就是「要包含對方的修改跟自己的修改」。

在之前的文章裡頭，我們已經將檔案照檔名排序了，所以當遇到合併衝突的時候，可以安心的包含對方的修改跟自己的修改。

參考來源

若是你有多人協同開發 Mac/iOS 專案，並且有使用版本控制系統的話，一定會在合併 Xcode 專案檔時吃到不少苦頭，一個不小心就會誤刪某些檔案的參照，或是重複某些檔案的參照。

最近發現一個好用的 script，可以用它來幫忙「根據檔名排序」專案檔裡頭的檔案。原本你的專案可能是混雜了檔案與群組資料夾，但經過這個 script 排序之後，專案會變成所有的群組資料夾排在最前面，接著才是檔案，而且群組資料夾裡頭的內容也會被排序。

因為被排序過，所以在合併不同版本的時候，就可以容易看出哪些項目是新增或刪除，若是不小心重複參照了某些檔案，也比較容易找出來。