SwiftUI 專欄 #2 有些題目還真不適合拿來入坑
SwiftUI 讀完就入坑 2022/06/17
13 的話
如果你是第一次讀這個專欄，建議先從頭照順序閱讀。
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%。也請按下愛心❤️、留言💬、回信✉️與我交流。這些回饋都會直接影響到我繼續寫作的動力與頻率喔。
希望今天的內容讓你可以少走一些彎路。我們下一期見！
👍