自 SwiftUI 在 WWDC 2019 大會上發(fā)布以來，我就一直在關注它的動態(tài)，甚至做了大量筆記，但我一直都沒有使用它。主要是因為我不想處理一些 bug 或想一些變通方法，我非常熟悉UIKit，因此與使用 UIKit 相比我的生產(chǎn)力會下降。

　　盡管如此，我對 SwiftUI 的學習和使用非常感興趣，只是一想到蘋果的一些歷史，比如Swift早期的境況，我就有點猶豫。我毫不懷疑 SwiftUI 會成為蘋果平臺開發(fā)的未來，問題是這個未來何時會變成現(xiàn)實。iOS 15 中推出了該框架的第三個主要版本。SwiftUI 的發(fā)展究竟如何，是否已準備好可以構建應用了呢？

　　投票結果

　　我決定通過推特問一問蘋果開發(fā)者社區(qū)的意見。我通過一項調查來確認開發(fā)者現(xiàn)在可否利用該框架構建整個應用——真正的項目，而不是業(yè)余項目。我針對 macOS 和 iOS 進行了分別調查，因為每個平臺的 API 覆蓋范圍不同。結果如下（共計737 人投票）：

　　SwiftUI 在兩個平臺上均已準備就緒：30.7%

　　SwiftUI 僅適用于 iOS：23.1%

　　SwiftUI 僅適用于 macOS：0.5%

　　SwiftUI 尚未做好準備：45.7%

　　從這個結果來看，我不應該指定特定于平臺的選項，因為大多數(shù)蘋果開發(fā)人員只做 iOS 開發(fā)。無論結果如何，這都是關于整個社區(qū)如何看待該框架發(fā)展狀況的一次調查。我也承認推特的調查不是很科學，并不是每個人都使用推特。鑒于上述所有情況，我認為相對公平的說法是：五五開。一半的開發(fā)人員已經(jīng)開始使用 SwiftUI，而另一半還不愿意嘗試。

　　SwiftUI 的期待功能

　　推特上有很多關于 SwiftUI 的討論，在此我將嘗試提煉和總結大家的意見，以及來自社區(qū)的其他評論和資源。

　　大家的普遍看法是 SwiftUI 還不夠成熟，無法利用它編寫整個應用，即 100% 純 SwiftUI。原因有兩個。

　　首先，它可能缺少必需的API，因此你必須借助UIKit。其次，你可能會發(fā)現(xiàn)一些bug或性能問題，必須通過UIKit來解決。盡管如此，如果遇到適合 SwiftUI 的情況，它也會大放異彩。

　　SwiftUI 可以大幅加快開發(fā)速度。因此，你需要權衡利弊。

　　你必須混合使用 SwiftUI 和 UIKit。利用 100% SwiftUI 編寫應用可能還需要再等幾年。

　　多平臺功能似乎還沒有準備好，特別是 macOS API 似乎不太受關注。根據(jù)我嘗試多平臺示例應用的經(jīng)驗，某些 API 在 macOS 上的行為與我的預期不符，產(chǎn)生了一些奇怪的結果。

　　采用（或增加現(xiàn)有采用率）的最大障礙之一是 SwiftUI 一年一次的發(fā)布周期。新的 API 和錯誤修復需要等待一整年，這太難了。似乎在 iOS 13 中使用 SwiftUI 開發(fā)應用特別艱難，但 iOS 14 做了大量改進，并且 iOS 15 推出了大量新 API。

　　Steve Troughton-Smith表示：

　　由于 SwiftUI 只展現(xiàn)了部分 UIKit 和 AppKit 中存在的功能，因此很難判斷 SwiftUI 一年一次的發(fā)布周期是否合理，而且缺乏后臺的部署非常痛苦。[…] 以 iOS 15 中添加的新表單樣式為例：目前這項功能還沒有公開給SwiftUI […]

