✍️我為什麼要寫一本學習 SwiftUI 的書呢？

從今天開始，我會在 iOS Developer+ 連載「學習 SwiftUI」這本書。希望能夠在 4 月底寫完、5 月整理出英文版，並且出版、上架販售電子書。

作為第一線支持我的朋友，等書籍上架後，iOS Developer+ 的付費會員可以直接下載整本電子書，不需額外付費。

之所以要用連載的方式，是因為我要給自己沒有在上班期間的生活，一個目標與固定的節奏。不然我應該會過得很廢。

不過，老實說，對於寫出一本技術的書，我到現在還是非常沒有把握。

我出過很多文章、電子報、podcast、YouTube 教學影片，也在研討會演講過，就是沒有寫過書。

這對我來說是「挖坑給自己跳」的全新挑戰。

理性上來說，寫書，應該比我現在的能力稍微難一些，稍微努力一點應該是做得到的。（這是維持學習動力的一個重要策略，就是給自己一個難度比自己實力高一點的課題。因為太簡單會顯得無聊，太難的話一下就會放棄。）

感性上來說，我是一直在「好想把這個觀念講清楚」跟「我幹嘛要跟全世界說我在寫書」之間打架。

我已經想好了整本書的大綱，但是要一章一章寫出來，只能每週往前推進一些。

總之，以上是我真實的情況。希望接下來一段時間，可以持續地在 iOS Developer+ 分享我的心路歷程（當然還有實際的書本內容）。

還請多多支持。

至於為什麼要寫這本書，就從下文的「序章」開始說：

我為什麼要寫一本學習 SwiftUI 的書呢？

SwiftUI 從 2019 年推出到現在，已經有將近 6 年的時間，我也用了它 6 年，累積了不少實務經驗。也因為在公司的專案使用，所以與同事們有許多交流。我常常在跟其他 iOS 工程師交流的時候，觀察到他們的一些在學習上的障礙。

身為對學習與認知心理學有著濃厚興趣，而去讀了教育心理系的人來說，我對於怎麼把一個東西學起來一直感到好奇。所以當我發現許多人在學習 SwiftUI 遇到困難，就覺得特別有趣。

換句話說，我覺得 SwiftUI 很好玩，但是對我來說，掌握這項技術的學習過程，比它的內容知識本身還更有意思。

我認為，SwiftUI 其實並不難學，只是學習的時候要有一些策略。

尤其對於有著深厚的 UIKit 知識的資深 iOS 工程師來說，那些 UIKit 的知識對於學習 SwiftUI 往往是一種阻礙。因為絕大部分 UIKit 的核心觀念，對於掌握 SwiftUI 沒有任何幫助。

例如物件導向、記憶體管理、UIViewController life cycle 等等觀念。硬要套在 SwiftUI 上，只會感到十分挫折。而且無法掌握更關鍵的思考問題──如何設計與管理狀態。

反倒是一些接觸過其他的類似的前端框架的開發者，例如 Flutter 或者是 React Native，他們在學習 SwiftUI 的時候，往往能夠更快上手。

所以這本書就是寫來給資深 iOS 工程師，一起來試試看，在學習 SwiftUI 之前，先把腦中的一些東西先暫時放下，我相信這樣子學起來會容易很多。

另一方面，SwiftUI 的一些特性，讓它需要比較好的文件或者是學習資源，才能讓人確定一些 API 的行為。舉例來說，SwiftUI 有大量的 modifier。而這些 modifier 的作用範圍，以及他們的順序造成的差異呢？通常只有把它寫出來實際看結果，才可以確定。

但是，Apple 雖然有提供大量的文件跟教材，卻缺乏互動性，而且沒有好的編排結構。以致對於學習者需要掌握哪些知識，不太容易形成清楚的心智模型。

市面上有不少以 SwiftUI 教學為核心功能的 App，可以讓人直接嘗試效果。網路上也有大量附帶程式碼範例的文章。而我在本書的範例程式碼，則是想提供另一種取向，也就是直接使用 Preview 來學習。畢竟能夠即時看到一段程式碼的效果，也就是立即獲得回饋，是最快的學習方式。

說到 Preview，SwiftUI 的 Preview 雖然提供了即時回饋的理想。在現實上，它從一開始就有不少問題。不是更新非常慢，就是乾脆無法現。雖然每一年都有更新，但是要把 Preview 運用到足以發揮它的效果，非常考驗開發者的功力。所以，本書也會提供一些讓 Preview 變得更實用的技巧。

