13 報的 SwiftUI 專欄在 2022 年成立時，就是一個付費專欄。只是當時我沒有設立付費牆，而是採用「誠實訂閱」制度。當時就有不少朋友訂閱了我的 Patreon 來支持我寫作，非常謝謝你們！

今年 9 月，我啟動了 iOS Developer+ 會員，寫了很多文章。然後上個月在 iPlayground 講了 SwiftUI，覺得有很多東西可以再跟大家分享，所以這個專欄可以繼續連載了～

今天這封電子報只是新連載內容的開頭，完整的文章以及後續內容請加入 iOS Developer+ 會員來觀看。

除此之外，有一件重要的事情提醒：就是 iOS Developer+ 的年度限定優惠到今天（Cyber Monday）截止。

本來是上週為了慶祝台灣獲得世界棒球 12 強賽冠軍，剛好跟 Black Friday 以及 Cyber Monday 的時間相近，所以我就設定到今天截止。

我的個性沒有很喜歡做促銷，所以請把握機會。

訂閱了就可以看到過去所有的內容，我也會把你邀請到我的 Notion（主要是因為，在 Notion 排版比 Patreon 更好看）。

優惠辦法我寫在文末。

（看前一期 · 回專欄目錄 · 回首頁）

連載再開

SwiftUI 本來就是我很關心且熟悉的主題，之後也會在 iOS Developer+ 分享。

有兩個原因。

一個是 2022 年我就在 13 報寫過幾篇「SwiftUI 一讀就入坑」專欄文章，一直都對於寫 SwiftUI 主題很有興趣。算是連載再開吧！

另一個是，上個月我在 iPlayground 以「Why SwiftUI? Why TCA?」作為開場題目。為了準備，我對 SwiftUI 又有一些更深入的思考與認識。

演講時間只有 30 分鐘，內容非常緊湊。而我在台上的感覺是，很多重點沒有充分傳遞給台下聽眾，有點可惜。

總之，SwiftUI 有很多東西可以慢慢聊。

今天這篇文章我想來講講 SwiftUI 這類框架很重要的觀念──描述性與狀態驅動。

狀態驅動

這是我在 iPlayground 演講時，放了好幾次的投影片。

不知道你是否看得懂這三句話呢？

看得懂的話，表示你瞭解狀態驅動（state-driven），也是 SwiftUI 的重要特性。

如果你是資深 iOS 工程師的話，恐怕反而不容易直覺地去理解。

因為 UIKit 並不是狀態驅動的框架。

🔐後續內容請前往 iosdeveloper.plus 訂閱，取得所有獨家內容。所有文章可以在這裡預覽。

🎉慶祝台灣以 4:0 擊敗日本隊奪得世界棒球 12 強賽冠軍，iOS Developer+ 會員限時 40% Off！

到 https://iosdeveloper.plus 訂閱 iOS Developer+ 並輸入 TEAMTAIWAN 即可獲得第一個月的折扣。

活動期間到台灣時間的 2024/12/2（Cyber Monday）23:59 為止。

SwiftUI 專欄是一個付費專欄，只是我沒有設立付費牆，而是採用「誠實訂閱」制度。

我的目標是累積到 100 位 Patreon 支持者，目前進度來到 28%，感謝新舊朋友們的支持。

（看前一期 · 回專欄目錄 · 回首頁）

前言

相隔一個多月，又與大家見面了。

坦白說，在過去這個月裡，我對 SwiftUI 的感受是五味雜陳，直接導致這個專欄的難產。

怎麼說呢？隨著 iOS 16.0 的正式發佈，開發者社群也發現大量的 SwiftUI bugs。有些 bugs 在 iOS 16 的 beta 版甚至是沒出現過的。那些 bugs 都是 Apple 不該交給開發者的東西。

這就讓我感到為難。雖然這個專欄開宗明義就說是讀完就「入坑」，但這個情況也實在慘烈。

下面我會轉載一些 SwiftUI 在 iOS 16 上的問題，然後談談我對這些現象的猜想。

框架融合的難處

有個觀點不一定對，但我常常講，就是：SwiftUI 這個框架本身的問題其實不多。通常最嚴重的問題都是它跟其他框架串接的時候。

Text、Color、Shape、VStack 這些「原生 SwiftUI」的東西很少遇到問題。

但像是用 UIKit 做的 List，從 iOS 13 以來就是重災區。也是我在 #3 那些不該碰的 SwiftUI API 裡面特別不推薦的功能。

以下兩個 iOS 16 bugs 都跟 List 有關。

List 搭配 ScrollViewProxy 進行捲動，有可能會 crash：

List 有時不會觸發 .task：

Apple 在 WWDC22 指出，iOS 16 裡的 List 實作已經從 UITableView 改成 UICollectionView。

我們可以合理猜想，SwiftUI 工程師在修改呼叫 UICollectionView 那邊，有些情況沒有考慮好。

或者我們也可以說，這兩種截然不同原理類型的框架要融合，天生就有難度？

SwiftUI 的原則是「改變狀態就改變畫面」。要用 UIKit 來實作這個要果，就變成「框架要明確追蹤到狀態改變，並且使用 UIKit 的方式把畫面設定正確」。

那麼這些橋接與融合的程式碼就要面臨挑戰：SwiftUI 的畫面更新週期，能夠與 UIKit 的能夠完全同步嗎？UIKit 的事件能夠完美地傳回 SwiftUI 嗎？

如果有任何一點做不到的話，就是災難的開始。

我沒有用過 React Native，但我猜 RN 在與 UIKit 溝通也會有類似的挑戰。

其他 Bugs

不過下面這幾個問題，我就沒辦法單純用 UIKit 來當擋箭牌了😅

ScrollView（雖說它目前還是 UIScrollView 實作）裡的 lazy View 的狀態沒有維持住。奇怪的是這個 View 裡面有幾層還有差🤔

onPreferenceChange 寫在 .background 裡會壞掉，但是改成放在 .overlay 裡面就正常。這真的顛覆我對這兩者差異的觀念🤯

至於 SwiftUI 在有 ProMotion 的 iPhone 上無法達到 120 Hz，可能只是 Apple 沒有設定好。畢竟 iPad Pro 上的 SwiftUI 一直都可以。

開發者自救會？

框架的 bug 有很多種，但最慘的肯定是「原本好好的，升級之後就壞掉了」這種。

我說的是正統的 API 使用，沒有用 workaround，而且開發者也用了新版的 SDK。但原本的語法或呼叫方式，在新的作業系統壞掉了。

SwiftUI 目前在 iOS 16.0 就是屬於這種。

那麼問題是，在 Apple 還沒修復的情況下，開發者能夠處理這些 bug 嗎？能繞過嗎？

使用 UIKit 的時候，如果有 bug，通常很好繞過。因為開發者有很多招可以使用：

1. 在 runtime 拿到 UIKit 物件的實體，然後針對各種參數進行監控與修改。也就是說，官方的實作有問題，我們就把實際上發生的事情再改成別的

2. 很多時候，延後一點時間來觸發，做到調整畫面更新順序就能解決問題😌

3. 寫下繼承原本物件的新物件，並且覆蓋某些行為。這是標準的物件導向程式給開發者的自由

這 1、3 兩個技巧也可以組合，比如前者就是在 runtime 可以「看到」UIKit 的部分實作，所以才要覆蓋哪些部分。

但是 SwiftUI 的實作是看不到的，它的 API 把這些細節藏起來。

更重要的是，因為 API 是封裝過的。就算開發者用了各種技巧得知某個作業系統版本的實作並加以修改，在下一個版本它被改掉的機率遠高於 UIKit。這方面可以參見本專欄之前的「不要使用 Introspect」。

無奈的就是目前是 Apple 自己把實作改壞，開發者除了換個方式實作（比如把那個部分改成用 UIKit 來寫），也沒別的辦法。

有很多開發者在成熟的產品上不想用 SwiftUI──除非它是開源的框架──現在你可以理解背後的原因了。關鍵就是，在系統框架有 bugs 的時候，開發者有多少自救管道的問題。可能對於這些開發者來說，只要自己無法動手修改，SwiftUI 就只能是玩具。

當然，從另一個角度來說，任何一個處理掉很多 UIKit 細節毛病的 app，裡面應該都是充滿了 workaround 掉 Apple bug 的程式碼🌚 想要有「潔癖」地使用 UIKit 是不可能的，而 SwiftUI 就更不可能了。

結論

我想到 SwiftUI 的坑大概可以分成以下幾種情況：

1. 某個 API 設計地不是很好，所以你得用某種不那麼爽的姿勢使用它

2. 某個 API 沒有開放自訂或參數，所以你得自己重新實作

3. 這個 API 提供新功能，但是在舊版 OS 沒有，所以只能等新版 OS 時才能使用

4. 某個既有 API 在新版 OS 上是壞的

前 3 種坑，我覺得都能隨著開發經驗的增長，學會優雅地應對。但是今天列出來的問題都是第 4 種吧。

讀到這裡你可能會想說，還好我還沒有開始學 SwiftUI。

本來寫這個專欄的目的是引起讀者對 SwiftUI 的興趣，並且降低學習的障礙跟焦慮。

但現在的情況比較像是我們只能說，看看 iOS 16.1 或是後續版本會不會比較好。