　　你應該采用什么方法來構建應用？在聽取了Noah Gilmore 的討論（https://mobile.twitter.com/noahsark769/status/1409733170736492548）之后，似乎利用 UIKit 編寫App Delegate 并在 UIKit 中處理導航是個好主意。換句話說，有了 UIKit shell 和 SwiftUI 核心，至少可以在可能的情況下使用 SwiftUI。Noah 還建議首先嘗試在 SwiftUI 中構建一個視圖，如果行不通，則只能使用 UIKit。大多數(shù)情況下效果都很好。

　　對我來說，似乎目前“UIKit shell”是最好的方法。我知道這些框架都可以互操作，但從 UIKit App Delegate（或 Scene Delegate）著手比較靠譜。如果你非常熟悉 UIKit ，則無需從一開始就完全致力于 SwiftUI。簡單來說，擁有一個“UIKit shell”就是留一手，在必要時方便退出 SwiftUI。

　　我有一個想法，剛開始利用 SwiftUI 編寫表格視圖或集合視圖單元格。這似乎是一種將 SwiftUI 代碼引入代碼庫的合理且可控的方式。然而，事實證明，這可能很棘手，因為 SwiftUI 單元格無法提供與 UIKit 相同的功能。對于某些需求來說這樣做沒問題。如果有問題，那么應用中的某些功能就只能完全使用 SwiftUI 的 List 或 UIKit 的 UITableView了。

　　另外，你需要想辦法處理一些bug或問題（https://jessesquires.github.io/TIL/apple_platform/swiftui.html#known-issues--workarounds）。而且你需要在 UIKit 上投入一定的工作量。特別是有些應用的生命周期和導航會涉及很多 SwiftUI 的問題、bug或缺乏API。

　　App 的功能和靈活性都不如 UIApplicationDelegate。但是，正如 John Sundell 指出的那樣，你可以同時使用這兩個組件。

　　NavigationView 和 NavigationLink API的功能很有限，無法支持 UIKit 提供的功能。Omar 的這篇帖子（https://obscuredpixels.com/abstracting-navigation-in-swiftui）很好地概述了這些問題，并提供了一些有關如何包裝 API 以及提供導航層的技術。

　　根據(jù)我從蘋果給出的示例和文檔中看到的示例代碼，與 UICollectionViewCompositionalLayout 的強大功能相比，LazyVGrid 和 LazyHGrid API 似乎非常弱。但是，有一些技術可以組合復雜的界面。

　　SwiftUI 的文檔非常匱乏。我說的不是 API 文檔，而是概念文檔。請參見 Howard Oakley 的帖子（https://eclecticlight.co/2021/06/13/last-week-on-my-mac-the-elephant-at-wwdc/）：

　　但是，僅通過查看 API 中的各個函數(shù)，根本不可能了解諸如屬性文本之類的主要主題。首先，你需要了解子系統(tǒng)的設計和運作方式，以前蘋果都會提供這些概念信息。正如蘋果所熟知的那樣，良好的概念文檔的結構和編寫方式與API 的類和函數(shù)的文檔完全不同。

　　Howard在從整體上討論了蘋果的文檔問題。然而，像 SwiftUI 這樣的框架缺乏概念文檔尤其應當。目前我們必須依靠個人調查和實驗來獲取有關其內部運作方式的信息。

　　總結

　　最后，SwiftUI 在某些方面還有很長的路要走?？赡苓€需要好幾年才能追趕上 UIKit。

　　Steve Troughton-Smith表示：

　　今年的這些Q&A是一個很好的資源，盡管一些交流確實突出了 SwiftUI 還有很長的路要走。

　　無法設置表格背景顏色，無法更改狀態(tài)欄樣式，沒有新的工作表樣式，沒有自定義時間選擇器的間隔……

　　終有一天這些 API 的限制都會減少，但一年一次的發(fā)布周期很難讓 SwiftUI 趕上 UIKit。

　　我希望通過本文，為像我一樣正在考慮是否以及應該開始使用 SwiftUI 的人提供一些幫助。如果你的目標是iOS 14 及更高版本，尤其是 iOS 15，那么現(xiàn)在就可以開始嘗試了。