SwiftUI 專欄 #0 首先，以 M1 為目標吧

SwiftUI 讀完就入坑 2022/06/03

13 的話

13 的 Apple 開發者電子報正式開闢 SwiftUI 專欄副刊～

這是一個沒有付費牆，但是用付費電子報心態在經營的專欄。

請到 Patreon 訂閱來支持我繼續寫作。訂閱者可以搶先讀到每一篇新文章。

副標題「讀完就入坑」是因為我想用一種輕鬆的氣氛帶讀者認識 SwiftUI。

就算你不熟悉 iOS 開發也可以享受其中。對於還未入門 SwiftUI 的 iOS 老手也會很有幫助。

不需要有資訊焦慮，讀下去就知道。

（回專欄 · 回首頁）

---

為何你要讀 13 寫的 SwiftUI 專欄

SwiftUI 是 Apple 在 2019 年 WWDC 隨著 iOS 13 一起發表的全新 UI 框架。簡單來說就是想透過新的寫法，讓人可以同時開發 iOS、Mac、Apple Watch、Apple TV 的 app。

再過幾天就是 WWDC22，Apple 肯定會發佈大量 SwiftUI 的新功能。作為第四版的 UI 框架，SwiftUI 應該有一定的成熟度了…吧？

關於這點沒人說得準。只能說，SwiftUI 從 iOS 13 以來產生了大量的傷害。許多 iOS 開發者都覺得 SwiftUI 還不成熟。

但這不妨礙我想寫 SwiftUI 專欄啊。一方面是很多人有興趣。另一方面，我踩的坑算是夠多了，覺得大部分問題是因為不了解基本觀念，或是被舊的心智模型（UIKit）給束縛了。一旦跨過幾個明顯的障礙以後，SwiftUI 真的是滿好玩的。至少我是回不去用 UIKit 了。

我有把握帶你跨過那些明顯的障礙，而且內容或方向，其他 SwiftUI 入門教材是看不到的。怎麼樣，有興趣了嗎？

讓我們開始吧。

想不到，這是一個勸敗專欄

首先，要用好（或是玩好、學好）SwiftUI，你需要一台 M1 等級的 Mac。

13 你不是在說笑的吧，「欲練 SwiftUI，先買 M1」？

道理很簡單，你需要夠快的電腦。但請先聽我講個背景。

Apple 推出 Apple Silicon 的 Mac 時，我是最早一批體驗的開發者。申購了 A12Z 處理器的 DTK，驚為天人。M1 正式上市以後，買了 MacBook Air M1 給家人，DTK 歸還 Apple 以後加價買了一台 Mac mini M1。公司發給我 MacBook Pro 13 吋 M1 與 iPad Pro M1。

是的，我家裡有 4 台 M1。

這其中，最了不起的是 MacBook Air M1。最便宜的 Apple 筆電，但是效能、續航力、發熱控制，都超過當時公司配給我的 MacBook Pro 16 吋 Intel Core i9。售價只有一半不到。

M1 是 Mac 電腦 CP 值大爆發的一代。

追求能夠把 Preview 跑好的 CPU 效能

要用好 SwiftUI，最重要的是，寫程式的時候要能夠直接看到畫面。原因我後面再講。這個功能叫做 SwiftUI Preview，或是 Xcode Preview。

Preview 要運作正常，你需要一台夠快的電腦，而 M1 就是我使用多台 Mac 之後確認的最低標準。

當然你要買 M1 Pro、M1 Max 甚至 M1 Ultra 我也不會反對。但是就 CPU 運算能力來說，M1 是很夠用的。

接下來，16 GB 很有用

我當時買那台 MacBook Air 是打算給家人文書使用，所以故意選了 8 GB，想順便了解一下 Apple Silicon 有 UMA(Unified Memory Architecture) 能否用比較少的記憶體仍保有不錯的效能。

結果發現，如果不跑 Xcode Preview，而是把程式跑到手機上，那執行速度確實會比 Intel Core i9 來得快。

但是如果開了模擬器（Simulator）或是 Preview，記憶體就會以每個模擬器 2 GB 為單位被吃掉（Preview 也是模擬器的一種），一下子就不夠用了。

簡而言之，準備一台 M1，選配到 16 GB 記憶體。

為什麼要顧好 Preview？

我應該還沒有成功說服你為了 SwiftUI 把 M1 買下去。現在來說為什麼要顧好 Preview。