我個人是不抱太大期待就是了🌚

雖然今天的內容沒一句好話，但是我最近還是寫了不少 SwiftUI，搭配 Xcode 14 的 Preview 更新速度還是滿愉快的開發體驗。也不能說 SwiftUI 在 iOS 16 就完全壞掉，只是問題比較多。

對於熟悉 SwiftUI 的朋友還是可以繼續用，總之哪裡有坑就避開。而對於初學或在觀望的朋友，我已經跟你說坑在哪了，哈！現階段只能降低對 SwiftUI 的期待了，這樣就不怕受傷害？

那麼你可能會問：「這個世界以後會變好嗎？我是說 SwiftUI。」我猜，如果 Apple 繼續用 UIKit 來實現 SwiftUI 的功能，那麼狀況應該不會變好。

但是有個現象值得觀察。今年 UIKit 在 UITableView 與 UICollectionView 裡新增了 UIHostingConfiguration 這個機制，也就是讓 cell 直接放入 SwiftUI 的 View。耶，這思路是顛倒的──用 SwiftUI 來實作 UIKit。你覺得有希望嗎？

總之，我還是會密切觀察 SwiftUI 的發展，請繼續支持本專欄～

喜歡本專欄的讀者，請到 Patreon 訂閱支持我🙏 我的目標是累積到 100 位支持者，目前 28%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

希望今天的內容讓你可以少走一些彎路。我們下一期見！

SwiftUI 專欄是一個教你入坑 SwiftUI 的付費專欄。不過我沒有設立付費牆，而是採用「誠實訂閱」制度。

希望可以累積到 100 位 Patreon 支持者，目前進度來到 27%，感謝新舊朋友們的支持。

如果你是第一次讀這個專欄，建議先回到目錄，照順序閱讀。

這期介紹了一些我有在使用的 SwiftUI 文件工具與網站，可以說是教你釣魚。

請記得看到最後，有我心目中的「最佳解」喔。

（看前一期 · 回專欄目錄 · 回首頁）

好的文件，對於學習一套程式框架是不可或缺的。而要這些查詢文件，就需要有適當的工具。

對我來說，使用 SwiftUI 文件工具，不出這三個目的：

1. 查詢如何使用某個功能

2. 瀏覽有哪些 SwiftUI API 是我還不知道的

3. 分享特定 API 的資訊給其他人

以下工具與網站，我會分享使用的經驗，以及有沒有符合我的目的。如果喜歡的話，還請訂閱支持！

Apple 官網

網址：https://developer.apple.com/documentation/swiftui

Apple 官方文件在過去常常被詬病，有些新的 API 完全沒文件，只寫了一句「No overview available.」。甚至還有開發者專門架設 nooverviewavailable.com（已關站）調侃此事。SwiftUI 早期的文件也是很貧乏，許多功能都不知道怎麼使用。

但最近幾年 Apple 在 SwiftUI 文件下了苦工，很多元件甚至提供了截圖。

今年 Apple 官網的文件還做了一次改版，變成左邊有個目錄。跟 Xcode 內建的文件瀏覽器越來越像。

雖然內容看起來很豐富，但是好不好找資料呢？

簡單判斷 SwiftUI 文件查詢能力的方式，就是輸入「Text」，看看會找到什麼。畢竟這是一個很常見的元件，而且有許多使用方式。

很遺憾的是，輸入「Text」之後會找到成千上萬的 init function。看看這無敵長的捲軸，完全不實用嘛。

沒關係，我們可以從 Google 找😂

官網文件最大的好處就是有標準的網址，用瀏覽器就可以閱讀。適合分享。

所以，即使內建搜尋功能等於沒有，如果找得到特定 API 的頁面，還是會成為我認定的「權威文件」。

官網的文件也一定會包含 Beta 版，甚至還有 API Changes 的選單可以切換顯示。對於想知道最新變化的人來說，有一定的幫助。

Xcode 內建文件瀏覽器

打開 Xcode 以後，從 Window 選單找到「Developer Documentation」就是了。或是按 Cmd + Shift + 0。

就我個人的習慣來說，從 Xcode 看 SwiftUI 文件，不是很實用。原因是：

1. 必須要開啟 Xcode 才能看。

2. 文件版本綁定目前的 Xcode 版本。換言之，正式版 Xcode 看不到 Beta SwiftUI 的 API。

不過，至少它的搜尋功能比官網實用多了。

輸入「Text」以後可以看到 Text。

此外，從分享按鈕也可以複製對應的官網網址。

SwiftOnTap

網址：

https://swiftontap.com/

SwiftOnTap 是我過去最喜愛的 SwiftUI 文件網站。

它的優點很明顯：

1. 提供相當不錯的搜尋功能

2. 分類索引一目了然，可以很清楚知道有哪些 API

3. 有提供截圖範例。這比 Apple 官方文件早了一、兩年就做到

但是它有很明顯的缺點，所以我現在無法推薦給大家：

1. 由社群維護，準確性跟更新程度有問題。iOS 15 以後的資訊基本上都不在裡面

2. 不知道什麼時候會關站。幾個月前，維護者在首頁聲明：如果沒有捐款支持的話，預計今年 8/31 會關閉（時間已過）。我不清楚為何每月「僅有」40,000 人次的網站需要 $400 美金才能繼續提供服務。

其實，讓我最困擾的還是該網站維護者的態度。

沒有積極維護這點我可以接受，畢竟這是件吃力不討好的事。但是沒有在首頁聲明文件的版本或更新資訊，以至於我用了很久才發現裡面根本沒有 iOS 15 的 API。我相信該網站的上萬使用者中，也有不少人跟我一樣落入這樣的坑。

MacBuka’s SwiftUI Index

網址：https://mackuba.eu/swiftui/changelog

這個網頁是開發者 Kuba Suder 在今年建立的。

特色是把 SwiftUI API 依照推出的版本（年份）排列，建立成索引。對於了解最新 API 有哪些，或是查詢向下相容非常方便。

每個項目點下去都是連到官網。可以說是官網索引的加強版。

Kuba 甚至整理到各 Beta 版的差異。像是 iOS 16 Beta 3 就推出了一堆新的、WWDC 沒提到的 API。Beta 2 與 4 也有少量新增，更別說 Beta 1 的大量 API。非常推薦各位去翻一下。

網站是在一頁裡面列出所有的 type、modifier、property wrapper、environment key 等等，所以可以用瀏覽器的全文搜尋，也可以用它提供的搜尋框。不過輸入「Text」仍然會找到一堆不相干的東西。

你也可以照主題分類來瀏覽。對於想把 SwiftUI 全部功能或是關鍵字都看過一遍的人來說，我覺得是很不錯的網站。

不過 Kuba 是否會妥善維護，還是會像 SwiftOnTap 那樣，明年 SwiftUI 更新時得留意一下。

SwiftUI Companion

The SwiftUI Lab 這個網站推出的 A Companion for SwiftUI app 是個要價 $50 美金或 $1690 新台幣的文件應用程式。在 Mac App Store 上評分很高。

我是用各位付費讀者的訂閱費用購買的，在此特別感謝支持🙏

但是作為文件工具的話，我不覺得好用，跟我的需求不符合。

首先，它很難查詢資料。輸入「Text」的效果比 Apple 官網好不到哪裡去。

其次，它的內容完全取自於 SwiftUI Lab 研究 SwiftUI 的教學文章，而不是抄自官網。編排、敘述、範例程式碼，都是自成一格。所以是輔助學習，而非「權威文件」。

有這樣的輔助學習教材並不是壞事。問題是，它沒有打開對應官網頁面的功能（不清楚原因，可能是怕 Apple 不給上架 Mac App Store？），所以我如果要比較兩邊的寫法，得自己用其他方式打開官方文件。

最後就會變成：既然我最後還是要看官方文件，那我就懶得開 Companion 了。

Companion 是很厲害的 SwiftUI 研究結晶，裡面有很多範例程式碼，以及從與官方不同的角度來解釋 API 的說明，甚至還有一鍵打開 Playground 檔案的功能。

對於學習 SwiftUI 來說，或許是個不錯的教材。其內容也完全對得起價格。

但是如果要當作文件工具來用的話，以我的標準是不合格的。當休閒書來讀、了解 API 的功能，倒是不錯。

如果能增加連結到官網的功能，就太好了。

Dash

官網：https://kapeli.com/dash

Dash 是知名的 Mac 文件工具，支援超過 200 種文件，當然也包括 Apple 的開發者文件。

作為 SwiftUI 文件工具，我覺得 Dash 相當好用，也是我平時最優先會選擇的工具。

首先，它的文件庫是從 Xcode 來的，而且支援 Beta 版。只要下載新的 Xcode，Dash 裡的文件庫就可以更新。在查詢時，就不需要開啟特定版本 Xcode。這點比 Xcode 內建的文件瀏覽器方便不少。

而且，由於文件庫是從 Xcode 來，所以你可以離線查詢。這點是勝過官網或者我提到的其他文件工具。

當然，這也表示它的文件索引就跟官方的一樣，不像 SwiftOnTap 或 MacBuka 那樣有用心編排過。至少我個人覺得，想要全面了解 SwiftUI API 的話，官方的索引不如前兩者。