而最重要的是，我會把 SwiftUI 的知識與開發技能加以分類，讓讀者可以循序漸進地掌握不同的知識分支，而不是東拼西湊。

有了這樣的學習框架，未來有更多的 SwiftUI 知識需要學習時，就可以輕鬆地放在不同的位置，更容易掌握。例如有些 modifier 最好是先熟悉狀態管理，再來學習會比較好。

你應該學習 SwiftUI 嗎？

iOS 開發社群對於學習 SwiftUI 的興趣是非常濃厚的。它的語法寫起來相當的簡潔，要快速做出一些東西會很舒服。在合適的條件下，它可以做出很不錯的產品。

不過在實際的工作機會上，很多專案還不見得能使用 SwiftUI，例如說專案需要支援的 iOS 版本還比較舊，所以轉換到 SwiftUI 有先天的限制。或者是特定版本的 SwiftUI 的 bug 不好處理等等。

不過隨著 SwiftUI 推出一年一年的過去，這些現象當作不學習 SwiftUI 的理由會越來越沒有說服力。

總之我覺得，SwiftUI 已經推出了這麼多年，不再是不成熟的技術。如果有好的學習策略，它其實很好玩，也很值得學。

該是時候把它學起來了。

這本書適合誰？

這本書不是為 iOS 開發初學者撰寫的。如果你是剛開始學習 iOS 開發的新手，或許能夠從本書獲得一些好的學習觀念，但是對於瞭解 SwiftUI 的核心知識，其他教材或書籍的輔助仍是不可或缺。

本書的目標讀者是：

• 有一定 Swift 程式語言經驗的開發者
• 特別是有 UIKit 開發背景的資深 iOS 工程師
• 已經嘗試過 SwiftUI，但感到困惑或挫折的開發者
• 想要建立清晰 SwiftUI 心智模型的開發者

如果你已經熟悉其他描述式 UI 框架（如 React、Flutter 等），SwiftUI 的描述性框架特性應該會很容易上手，但仍然能從本書中得到學習策略的幫助。

我的 SwiftUI 背景

我可以說是很幸運地，曾經在一間公司要開發新產品、並且建立新團隊的時候加入。

當時團隊決定使用 SwiftUI 與 Point-Free 的 TCA(The Composable Architecture)，並且陸續招募了一些優秀的 iOS 工程師。所以我們有機會一起使用 SwiftUI 與 TCA，並且在過程中克服各種挑戰。

（TCA 搭配 SwiftUI 是非常優秀的狀態管理框架。但它不會是本書的重點。）

也因為這間公司因為商業模式的特性，使用者有很高的軟體升級意願，我們只需要支援當前與上一代的 iOS 版本。這就讓我們有機會可以逐年淘汰舊的 SwiftUI 版本，不管是舊的語法、機制，或是 bug。

我們有 3 個專案使用 SwiftUI 及 TCA 開發，畫面很多，功能越來越複雜。配合 TCA 撰寫了大量的測試，在開發中可以見招拆招。

綜合了團隊 3 年半的開發經驗來說，未來的專案還是會優先使用 SwiftUI（以及 TCA）。

至於我自己，平時就有大量的 side projects。大大小小的 SwiftUI app 也超過 10 個。我也從來沒有想過要放棄 SwiftUI。

總之，在合適的情況下，SwiftUI 是很不錯的選擇。

另一方面，這些經驗也讓我感到，一個人要自學 SwiftUI 滿困難的。有團隊一起研究的話，會簡單很多。這也是我想寫這本書的原因。

我對於 SwiftUI 的態度

我的新的 iOS 或是蘋果平台的專案都是優先使用 SwiftUI 開發，可以說完全不會想要回去寫 UIKit 了。

但我並不會說 SwiftUI 是最好的選擇，或是完美無缺。（我對於學習 SwiftUI 的動詞向來是「入坑」。）

也不會說只要用 SwiftUI 就可以解決所有問題。有些應用程式或是特定畫面，就是不太適合用狀態管理的方式來開發。

SwiftUI 在特定情況的效能問題，也有待 Apple 持續解決。

不過這個框架的核心精神是好的。

所以，我會希望讀者掌握 SwiftUI 的知識以後，可以在適合的場合使用 SwiftUI，在不適合的場合，就使用其他技術。這才是對待技術比較實際的態度。

讓我們一起享受 SwiftUI 的學習過程吧！