每個有經(jīng)驗(yàn)的iOS開發(fā)人員都熟悉interfacebuilder和storyboard。你可能不喜歡它們，但至少熟悉它們。如果你以前沒用過這些，可以跳過這一章。

還在這里嗎？好的-這意味著你以前用過IB，可能很好奇SwiftUI有什么不同。

好吧，讓我問你一個問題：你經(jīng)常手工編輯storyboard或XIB嗎？

可能很少或沒有。好吧，但總的來說答案是否定的——interfacebuilder和storyboard包含大量不易閱讀或編輯的XML。

更糟糕的是，storyboard會隨著開發(fā)時間的推移，變得越來越大。當(dāng)然，它初始時很小，但是再你添加了一個又一個視圖控制器后，會意識到在一個文件中有十多個視圖的數(shù)據(jù)，你所做的任何源代碼管理更改都會變得非常痛苦。

還有一個很糟糕的缺點(diǎn)就是，當(dāng)開發(fā)人員通過源代碼管理下拉該文件時，無法明顯看到改動信息。XIB也是如此。

IB使用時，接口生成器對我們的Swift代碼了解不多，而我們的Swift代碼對Interface Builder也知之甚少。結(jié)果，我們最終得到了很多不安全的功能：我們用Ctrl鍵從IB拖動到我們的代碼中來連接某個動作，但是如果我們刪除了這個動作，代碼仍然可以編譯—— 說明IB真的不在乎它要調(diào)用的代碼是否存在。

storyboard也是類似的，當(dāng)我們在storyboard創(chuàng)建TableViewCell?，或者?創(chuàng)建視圖控制器view controll時，我們使用字符串來標(biāo)識代碼中的重要對象，甚至有自己的名稱：“stringly typed api”。即使這樣我們也需要使用類型轉(zhuǎn)換，因?yàn)镾wift無法知道storyboard返回的TableViewCell的具體類型。

導(dǎo)致問題存在是因?yàn)?IB、storyboard和Swift 是各自獨(dú)立的。

SwiftUI打破了這種傳統(tǒng)方式。它是一個只支持Swift的UI框架，這并不是因?yàn)樘O果認(rèn)為Objective-C是時候消亡了，而是因?yàn)镾wiftUI可以充分利用Swift的所有功能——值類型、不透明返回類型、協(xié)議擴(kuò)展等等。

不管怎樣，我們很快就會知道SwiftUI是如何工作的。目前至少需要知道的是，SwiftUI修復(fù)了人們使用舊Swift+Interface Builder方法時遇到的許多問題：

1 不再需要爭論程序設(shè)計或基于故事板的設(shè)計，因?yàn)镾wiftUI同時給了我們兩者。

2 不再需要擔(dān)心在提交用戶界面工作時會產(chǎn)生源代碼管理問題，因?yàn)榇a比腳本XML更易于閱讀和管理。

3 不必太擔(dān)心string類型的api了——仍然有一些，但明顯更少。

4 不再需要擔(dān)心調(diào)用不存在的函數(shù)，因?yàn)槲覀兊挠脩艚缑嬗蒘wift編譯器檢查。

上述都是遷移到SwiftUI的好處。

概念I(lǐng)nterface Builder

xib和nib都是Interface Builder的圖形界面設(shè)計文檔，nib這個名字來自于NeXTSTEP系統(tǒng)，在NeXTSTEP被Apple收購之前，一直使用nib作為Interface Builder的圖形文檔，nib的發(fā)展經(jīng)過了nib2.0,nib3.0，到NeXTSTEP被Apple收購之后，帶有NeXTSTEP標(biāo)志的nib被換成了xib

與nib不同的是，xib是一個XML格式的純文本文件，而nib是一個二進(jìn)制文件，xib比nib有個很明顯的好處，就是xib可以很方便地進(jìn)行diff操作。由于xib是文本文件，所以在版本控制和管理方面比nib更有優(yōu)勢。然而，不論在 Interface Builder中選擇的是nib還是xib格式，Xcode編譯后都將得到一個供程序運(yùn)行時使用的經(jīng)過編譯的二進(jìn)制nib文件。

引用《Cocoa Programming for Mac OSX》一書的說法，Interface Builder 把窗口、菜單欄以及窗口上的各種控件的對象都“凍結(jié)”在了一個 NIB文檔里面了；程序運(yùn)行時，這些對象將會“蘇醒”。