Dash 有個小缺點，是 Apple 官方文件有時候會放截圖，這個目前在 Dash 是看不到的。幸好，Dash 跟官方文件的連動機制做得很好，可以從選單或快速鍵打開 Xcode 或是官網。

我常常在分享連結，很常用到「Copy Online Page URL」。

不過，Dash 目前的版本沒辦法只搜尋 SwiftUI 文件，而是會針對所有 Apple 文件。搜尋結果看得到是從哪個 framework 來的，但不能事先過濾掉。

對於只想看全部 SwiftUI API 的人來說，可能還是 MacBuka 的 Index 比較實際。

關於這點，我給 Dash 開發者提了意見，他之後可能會加進去唷。

最後重點，為何我會優先使用 Dash 呢？因為它有跟 Raycast 整合！

以前我都是 Alfred 作為快速進入 Google 搜尋的入口。所以找文件可能就是輸入「SwiftUI Text」之類關鍵字，然後再從 Google 搜尋結果進到 Apple 官網。

自從用了 Raycast + Dash 以後，就可以很輕鬆且快速的離線查詢了。

Dash 的售價是 $29.99 美金買斷，有試用期。我覺得非常超值，而且絕不是只能作為 SwiftUI 文件工具而已。

也是用各位付費讀者的訂閱費用購買的，再次感謝支持🙏

結論

以上就是我使用 SwiftUI 文件工具的心得與經驗。

必須要說，真的很謝謝各位付費支持我寫此專欄的朋友們，不然我也不見得會去買那些工具來試用，然後寫出這篇文章。很享受這個取之於讀者、用之於讀者的循環！

喜歡這篇文章的話，請到 Patreon 訂閱支持我🙏

我的目標是累積到 100 位支持者，目前 27%。也可以按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

希望今天的內容可以加速你掌握的 SwiftUI。我們下一期見！

SwiftUI 專欄是一個付費專欄，只是我沒有設立付費牆，而是採用「誠實訂閱」制度。

我的目標是累積到 100 位 Patreon 支持者，目前進度來到 27%，感謝新舊朋友們的支持。

如果你是第一次讀這個專欄，建議先回到目錄，照順序閱讀。

離上次發表專欄文章已經過了一個多月，最主要是因為我這陣子工作內容轉變，很少寫 SwiftUI，甚至連程式都很少寫很多😅

在這種情況下要繼續寫出長篇的 SwiftUI 文章 ，有著天然的心理障礙。再加上前陣子休了個假。

不過既然都說是訂閱制的付費專欄，總是不能因為這樣就擺著。用來刺激寫作靈感的各種設備已經在路上了，希望可以好轉（13，你不是又找理由花錢吧？😏）。

可以確定的是，以後的文章篇幅會短一點、較好消化一點。

今天來跟大家聊我都怎麼整理 SwiftUI 的程式碼，讓它好讀好懂。

（看前一期 · 回專欄目錄 · 回首頁）

一目了然的 body

SwiftUI 算是很好寫，尤其是搭配我一開始介紹的 SwiftFormat 等技巧。

但是如果你不注意的話，還是可以寫出很難閱讀、很難維護的程式碼。

由於 SwiftUI 的 View 裡面一定會的部分就是 body，所以我讓程式碼好讀的方式就是──讓 body 一眼就可以被看透！

來，直接看一段程式碼。

看得出來這是什麼畫面嗎？有哪些元件？元件之間排版的關係是怎麼樣子？是不是一眼就看懂了。

如果再搭配妥善完整的 Preview 在旁邊，是不是很容易就把元件與實際呈現的樣連結起來？

這就是我們要的效果！

當然，沒經過鍛鍊的 body（？）絕對不是一開始就長這樣。以下歸納我通常寫一個 SwiftUI 畫面的步驟。

第一階段：快速排版

為了快速調整畫面元件，在開始一個新的 View 時，所有的程式碼會先擠在 body 這個 closure 裡面。

一邊在 body 添加程式碼，一邊對照 Preview 是否符合需求的設計圖。

如果遇到要依照變數來改變顯示方式，我通常會先直接寫死，而不是拉一個變數出來。跟資料有關的東西，可以晚一點再一起處理。

第二階段：拆分 body

等到大部分元件都具備以後，從 Preview 看且來跟設計圖夠像，我就會開始把各個部分命名，擺到 @ViewBuilder private的 var 或 func 裡。

什麼叫「夠像」？通常把字體、顏色、元件間距都指定正確，這時候看著 Preview 就會莫名地有感覺。好像已經做完八成的感覺，其實可能才剛開始寫沒幾分鐘。

這大概是寫 SwiftUI 最有成就感的一件事。

命名就如上面程式碼示範的一樣，要一眼就看懂。

寫 @ViewBuilder 是個好習慣，可以很明顯讓人知道這是一個比較小的 View。

雖然有些回傳單一 View 而沒有條件，像是 appLogo 只有一個 Image，不加 @ViewBuilder 的話，compiler 也完全沒問題。

像這樣：

var appLogo: Image {
  Image("appLogo")
}

但我覺得，每次看到 @ViewBuilder 就知道是子畫面，眼睛不用掃到後面的型別。

而且搞不好以後會需要修改回傳的東西，後面一律寫 some View 也是方便修改。

private 則是因為通常只會在 body 用到這個元件。

總之，我都會寫成這種樣的結構：@ViewBuilder、換行、private var、名稱、回傳型別為 some View。

@ViewBuilder
private var appLogo: some View {
  Image("appLogo")
}

我習慣從 body 開始往下都是一整排 @ViewBuilder，不用特別寫 // MARK: Views 來分程式碼區塊。反正看到沒有寫 @ViewBuilder 的就知道捲到另一個區塊了，算是滿直覺的

那如果從 body 拆分這個子畫面的時，需要傳入變數，我就會把它寫成 func buildFooView 的形式。

此時，func 內部用到的變數就變成從外部注入，有的甚至要寫 if else。這個小小的動作顯得非常自然，但你已經對該元件完成了重要的 refactor。

如果是依照條件來顯示 subView， 可以只寫 if show { subview }，不用寫 else { EmptyView() }。這是使用 @ViewBuilder 的另一個好處

body 那邊要不要開始定義 property 來放要注入的變數？如果很簡單的是可以，但我通常還是會晚一點再處理。

抽成 func buildFooView 還有一個好處，就是如果想要單獨 Preview 那個子元件，可以很輕鬆得做到。

第三階段：處理資料流

等到 body 都拆分完以後，可以開始決定畫面上會變動的部分，是要用 @State 安置、把某些資料放到一個或多個 view model 等等。

這個時候 View 的 init 介面會完成。而我通常會把 Preview 裡的畫面複製好幾份，依照我覺得需要看到不同資料對應不同樣貌，而調整 init 注入的參數。

也就是善用 Preview 快速驗證不同資料跟畫面的對應關係。

第四階段：完成其餘功能

最後的步驟就是完成剩下的功能。比如畫面細部的微調、串接到下一層畫面，或是與 SwiftUI 無關的實作。

當然，以上步驟並不是絕對的，只是我歸納自己在開發 SwiftUI 時，自然而然會進行的順序。本篇的重點主要還是在前兩階段，後兩階段的細節有機會可以再補充。不過我相信你真的下去寫 SwiftUI 一陣子以後大概就可以理解，不需要硬記。

結論

一開始的程式碼範例是個「登入」頁面。

裡面由上而下會有 app logo、帳號輸入框、密碼輸入框、登入按鈕、忘記密碼按鈕。相信你光是看 body 的部分，就知道整個畫面的結構。再搭配 Preview（雖然我沒放圖），很快就能掌握整個畫面。

這不只是在團隊開發時需要的好習慣。就算是單人開發，對未來的自己維護這份程式碼也給予很大的便利。

我在判斷一個工程師在程式碼易讀性上的造詣時，如果對方剛好寫了 SwiftUI，看一眼他怎麼安排 body 就差不多足夠。

對於從 body 拆出來的子畫面，通常會有這幾個特徵：

• @ViewBuilder 並換行

• private var 放靜態的元件

• private func 放需要注入參數的元件

• 一律回傳 some View

你學會了嗎？

喜歡本專欄的讀者，請到 Patreon 訂閱支持我🙏 我的目標是累積到 100 位支持者，目前 27%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會影響到我繼續寫作的動力與內容喔。

我們下一期見！

SwiftUI 專欄是一個付費專欄，只是我沒有設立付費牆，而是採用「誠實訂閱」制度。

我的目標是累積到 100 位 Patreon 支持者，目前進度來到 25%，感謝新舊朋友們的支持。

很高興專欄寫到第 5 篇了。今天來跟大家聊 Color 這個我很喜歡的主題，相信你會覺得有趣！

如果你是第一次讀這個專欄，建議先回到目錄，照順序閱讀。

（看前一期 · 回專欄目錄 · 回首頁）

首先來說 Color 的排版特性。

等一下 13，Color 不就是顏色嗎，哪來的排版特性？

我說過了呀，別把 UIKit 的思考習慣帶來 SwiftUI 嘛。色塊為什麼不能直接拿來排版呢？

🧱填滿畫面

我們可以把 Color 放進任何的 View Builder 裡，包括 View 的 body。

顯示出來的效果，就是佔滿整個「畫面」，或者說，有多少就用多少。

