Paul Hudson
@twostraws September 16th 2019
每個有經驗的iOS開發人員都熟悉Interface Builder和Storyboard，甚至XIB也是如此。他們可能不喜歡它們，但至少對它們熟悉。如果您以前從未使用過這些功能，則應該跳過此位。
還在？好的-這意味着您以前使用過IB，並且可能會對SwiftUI的不同感到好奇。
好吧，讓我問您一個問題：您是否曾經手動編輯情節提要或XIB？
可能不會。好吧，除了那一次，但答案是肯定的-故事板和XIB包含相當多的XML，這些XML不容易閱讀或編輯。
更糟糕的是，情節提要有一種隨着時間而變得越來越大的習慣。當然，它們可能從很小的地方開始，但是隨後您又添加了另一個視圖控制器和另一個視圖控制器，然後突然您意識到在一個文件中有十個數據屏幕，並且您對源代碼所做的任何更改突然變得非常痛苦。
但是，儘管單點故障並不好，並且基本上無法看到有人通過對故事板進行修改而打開拉取請求時發生了什麼變化，但故事板和XIB的問題更大。
您會看到，Interface Builder對我們的Swift代碼一無所知，而我們的Swift代碼對Interface Builder也一無所知。結果，我們最終得到了許多不安全的功能：我們將Ctrl從IB拖動到我們的代碼中，以將某物連接到一個動作，但是如果我們刪除該動作，代碼仍然可以編譯– IB真的不介意代碼是否它打算呼叫不再存在。
類似地，當我們從情節提要板或出列表視圖單元格創建視圖控制器時，我們使用字符串來標識代碼中的重要對象-一個如此普遍的系統，它甚至有自己的名稱：“字符串類型的API”。即使這樣，我們也需要使用類型轉換，因爲Swift不能知道它返回的表視圖單元實際上是MooncakeTableViewCell。
存在這些問題是因爲IB和Swift是非常不同的東西。這並不是一個很大的驚喜– Interface Builder不僅可以追溯到原始Mac OS X誕生之前，還可以根據Objective-C的工作方式進行設計。
SwiftUI在過去很難過。這是一個僅限Swift的框架，不是因爲Apple決定是時候讓Objective-C死亡，而是因爲它可以讓SwiftUI充分利用Swift的全部功能-值類型，不透明的返回類型，協議擴展等等。
無論如何，我們很快就會確切介紹SwiftUI的工作方式。到目前爲止，您至少需要知道的是，SwiftUI修復了人們使用舊的Swift + Interface Builder方法所遇到的許多問題：
- 我們不再需要討論基於程序設計或基於情節提要的設計，因爲SwiftUI同時爲我們提供了兩者。
- 提交用戶界面工作時，我們不再需要擔心會產生源代碼控制問題，因爲代碼比情節提要XML更易於閱讀和管理。
- 我們不再需要爲字符串類型的API擔心太多了-仍然有一些，但數量大大減少了。
- 我們不再需要擔心不存在的調用函數，因爲我們的用戶界面已由Swift編譯器檢查。
- 因此，我希望您會同意，遷移到SwiftUI可以帶來很多好處！