久等了。
寫書真的不容易。
我原本的策略是，宣布自己要每週連載，來逼自己要有定期的產出。但是上週還是遇到了寫作瓶頸，想要把東西一次寫清楚、寫完整，反而就寫不出來了。
所以我這兩週做了一些調整。回頭寫一些 SwiftUI 專案，用實際的開發經驗來刺激寫作靈感。
另一方面，我也不追求照順序、一次到位。也許後續的發表順序會先從我更有把握的先開始寫。
最後就是，我本來是用 Cursor 這種寫 AI IDE 來輔助寫作，但是後來還是覺得「傳統」的編輯軟體更適合寫書。所以我又回頭去使用 Ulysses。至少它會顯示我已經寫了幾頁、字數多少。
以下是第二章預計的內容。
從 UIKit 轉換到 SwiftUI，我一開始是很興奮的。但是沒有多久，就開始發現事情沒有這麼簡單。有些觀念得重新學習，不只是語法的變化而已。我也觀察到許多開發者有遇到和我一樣的學習障礙。
現在，我們來談一談這些 SwiftUI 的學習障礙。看看你是否也有類似的經驗？
我想先談 SwiftUI 本身、文件、以及開發工具本身的問題。
至於我們學習者本身的狀況或者知識背景，留待下一章討論。
Progressive Disclosure 的 API 設計
我認為 SwiftUI 的語法很好閱讀。但是，好讀跟好寫是兩回事。
在建構 SwiftUI 內建元件時，我們有非常多的選項與參數。
Apple 官方聲稱這種 API 設計叫做 Progressive Disclosure（參見 WWDC22 影片），認為對於初學者可以使用比較簡單的語法快速上手，然後有需要時再改成更複雜的版本。
舉例來說，要寫一個 Button，最簡單的方式是：