用在有瀏海的 iPhone，系統會把 Safe Area 留白。如果想把顏色填滿，可以加個 .edgesIgnoringSafeArea(.all) 。

🥞多個 Color 自動等分

那如果我們把多個 Color 擺在一起呢？很簡單，它們會自動平均分配空間。

千萬別小看這個特性，很多需要等分的排版需求，用多個 Color 就可以解決。

舉例來說，當你需要自己做固定數量的 tab bar。

如果直接用 Button 下去排，因為文字不一樣，寬度顯得不平均，而且會縮在一起，而不是填滿全部的寬度。會變成這樣：

很多人會想說：「只要先知道全部的寬度，再拿來除以 tab 數量就好了。」但是，照著這個思路來做，很容易就會用上一期我說盡量別使用的 GeometryReader。這裡就不做錯誤示範了。

其實遇到這種需求，用 Color 來排版真的很簡單。

你看這樣子，橫向寬度是否每個就是 1/3 了呢？

稍微解釋一下。首先我們在 HStack 裡放了 3 個 Color，但是不需要真的有顏色，所以直接用透明的 .clear。

接下來在每個 Color 加上 .overlay 這個 modifier，裡面放實際要按的 Button。

.overlay 也是個好東西，其實我一直很想花大篇幅來介紹，但今天的主角不是他。目前記得拿它跟 Color 一起服用就好了。

🔧修正 Button 點按範圍

上面這段程式碼看似排版正確了，但實際行為有點問題。是哪裡呢？原來是按下去的範圍仍然僅限於有文字的地方。因為 Button 的範圍僅限於 label 的內容。

讓我們對調一下內外順序，把 Color.clear.overlay 放到 Button 的 label 裡，就可以了。

🌄.foregroundColor 與 .background

有一次，同事在 review 我的 SwiftUI 程式碼時，問了非常好的問題：

「同樣是設定顏色，為什麼 .foregroundColor(color) 的名稱中有 color ，但是 .background(color) 卻沒有 color 呢？」

這是因為，這兩個 modifier 其實不是一對的，意義完全不同。

• .foregroundColor 是用來幫文字、圖形上色的。我們傳入的 Color 是拿來當顏色使用的。

• .background 是用來幫 View 在它背後同樣範圍，放入另一個 View 的。我們不一定要傳入 Color！

當然，如果傳入 Color 的話，它就會被當成 View 並且填滿「整個範圍」。這就回到我一開始說的 Color 排版特性。

每個 Color 都可以當成 View 來使用。

我的說明有簡化過，因為 background 有好幾種版本。這邊指的是傳入 View 的 background<V>()，有興趣深入的話，請直接看連結的文件吧。

🌃.background 與 .overlay

再跟你說一件秘密吧。我們一開始不是教了 Color 搭配 .overlay 嗎？其實這個 .overlay 跟 .background 的排版行為完全一樣！

兩者都是在目前的 View 同樣範圍再放入另一個 View。差別只是在於，加在 z 軸的上方還是下方而已。

上圖的範例中，兩個 Text 完全相同，尺寸也相同。Color 放在 .overlay 與 .background 的差別只在於跟 Text 是誰蓋掉誰。

結果我還是忍不住介紹了 .overlay😂

🈳Color.clear、 Spacer()，與 EmptyView()

這三個東西，乍看之下很像，實際上完全不同。

先說 EmptyView()。當你需要指定或回傳一個 View，但是又不希望看到它，就可以使用 EmptyView，因為它不會參與排版。

雖然 Apple 官方文件說我們很少會用到，不過實際在寫程式的過程中，我還滿常拿來當作「暫時讓 code 可以 build 過的東西」。

這東西不佔視覺空間，所以我不稱它為「placeholder」，以免混淆概念了。

接下來比較 Color.clear 與 Spacer() 的不同。

我們已經知道 Color 會填滿範圍了，Spacer() 也是。但是 Spacer() 一般來說是用在 VStack 跟 HStack，在其他 View 之間拉開距離用的。此時只會在單一軸向發生作用。

換言之，就是留白。

Spacer() 的優先度很低，別的 View 決定好長度或寬度以後，剩下的才留給 Spacer()。相對的，Color 會吃掉一定的空間，甚至有可能會搶去其他 View 的。

上圖除了展示 Color 擠壓到 Text 的水平生存空間以外，它還往垂直方向長到滿。

所以，如果只是希望剩下的空間留白，應該用 Spacer()，而不是 Color。

通常也不會把 Color 跟 Text 擺在同一個 VStack 或 HStack 裡啦。

🌈Color 與 UIColor 近似的顏色功能與特性

最後，讓我們很快帶過 Color 在顏色方面的功能與特性。很多都跟 UIColor 很像，所以比較簡單。

建立 Color 方面：

• 可以在 Asset Catalog 設定色碼與名字，並用 String 來 init

• 可以用 rgb、hue 與 saturation，或是 white 的值再搭配透明度來 init

• 可以從 UIColor、NSColor、CGColor 來 init，也可以反過來轉成 UIColor、NSColor、CGColor?

系統預設的彩色顏色，也跟 UIColor 沒什麼不同。有 red、orange、yellow 等等，可以直接從 Apple 的 Human Interface Guidelines 找到色碼表。

要注意的是，這些顏色都是動態的，會依照 Light / Dark Mode、Accessibility 的高對比設定等情況而有所不同。

這個特性可以在 Asset Color 設定（下圖右邊兩個箭頭）。

最基本的 black、white 當然也有，不過沒有提供 systemGray2 等灰階色。

UIKit element colors 也不在 SwiftUI Color 裡，只有 .primary 與 .secondary。畢竟 Color 還要支援非 iOS 的作業系統。真的有需要的話，自己轉就行了。

🎨Color 獨特的顏色功能與特性

• .accentColor 是 SwiftUI Color 特別的 property，可以說是整個 app 的主題色調吧。你可以在 Asset Catalog 設定。現在新增專案預設都會看到它（上圖左邊箭頭）。

值得一提的是，Mac app 要使用 accentColor 的話，使用者必須把系統偏好設定的強調顏色設定成「多色」才會發生作用。

• 可以用 .opacity() 直接幫 Color 修改透明度。

• iOS 16 新增了很有趣的功能 .gradient，可以直接從 Color 產生漸層的 AnyGradient 。

Color 如何「保存」？

最後我想提一點，顏色的指定其實是滿複雜的事情。如果你想把 Color 存起來供未來使用（比如說把使用者選擇的顏色存在 UserDefaults），Color 沒有提供直接讀取 rgb 與 alpha 值的功能，可能要先轉成 UIColor 再處理。

由於 Color 跟 UIColor 都有動態數值的功能，以及可能要考慮 color space，務必把這些細節搞清楚，以免存錯數值。

結論

1. Color 是 View，有排版特性，會填滿範圍

2. 多個 Color 擺在一起時，會平分空間

3. 搭配 .overlay 很好用

4. .foregroundColor 與 .background 不是一對。傳入 Color 時，前者會拿來當顏色用，後者會拿來當 View 使用

5. .overlay 與 .background 才是一對

6. 在 V/HStack 中，Color 會往兩軸填滿、Spacer() 只會在單軸做留白

7. EmptyView() 不會參與排版

8. 顏色功能方面，許多都與 UIColor 相似

9. 獨特之處在於 .accentColor、.opacity()、.gradient 等

10. 如果要保存 Color 要特別小心

讀完這期 SwiftUI 專欄，有沒有覺得「好多東西其他 SwiftUI 教學都沒提過」呢？

喜歡本專欄的讀者，請到 Patreon 訂閱支持我🙏 我的目標是累積到 100 位支持者，目前 25%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

希望今天的內容讓你可以少走一些彎路。我們下一期見！

如果你是第一次讀這個專欄，建議先從頭照順序閱讀。

SwiftUI 專欄是一個付費專欄，只是我沒有設立付費牆，而是採用「誠實訂閱」制度。

我的目標是累積到 100 位 Patreon 支持者，目前進度來到 23%，感謝新舊朋友們的支持。請注意 Patreon 會在初次訂閱和每個月 1 號扣款。

前陣子用讀者捐款添購了一些設備以及軟體，對我的寫作很有幫助。能夠做到取之於讀者用之於讀者的正向循環，還滿感動的。

上一期結尾我說到接下來要聊 Color。不過我在推特上辦的小投票有 3 倍的人想先聽我講「那些你不該碰的 SwiftUI API」，所以我就先來寫這個題目。

不過這題目比較麻煩，多寫了一週。以後還是盡量按照自己的步調好了😂

（看前一期 · 回專欄 · 回首頁）

🙅不要相信任何人

在開始本期週報之前我想講一個非常重要的觀念：

SwiftUI 還很新，不要輕信網路上寫的東西。

你在網路上看到關於 SwiftUI 的資訊，不管是 blog、教學課程、StackOverflow 的答案、GitHub 上的程式碼、Twitter 上的討論，甚至 Apple 論壇跟官方範例程式碼，都有可能是錯的。

當然也包括我寫的東西。雖然我都會盡可能查證才寫出來，但我也是會錯的。

所謂的錯，不一定代表那樣寫程式會動不了，但很有可能會在某些狀況下炸掉或是超出你的預期。尤其是越早寫的出來的 StackOverflow 答案🌚。因為 SwiftUI 剛出來的前兩年，許多人還在摸索。光是要讓某些東西能夠「像以前 app 的行為」，就搞半天。