SwiftUI 的基本概念是，你寫下的程式碼，是在描述資料與畫面之間的關係。之後只要修改資料的狀態，畫面就應該會跟著改變。（這句話現在不理解或記不起來沒關係。我之後會重複講到烙印在你的腦海裡🤪）

而 Preview 就是一個幫助你把各種資料的可能展現出來、直接看到畫面長相的機制。

你知道嗎，以前很多 iOS 開發者喜歡吵說要用程式碼「刻」出來，還是要用 Storyboard 「拉」出來。

前者是把建立畫面的各個元件並組合的步驟寫出來。後者則是用 Xcode 裡的所見即所得工具──Interface Builder 來排版。

但是這兩種方式我都不喜歡。不管是用「刻」的還是「拉」的，都要到執行階段才能看到結果。在編譯階段時，無法確定畫面是正確。換言之，開發者必須要把程式跑到模擬器或實機，才會看到真實的樣貌。

等待「跑起來」是非常浪費生命的事情。但我們過去都是這樣做，每個循環從幾十秒到幾分鐘不等。

xkcd 這張圖歷久不衰哪。

等待時間很長，間接地造就了許多優質的 iOS 開發者推特帳號。因為他們等待期間不知道要幹嘛就上推特看看新知。（講到這裡，也歡迎追蹤我的推特帳號。那是一個很純的在討論 Apple/iOS 技術的帳號。）

SwiftUI 的出現，瞬間打破了這個現象？好吧雖然我很想這麼說，但至少在 iOS 13 時第一版的 SwiftUI 並沒有。當時 Xcode 11 的 Preview 慢得要命，又常常當機。勸退了不少想嘗鮮 SwiftUI 的開發者。

現在的 Preview 已經夠用

但是現在已經是 Xcode 13、iOS 15。SwiftUI 第三版穩定許多，Preview 在大多數情況都正常了。雖然偶爾要多按幾次才會跑完，但已經是確實有生產效率的工具了。

Preview 的原理是小模擬器，把執行出來的畫面擺在程式碼旁邊。所以它依然是我上面說的「把程式跑起來才看得到真實的樣貌」。但是因為跑的程式僅限於小範圍，所以改動程式碼之後，可以在幾秒甚至一秒內看到排版更新的結果。

每個循環從幾十秒～幾分鐘，縮短到幾秒鐘，我敢說用 SwiftUI 開發 UI 的效率比 UIKit 快上 10 倍。

踩過 SwiftUI 坑的朋友肯定不同意我個說法。「開發 10 倍快但是遇到 SwiftUI 的 bug 解決不了，花上 100 倍 的時間處理，那也沒有比較好啊。」

沒錯。所以之後我會聊到很多 SwiftUI 的坑，讓你對它有個正確的期待。希望這樣可以幫助你在不同需求下，選擇合適的工具來開發。

你也可以用 Preview 來看到 UIKit 的樣貌。因為 SwiftUI 提供包裝 UIView 的功能。不過這方面我就不打算討論了。

我需要準備一台 iPhone 嗎？

考慮到有些讀者是對 SwiftUI 有興趣，但沒有接觸過 iOS 開發，我還是說明一下。

雖然在開發個別畫面時，我們會使用 Preview 與模擬器，app 跑在模擬器與實際在裝置上運作，還是會有一些不同。

學習 SwiftUI 本身只需要 Mac，但如果是開發完整的 app 的話，要有對應平台的裝置，才能確定程式的功能與使用者體驗符合你的期待。

SwiftUI 可以用來開發 iOS app，以及 Mac、Apple Watch、Apple TV 上的 app。所以，想要開發 iPhone app 的話，一定要有一台 iPhone；要開發 iPad app 就要有一台 iPad。不過，如果是開發 Mac app 的話，倒是不需要準備一台 iOS 裝置。

小結

Preview 是 SwiftUI 能達到生產力的必要條件。而 M1 等級的 Mac 則是讓 Preview 夠用的必要條件。學習 SwiftUI 的路上有一些勸退的小怪，但 Intel Mac 動不動就風扇起飛、Preview 跑起來太慢令人失去耐心，肯定是其中的大魔王。

所以，先去弄一台 M1 吧💸

喜歡今天的專欄的讀者，請按下愛心❤️或留言💬，更歡迎直接回信✉️與我交流。我會看大家的反應來調整下一篇的發表時間。

也別忘了到 Patreon 訂閱來支持我繼續寫作。訂閱者可以搶先讀到每一篇新文章。