前一期我就有提到，覺得不適合 SwiftUI 用來複製 UIKit 的行為。如果硬要這麼做的話，有非常高的機率是在寫所謂的 workaround。

既然是 workaround，就表示它很有可能會在未來的某一天壞掉。有機會我再教怎麼管理 SwiftUI 的 workaround，最好不要派上用場。

總之網路上有不少東西是在教 workaround，「抄答案」的時候要小心。

說個題外話，我自己非常喜歡的 SwiftUI 文件網站叫作 SwiftOnTap。它集結了 Apple 的文件，再進行補充。最大的優點是除了範例程式碼以外，還會放一些畫面截圖。而且內容完全都是 SwiftUI，所以搜尋起來比 Apple 自己的文件好找東西。

不誇張地說，以前我每次寫 SwiftUI 都會用到這個網站來查資料，而且長久以來都大力推薦。

但是它其實在 iOS 15 推出以後並沒有做什麼更新，所以少了很多新東西。如果你的專案只從 iOS 14 開始支援起，是沒有什麼問題的。寫 iOS 15 以上的話，就會漏掉一些新功能了。

這也算是另一個不要輕信網路上東西的例子吧。

有比 SwiftOnTap 更好的替代方案嗎？有的，等需要時我們再來介紹。

🙅不要使用 Introspect

SwiftUI-Introspect 是一個非常熱門的 SwiftUI 套件。它的功能是利用 SwiftUI 自己的 API，讓開發者在使用 SwiftUI 的元件時，可以找到對應的 UIKit 或 AppKit 物件，進行修改。

舉例來說，List 在 iOS 13-15 使用 UITableView 來實作。在 iOS 15 以前 List 沒有管理分隔線的 API。

不過，透過該套件，你可以寫：

List {
  // list 內容
}
.introspectTableView { tableView in
  tableView.separatorStyle = .none // 使用 UIKit 的方法把分隔線藏起來
}

從某種角度來說，Introspect 是非常優秀橋接 SwiftUI 與 UIKit/AppKit 的機制。它能幫你找到 UINavigationController、UIScrollView、UITableView、UITextField 等等 UIKit 使用者十分熟悉的元件。

我在 iOS 13 時代寫 SwiftUI 大量使用 Introspect。但是到了 iOS 14 之後，漸漸地就不再使用該套件了。原因有三個。

第一：SwiftUI 是很抽象的框架，底層實作會改變。

以我上面舉的例子來說，iOS 16 的 List 不再使用 UITableView 實作了。寫在 Introspect 裡面的程式碼，因為找不到對應元件，不會被執行。那這個 app 跑在 iOS 16 上會變成什麼樣子呢？就只能跑起來才知道炸成怎樣了。

第二：使用 Introspect 是 workaround。

早期 SwiftUI API 缺東缺西的時候，拿它來暫時繞過非常好用。但是如果有正式的 API，就不該繼續使用 workaround。

第三：過度依賴 Introspect 會導致你學不好 SwiftUI。

這才是我反對依賴 Introspect 的主要原因。它會讓你學習 SwiftUI 的時候，還一直想著畫面上的元件是什麼 UIKit 元件、要達成某個需求怎麼用 UIKit 的方法實現。

這樣很容易會變成只是用 SwiftUI 來刻一部分畫面，實際上還是用 UIKit 的心智模型在思考。

本專欄是強烈建議從 iOS 14 SwiftUI 開始支援起的，所以就別用 Introspect 了吧。

不過，如果你有興趣了解它找到對應 UIKit 元件的原理，其專案原始碼非常值得閱讀。

🙅不推薦使用 List

有沒有聽過一句玩笑話形容 iOS 工程師的主要工作是「把 JSON 變成 table view」。

這個嘛，我既不同意也不反對🤣

由此可見列表形式的畫面，在 iOS app 中十分常見。

但我不是很建議使用 List 來做列表畫面。幾個原因：

1. 直到 iOS 15 才有比較好的自訂性，特別是分隔線的 style

2. 它的選取效果是一整個「cell」。比如說設計的要求是整個 cell 可以點按，同時裡面有比較小的按鈕。那不管按哪邊，都會有整個 cell 被選起來的效果。這絕對不是你想要的

3. 它有一堆 ListStyle 可以套用。但畫面比較複雜時，可能沒有符合你需要的樣式

你一開始還是可以用 List 試試看（問題會出在哪，總是要自己試過嘛）：

List {
  ForEach(data) {
    // cell
  }
}

一旦發現不夠用，替代方案可以考慮 ScrollView 跟 LazyVStack 的組合。反正 SwiftUI 在改變畫面結構的成本超低。

ScrollView {
  LazyVStack {
    ForEach(data) {
      // cell
    }
  }
}

🙅盡可能不用 GeometryReader

在 StackOverflow 上尋找 SwiftUI 怎樣排版時，GeometryReader 會大量出現！通常是想要知道尺寸，然後要「傳遞」給另一個 View 作為排版依據。

但是其實很多時候，用其他的方法可以得到一樣的排版效果。

我今天不打算介紹它的原理或使用方式。用另一種說法勸退好了：我現在有一個很喜歡的腦力活動，就是每次看到有人分享 SwiftUI 的程式碼時，如果裡面用了 GeometryReader，我就會想試試看能否不使用它而達到一樣的排版效果。

結果，大部分情況可以不需要 GeometryReader。

這位 Apple 工程師的推文也是挺有趣的：

太多 SO 答案用了 GeometryReader 很難不抄到。等你跟 SwiftUI 比較熟以後，可以回頭看看以前寫的 GeometryReader 是不是可以改成更簡單的方法。

🙅不要使用 AnyView

AnyView 是個 type-erasure 的 View。換言之，它會抹除 View 本身的型別資訊，對於 SwiftUI 識別是否需要更新畫面會造成困難，且浪費效能。

絕大多數情況你都不需要用到。你可能會在某些 StackOverflow 答案看到它，通常是錯的。

不做解釋只寫關鍵字的替代方案： @ViewBuilder + some View，或用 Group 把 View 包起來。

🙅太急著使用 ObservableObject

這點純屬我個人意見。

大部分 SwiftUI 教學，很早就把 @State、@Binding、@ObservedObject、@StateObject、@EnvironmentObject 等 property wrapper 教給你。

結果就是，許多人開新畫面要塞資料時的起手式變成一定要來個 ObservableObject：

class FooViewModel: ObservableObject { // 真的需要 class 嗎？
  @Published var flag: Bool
  @Published var items: [Item]
  // init...
}

// 放在 FooView 裡：
// @StateObject var viewModel: FooViewModel

但是，我們通常都是先用 struct 或是其他 value type 來放資料，所以 @State 就夠了。換個角度來說，如果是要學習 SwiftUI 排版，那你只需要 @State。

struct FooViewModel {
  var flag: Bool
  var items: [Item]
}

// 放在 FooView 裡：
// @State var viewModel: FooViewModel

當專案變大時，資料的確有可能是 reference type，就會用上 ObservableObject，但根據我的經驗，初期先把 @State 跟 @Binding 這兩個用熟就好了。

🙅避免使用 @EnvironmentObject

@ObservedObject、@StateObject、@EnvironmentObject 這幾個 property wrapper 都使用 ObservableObject，需求與功能也略有不同。

其中，我強烈建議避免使用 @EnvironmentObject 。即便你很清楚自己在幹嘛，以後還是很有可能會害到自己。

先講個觀念：

Environment 在 SwiftUI 裡面指的是從上層 View 往下層 View 傳遞的東西。

比如說：

VStack { // 上層
  HStack { // 第二層
    Text("Hi") // 最下層
  }
}
.font(.largeTitle) // 此 modifier 的設定會由上往下每一層都發生效果，最下層的 Text 會受影響

很多 modifier 會把資訊往下層「傳遞」，像是這邊的 .font。在概念上我都稱之為 environment。

你可以想見，像 .font 這種 modifier 如果不小心加在很上層，那麼整個 app 有很多 Text 都會被影響到了。除非再寫一次 .font 把設定給「蓋掉」。

究竟哪些 modifier 有這種特性，其實是 SwiftUI 一個很大的初學者障礙。你只能一個一個嘗試。

Environment 這樣的東西，最適合去設定某範圍 app 畫面一致的行為。比如說，用 .preferredColorScheme 來設定某一部分的頁面強制 Dark Mode。

有一組 API 叫做 .environment() 與 @Environment var。上層用 .environment() 設定，下層用 @Environment var 讀取。

如果你不小心的話，就會把設定由上往下整個蓋掉。當然，除非這就是你想做的事情。

扯了這麼多，回到我們這一節講的 @EnvironmentObject。它是上層用 .environmentObject()塞入物件，下層使用 @EnvironmentObject var 來讀取與寫入。

請注意，是讀取與寫入。

@Environment 的 init 參數用是 KeyPath，所以是唯讀。

@EnvironmentObject 放的是 ObservableObject，可讀可寫。

親愛的讀者啊，發揮你的想像力吧。有什麼事情比上層無條件影響所有下層還要糟糕？就是下層可以反過來直接修改上層的物件啊。

物件資料被誰改了，誰知道啊。

如果這樣你還不覺得坑（聽起來很像 singleton，沒問題啊！？），還有一件事我沒說。

如果你在下層宣告了 @EnvironmentObject var，但是上層沒有任何地方透過 .environmentObject()塞入物件，那這個 View 也會直接 crash 給你看。

我實在是想不到，除了把自己炸死或是要故意坑隊友以外，為什麼要用到這種行為的 API 哪。

如果你真的很想跨層傳遞物件，並且希望不同層都可以寫入，寧可用 @Binding 一層一層地寫出來，至少你很清楚有哪些層 View 會用到。

SwiftUI 雖然很好寫，但是不能亂寫。Environment 屬於隱含行為，在團隊開發中要特別小心使用。

結論

還有很多東西我覺得不適合 SwiftUI 新手使用，不過這期的字數又爆掉了，哈哈。有機會再補充。

以前我的觀念是：盡量告訴大家哪裡有坑、建議避開。不過後來我發現，有些時候還是要親身經歷，知道痛才學得起來😅。因此，我不反對你去玩玩看這期講到的這些 API。

也歡迎跟我分享你的踩坑經驗。

喜歡這篇文章的讀者，請到 Patreon 訂閱支持我🙏 我的目標是累積到 100 位支持者，目前 23%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

希望今天的內容讓你可以少走一些彎路。我們下一期見！

如果你是第一次讀這個專欄，建議先從頭照順序閱讀。

SwiftUI 專欄是一個付費專欄，只是我沒有設立付費牆，而是採用「誠實訂閱」制度。

我的目標是累積到 100 位 Patreon 支持者，目前進度來到 16%，感謝新舊朋友們的支持。

上週，有位朋友設定了每個月 $13 這個金額，我覺得太有創意了❤️，於是把金額改成 $5、$13 兩種。內容是一樣的，金額差異只在於你覺得我提供了多少價值、自行選擇。

上禮拜的 WWDC22 Platforms State of Union 中，Apple 在牆上打出「The best way to build an app is with Swift and SwiftUI」，這句話有符合實際情況嗎？

今天要來跟大家聊的就是根據經驗 SwiftUI 適合做什麼、不適合做什麼。

（看前一期 · 回專欄 · 回首頁）

🙅不適合新手寫 Widget

2020 年，iOS 14 推出的 WidgetKit，就要求用 SwiftUI 開發。這個限制讓很多人覺得是個接觸學習 SwiftUI 的好機會。

但是，用 Widget 來學 SwiftUI，是我能想像到最糟糕的入門路線了。

除了拿來寫 tvOS app 以外，因為用的人少，坑特別多🌚

開發過 watchOS app 的我很快就意識到，WidgetKit 的本質跟 Apple Watch 錶面「複雜功能」（Complication）的 ClockKit 是系出同源的東西。

換言之，開發者要餵一系列時間的靜態資料給框架，不像舊版 Widget Extension 可以做很多即時更新的操作。

果不其然，今年 watchOS 9 的 ClockKit 反過來被 WidgetKit 取代了😉

如果你沒有寫過 Apple Watch Complication 的話，直接來寫 Widget，同時又學 SwiftUI，那就是雙重障礙，會非常痛苦。

會不知道到底是自己不懂 SwiftUI，還是 WidgetKit 又出毛病了。整天懷疑人生，順帶把 SwiftUI 祖宗十八代都問候完（UIKit 表示…）。

所以我建議至少把 SwiftUI 的排版、Shape 之類的學會，再來碰 WidgetKit。

🙆適合寫 Apple Watch App

剛才說我寫過 watch app。SwiftUI 剛推出時，就有消息指出：SwiftUI 最早是為了取代 watchOS 上的 WatchKit Interface 而設計的。換言之，初代 SwiftUI 最適合的開發平台其實是 watchOS 啊。

基於這個原因，我研究 SwiftUI 時先主攻開發 watch app。並且在 iPlayground 2019 講了一場 ⟪初代 SwiftUI 就用來寫 Watch App 吧！⟫（投影片連結）

這些不是今天的重點，可以不用看。

同時你應該可以理解為什麼我的 SwiftUI 學習路線沒有那麼傷害。反而因為寫 watch app 的同時順便搞懂了 ClockKit，對於隔年學 WidgetKit 很有幫助😎

總而言之，SwiftUI 是很適合寫 watch app 的框架。因為之前的 WatchKit Interface 實在是太爛了。iOS app 還可以用拿 UIKit 跟 SwiftUI 做比較，寫 watch app 根本沒得比。

今年 WWDC 跟一些開發者交流時，聽到他們說覺得今年開始特別適合寫 watch app。理由是，因為要做 iOS 16 Lock Screen Widget，跟 Watch Complication 互通。

但我覺得，2019 年 watchOS 6 能改用 SwiftUI 就比之前好太多。到了 watchOS 7 的 SwiftUI 又進步很多。

真要說今年開始適合寫的理由嘛，應該是 Xcode 14 對於 watch app 的 Target 管理簡化了。以前分成 Watch app 與 WatchKit Extension，光是搞懂個別檔案要放哪就搞死你。

🙅不適合在需要支援 iOS 13 或以下版本的 App 導入

SwiftUI 是 iOS 13 時推出的，那一版問題非常多。我完全不推薦一個要正式上架、需要繼續支援 iOS 13 的 app，用 SwiftUI 寫。

還好，iOS 16 都快出了，支援 iOS 13 的需求應該不高。這也是為什麼我現在才開始寫 SwiftUI 專欄，並強調現在是開發者最好的入坑時間。

總而言之，要用 SwiftUI 寫認真的專案的話，請至少從 iOS 14.0 開始支援。如果可以選擇的話，更好的選項是 iOS 14.2、再更好的選項是 iOS 14.5。

為什麼是 iOS 14.2？這是因為根據實際經驗，iOS 14.0 到 .2 有一些奇怪的 bug，很容易在 runtime crash。反正這幾個小版本太早期了，使用者很少。

為什麼 iOS 14.5 又更好呢？因為修好了一個非常大的坑。

我們之後會找機會多聊這個坑。現在你只要記得 iOS 14.5 以上最保險，就夠了。

當然後面也還有新的坑啦，但已經少很多了。

🙅不適合取代已經用 UIKit 寫好的畫面

不建議的最簡單的理由是，人家活得好好的為什麼要重做呢？

除非你已經對 SwiftUI 很有把握，而且有其他充分的理由，不然我一點都不建議把既有畫面用 SwiftUI 重寫。如果重寫之後規格一模一樣，對於 app 的商業價值完全沒有提升，你的產值也會是 0。

用 SwiftUI 重寫畫面，並不能算是一種重構。所以「專案會變得更好維護」不能作為重寫的理由。何況如果團隊對於 SwiftUI 不夠熟悉的話，怎麼能判斷會更好維護呢🤪

雖然我說 SwiftUI 不適合來拿重做 UIKit 已經做好的畫面，但是如果你個人想要學習 SwiftUI，又不知道拿什麼當題目的話，「用 SwiftUI 試著重做既有的畫面」是非常好的練習方式。

請看清楚，我說的是練習 SwiftUI，而不是寫好之後取代掉原本專案中的程式碼。既有畫面表示有現成的規格、UX，你只需要研究怎麼用 SwiftUI 重新實作。過程中可以體會到 SwiftUI 在拉版面的快速，也有可能會踩到開發過程的坑。但都是可以控制的範圍內。

小插曲：我寫到這段時，剛好有人貼給我看記帳 app Moze 開發者 Amos 提到用 SwiftUI 寫新的 iPad app，來回應使用者抱怨 app 更新緩慢。

經過他的大方同意，我把那段訊息截圖在這邊：

Amos 的這段話很實際地反映出開發者導入新技術的挑戰，也是很寶貴的經驗分享。Moze 雖然用 SwiftUI 重寫既有畫面，但是是在開發新的 app，我覺得是很充分的理由。

為了感謝他願意提供經驗分享，幫他的 app 廣告一下：對記帳有需求的朋友看看 Moze。

這不是業配。另外，我有別的需求，所以並非 Moze 使用者。

🙆適合做新的畫面或 App

如果是 UIKit 專案裡的全新畫面，或是既有畫面要大改版，那麼我的態度就不一樣了。

你可以試試看在做新畫面時，先用 SwiftUI 做個樣子。萬一有些需求達不到（在 iOS 13 的 SwiftUI 特別容易發生，所以我上面就說了…），再考慮用 UIKit 補足。

當然，因為我不知道你對 SwiftUI 的掌握度怎麼樣，沒辦法說這樣做就一定沒問題。但至少新的畫面用 SwiftUI 來做，一定可以省下「刻」畫面的時間。

如果你現在就開始這麼做，那麼坑是一定會踩到的，因為這個專欄還沒介紹到 SwiftUI 的坑嘛🤪

回頭解答開頭的問題。其實那張圖片是騙人的，或者說 Apple 的投影片本身就斷章取義。Josh Shaffer 的整句話是（我加粗）：

Now, if you have an existing app, it's easy to adopt these new technologies incrementally.

And if you're new to our platforms or if you're starting a brand-new app, the best way to build an app is with Swift and SwiftUI.

是的，SwiftUI 適合寫全新的 app，尤其是 iOS 跟 watchOS app。但請不要讀到這裡就去開個新專案，我們專欄才剛開始呢。

SwiftUI 也適合 iOS 開發者新手。前提是至少要有台 M1 不然我會勸退你。

🙆適合寫 Prototype

在求職過程中，偶爾會有「寫作業」的環節。通常會是依照需求寫個小 app 或幾個畫面，實作一些假的功能。

這種情況非常適合用 SwiftUI 來寫。因為寫作業通常不會限制你的工具或系統版本，但是有時間壓力，你也不會想花太多時間在上面。我最近一次求職經驗，就用 SwiftUI 寫了兩次作業，都相當迅速且輕鬆（當然，那兩次也都通過關卡）。

或者有的時候在團隊裡，為了溝通某些 app 的 UX，需要展示特定的流程或畫面，SwiftUI 也很適合。

像我就在一次公司內部的提案競賽中，為了驗證某個概念的可行性，用 SwiftUI 快速寫出了看起來很真實的流程原型。最後也因為「可行性看起來最高」（其他組別只能呈現投影片）而獲獎。

🙆適合寫 Side Project

最主要原因是，side project 完全在你手上。要支援最新的作業系統，沒問題。要加某個實驗功能，沒問題。發現 SwiftUI 不能實現你想要的設計，只能換掉，沒問題。

延伸上面講到 SwiftUI 開發 prototype 之快速。當想到某個點子時，可以立刻打開個新專案寫寫看。

我個人的經驗是，做個能夠驗證某個點子是否可行的小專案，通常是用小時在計算的。也就是說靈感一來，「趁這個週末用 SwiftUI 寫出一個自己用的小 app」，是完全可行的。

🙆適合寫自訂性高的畫面

SwiftUI 超適合做一些用 UIKit 排版起來會很痛苦的東西。比如一些非標準元件、要大量「手刻」的東西、轉場動畫。

我的 SwiftUI 「啟蒙」是 Design+Code 的課程，設計師 Meng To 創辦的教學網站。

WWDC19 宣佈 SwiftUI 不久之後，Meng 就開始推出用 iOS 13 寫 SwiftUI 的課程。他從設計師的角度來寫 app，充分發揮了 SwiftUI 的專長：所見即所得、快速調整版型、高度自訂性、酷炫的轉場動畫。Design+Code 迅速爆紅，厲害到連 Apple 都跟他買課程。

不過你不用上他的課，只要看一下 Twitter 帳號裡面的 SwiftUI 教學短片，就可以有一些印象。我隨便放一個：

看到那些動畫了嗎，SwiftUI 是那樣「玩」的。

所以我打從一開始學 SwiftUI 的觀念就不是「SwiftUI 要怎麼取代 UIKit」，而是「看起來 SwiftUI 很擅長某些東西，想把它的那些優點發揮出來」。我希望讀者也能有這樣的觀念。

如果你自己會設計，就可以大膽地實驗。如果你不會設計，至少跟設計師合作時也能討論怎麼運用 SwiftUI 的特色。

結論

過去，我在很多場合都講到過：SwiftUI 跟 UIKit 非常不一樣，甚至 UIKit 的既定觀念會對學習 SwiftUI 有負面的影響。

我猜大部分讀者都是 iOS 開發者，並且熟悉用 UIKit 開發 iOS app。所以學習 SwiftUI 時，得拋棄很多來自 UIKit 的習慣與假設。為了達到這個目的，之後的專欄裡面，我會盡可能地把 SwiftUI 當作全新的東西來教，而不會用 UIKit 作為對照。

比如說，SwiftUI 的 Text 跟 UIKit 的 UILabel 完全是不一樣的東西。給你看看最近幾天，前 SwiftUI 工程師 Natalia Panferova 貼的程式碼：

Text 的參數可以放 Text，還可以加 modifier！🤯

看到這種程式碼，如果不把 UIKit 丟掉的話，根本沒辦法思考。

SwiftUI 的 Color 也跟 UIColor 完全不同。下一期我們就從它開始。

喜歡這篇文章的讀者，請到 Patreon 訂閱支持我🙏 我的目標是累積到 100 位支持者，目前 16%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

希望今天的內容讓你可以少走一些彎路。我們下一期見！

這週是 Apple 給開發者一年一度的 WWDC，SwiftUI 的更新當然也是重頭戲。不過沒有影響到本專欄的規劃，還請放心照進度看下去。

上一期是 SwiftUI 專欄副刊的第 0 期，還喜歡那樣的風格嗎？如果還沒讀過，請先回去閱讀再接著今天的進度喔。

相信部分讀者看到 13 開始連載這個 SwiftUI 專欄，首先會想到的是「糟糕，又要學新東西了🤯」，伴隨著學不完、學不動的學習焦慮。

其實啊，我在規劃專欄時，最主要目的是想帶給讀者輕鬆認識 SwiftUI 的機會，設計出一條「減少傷害、強化樂趣」的學習路線。畢竟 SwiftUI 還很年輕，絕大部分公司既有專案都還在用 UIKit。現在開始，隨著專欄來接觸 SwiftUI 剛剛好，不用心急。

另一方面，我要多說明「這是個沒有付費牆，但是用付費電子報心態在經營的專欄」這句話的意思。

我做過許多 iOS 技術的分享，許多都滿「獨家」的。比如 Podcast 與電子報做了近三年，市面上都沒有出現類似的東西。

同樣的時間精力，可以做英文內容來接觸全球的開發者、寫 side project，甚至接案賺錢來增加收入。要不然也可以多休息、玩點遊戲等等。選擇在中文 iOS 開發者圈分享，還是因為想回饋這個照顧我許多的社群吧。

這次會開闢 SwiftUI 專欄，是因為我收過許多詢問 SwiftUI 如何入門的問題，也觀察到不少 iOS 開發者不得其門而入。SwiftUI 其實不難，只是學習途徑有它獨特之處。我對 SwiftUI 算是頗有心得，對於「學習 SwiftUI」這件事也有深入思考，相信認真寫起來，一定能幫到一些人。而且我寫出來的東西、鋪陳的方式，你在其他地方看不到。

用經濟學來說，就是市場有需求、我可以供給😂

但是，把這些知識整理成專欄，真的是在我「免費提供」的能力範圍邊緣了。如果這個 SwiftUI 專欄（或是任何人做的任何一項學習資源）對你有幫助，請回饋或是付費給作者。

你可以訂閱我的 Patreon 來支持我。我設定了每個月 $5、$10、$15 美金三種，希望可以累積到 100 位支持者。相對地，你可以提前看到專欄文章。每個月初，Patreon 會扣款，並送到我的 PayPal 帳戶。過程中去除各種手續費後，大概剩下 8 成是真正能運用的金額。通常我是拿來買買遊戲（Steam、Xbox、Switch 皆可，但台灣 PSN 不支援）、軟體服務（像是 GitHub Pro、Setapp）、網路服務、電子書。如果犧牲點匯差的話，訂 Uber Eats 還真的能填飽肚子，靠寫作當飯吃🤣（更新：Uber Eats 在台灣已不支援 PayPal）

作為早期支持者，如果你曾經捐款過 weak self 或是我個人，即使沒有在 Patreon 上訂閱，我也會把文章提前發給你看（主要是透過 Discord 專屬頻道）。如果你沒收到的話，請記得來跟我索取權限喔。

如果讀了這份專欄有所收穫，但還不想付費的話，我希望你可以把所學知識分享出來。寫 blog、發推特、編電子報，甚至拍影片，都很好。中文 iOS 社群需要更多技術分享。

啊，一個不小心開頭就寫了這麼多。請享受今天的內容～

（看前一期 · 回專欄 · 回首頁）

前言

上一期講的是 SwiftUI 開發環境必要的硬體設備。這一期，我們來講軟體工具的部分。

要撰寫 SwiftUI，我們必須使用 Apple 提供的開發軟體——Xcode。光是選擇正確的 Xcode 版本，以及怎麼取得 Xcode，就是一門學問了。我也會教你設定程式碼自動排版工具。這些都是快樂地玩耍 SwiftUI 非常重要的準備。

沒什麼選擇，只能用 Xcode

我們強調過，SwiftUI 的 Preview 是開發中不可或缺的功能，而這項功能是 Xcode 的一部分，所以我們就只能用 Xcode 了。

你可能會問，iPad 跟 Mac 上那個 Swift Playgrounds 做為替代品行不行？我覺得不行。

並不是說 Swift Playgrounds 不能拿來開發 app，有人確實做到了。但是如果要把 SwiftUI 學起來的話，Playgrounds 是不夠用的。

喔對了，VSCode 搭配 HotReloading 或許可以做出類似 Preview 的效果，但這東西太新，我還沒有試過。有興趣的朋友可以玩玩看。

安裝 Xcode 的錯誤與正確姿勢

可能是因為看過很多用 Mac App Store 下載 Xcode 導致傷害的案例，我特別喜歡勸開發者改用別的下載方式。為此寫過至、少、四、篇文章，是不是有誇張到🤣

從 Mac App Store 下載 Xcode，唯一稱得上好處的，是只需要 App Store 帳號。但是把 Apple ID 註冊為 Apple 開發者帳號並不用付錢（跟 Apple Developer Program 不一樣），而且開發者帳號以後一定用得到，所以就不要偷懶了吧。

最陽春的下載方式，是去官網登入開發者帳號以後，在這邊 https://developer.apple.com/download/all/ 挑選版本。下載 .xip 檔以後，自行解壓縮。

如果你有夠快的外接硬碟，也可以分享 .xip 檔案給需要的同事，這是最快取得 Xcode 的方式🤪

而目前最推薦所有認真想要從事 iOS 開發的朋友使用 Xcodes app 這個 app 來下載。原因有：

• 它採用 aria2，能夠同時多達 16 個連線，下載速度最大化。在我家的 1000/600 光纖，最高曾經跑到 112 MB/s

• 能夠看到電腦上所有的 Xcode 版本，並顯示所有版本的相容性資訊

• 一鍵切換目前工具鏈的版本，不用自己打 sudo xcode-select -s

• 新版還支援 unxip 測試功能，解壓縮速度最快可達 +70%

你可以在 Xcodes 的 GitHub Releases 下載該 app。

Xcode 每隔幾週就會有新版可以下載來踩坑測試，準備好快速的安裝工具絕不吃虧。上一期推坑 M1 呢，也是因為它用來解壓縮 .xip 很快呢😂

要選哪個 Xcode 版本呢

SwiftUI 最早是跟著 Xcode 11 一起推出的。寫下這篇文章的時候，最新版是 Xcode 13.4.1，而我認為 Xcode 13.2.1 是最穩定又不會太舊的版本。

資深 iOS 工程師都會去讀 Release Notes 以及上網看看有沒有「災情」，再決定使用哪個版本。

Xcode 13.3 以上有個坑──SPM Resolved 檔格式與之前的不同。如果用 13.3 以上新增 Package 再用舊版開啟，就會遇到問題。就穩定性來說我比較推薦用 13.2.1 版

在 Xcode 14 正式版推出之前，不反對下載 Xcode 14 beta 玩玩新功能。但我要讓你學到的是能用來上架的開發環境，所以前期教學內容會以 Xcode 13.2.1 為準。

上一期講準備 Mac 時，沒有特別提到硬碟容量。其實一個認真的 iOS 工程師，電腦裡通常會有好幾版的 Xcode，所以千萬不要只選配 256 GB SSD。512 GB 有時候也會覺得緊迫，1 TB 則相當舒服了。

排版非常重要

SwiftUI 如果寫得好，是可以做到讓人看一眼，就大概知道畫面的結構。像這樣：

var body: some View {
  VStack {
    HStack {
      leadingButton
      title
      trailingButton
    }
    .background(Color.secondary)

    content

    footer
      .font(.footnote)
  }
}

但這有個重要前提，就是縮排是正確的。下面是同樣的程式碼，但縮排是亂的：

var body: some View {
VStack {
    HStack {
        leadingButton
        title
        trailingButton
    }
.background(Color.secondary)
content
footer
    .font(.footnote)
}
}

你看得出來 VStack 裡有幾個元素、.background() 是套在哪一層嗎？

SwiftUI 程式碼裡面會有大量的 { }，用來表示畫面元素的階層關係。如果縮排不正確的話，根本就沒辦法理解畫面是長什麼樣子。

Xcode 內建的重新縮排功能，是把程式碼選起來，然後按下 Ctrl+I。

以前不懂事的時候，我都覺得，反正就 Cmd+A 全選、再 Ctrl+I 。還行，還可以接受。

但其實很多 IDE 能在打字或換行的同時，就會自動調整縮排（比如用 VSCode 或 Android Studio 開發 Flutter），根本就不需要開發者多按那幾下啊。Swift Playgrounds 也有類似的效果。從這個角度來看，Xcode 是非常落後的。

我之前就預言 Xcode 14 會有更好的 Swift 格式工具或自動排版功能。果然 Xcode 14 在修改程式碼時，更容易觸發自動調整縮排（例如打 } 時 ），還推出了 Swift Package plugin 機制，讓開發者自己安裝或開發合適的格式工具。

不論如何，還在用 Xcode 13 的我們，必須要有應對策略。而我覺得會令許多 iOS 開發者相見恨晚的就是採用 SwiftFormat。

SwiftFormat 裝起來

我在 2020 年寫過一篇筆記來推坑 SwiftFormat。它除了縮排以外，還能做很多自動套用 Swift 程式碼格式的事情。我推薦給所有使用 Xcode 寫 Swift 的 iOS 工程師，不論初學還是資深。不過在這個專欄我只說明必要的步驟。

首先，從 SwiftFormat 的 GitHub Releases 下載 SwiftFormat for Xcode app。

解壓縮以後，拖曳到應用程式資料夾，打開。

它的 icon 是這個樣子。

你可以在 app 裡設定各種規則，就留給你自己研究，預設的規則也挺好。

因為它是 Xcode 的「延伸功能」，必須到「系統偏好設定」裡啟用它。

如果你在「延伸功能」找不到 SwiftFormat，那麼可能是 Xcode 向 macOS 註冊來源編輯器方面出了什麼狀況。

已知比較有效的「解法」，是到應用程式資料夾把 Xcode 改個名字再改回來。

對，你沒有看錯…

如果你是用 Xcodes 下載的話，名稱可能會是「Xcode-13.2.1.app」。就隨便改成別的、再改回來。再回到「延伸功能」看看有沒有出現 SwiftFormat。

Xcode 與專案設定

今天這篇結束之前，一定要教大家幾個設定，可以說是我寫 SwiftUI 的密技。

綁定 SwiftFormat

前面設定完 SwiftFormat for Xcode 以後，應該會在 Xcode 的 Editor 選單最下面找到 SwiftFormat。裡面有三個功能，我們要幫 Format File 設定快速鍵。

請到 Xcode Preferences 的 Key Bindings，搜尋 SwiftFormat，並把 Format File 指定為 Ctrl+Shift+I。這組快速鍵與內建的 Ctrl+I 接近，又沒有衝突。（把內建的保留起來，以防萬一你還是要用到。畢竟 SwiftFormat 不支援 Objective-C）

這樣子，在寫 SwiftUI 時，看到目前檔案的排版不順眼，只要按 Ctrl+Shift+I 就好。不需要先選取程式碼喔。

SwiftFormat 還有許多進階的功能與整合方式，就請參考我之前的推坑筆記了。

修改縮排寬度

Xcode 專案預設的縮排寬度是 4 個 Spaces。根據我學到的經驗，改成 2 個 Spaces 對於看 SwiftUI 程式碼很有幫助。

這是 Indent Width: 4 Spaces。

這是 2 Spaces。對於螢幕的寬度要求輕鬆許多。而且對我來說，還比較容易用眼睛計算縮排的層級數。

請到 Xcode Preferences 的 Text Editing 進行設定。改完之後回到程式碼，按下前面教的 Ctrl+Shift+I，就會立刻看到效果。

至於灰色圓點嘛，我個人是覺得對於減輕眼力負擔頗有幫助。請到 Xcode 選單的 Editor，把 Invisibles 打開。

小結

SwiftUI 就像早期的 Swift，帶給開發者許多令人興奮的功能，但也帶來不少的困擾。希望透過本專欄畫出的路線圖，讓你有一個比較快樂、不挫折的學習經驗。

這期提到 Xcode、SwiftFormat 的準備，請別小看當中的細節。建立好習慣，才會讓之後 SwiftUI 寫起來更順利。

之後我會告訴大家，根據多方嘗試的經驗，什麼樣的「題目」適合用 SwiftUI。如果你有考慮用 SwiftUI 做的專案，歡迎寫信或是使用留言💬功能來與我討論。

喜歡這篇文章的讀者，請到 Patreon 訂閱支持我🙏（希望可以累積到 100 位支持者，目前 11%），並按下愛心❤️、留言💬，也歡迎直接回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。

訂閱支持 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 訂閱來支持我繼續寫作。訂閱者可以搶先讀到每一篇新文章。

2024 年更新：

13 報的 SwiftUI 專欄在 2022 年成立時，就是一個付費專欄。只是當時我沒有設立付費牆，而是採用「誠實訂閱」制度。當時就有不少朋友訂閱了我的 Patreon 來支持我寫作，非常謝謝你們！

2024 年 9 月，我啟動了 iOS Developer+ 會員，寫了很多文章。然後 11 月在 iPlayground 講了 SwiftUI，覺得有很多東西可以再跟大家分享，所以這個專欄可以繼續連載了～

請加入 iOS Developer+ 會員來觀看完整的文章以及 #8 之後的內容。也可以在這邊預覽。

2022 年的介紹：

現在開始接觸 SwiftUI 正是時候。我想用一種輕鬆的氣氛帶讀者認識它。

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

一起來，讓好奇心大過知識焦慮！

本專欄推薦從頭開始閱讀起。

2022

• 06/03 #0 首先，以 M1 為目標吧

• 06/10 #1 來把 Xcode 搞好

• 06/17 #2 有些題目還真不適合拿來入坑

• 07/08 #3 那些不該碰的 SwiftUI API

• 07/15 #4 Color 不只是顏色

• 08/26 #5 只要看一眼 body

• 09/07 #6 文件工具與網站

• 10/13 #7 不期待就沒有傷害

2024

• 12/2 #8 連載再開。描述性框架、狀態驅動、TCA