watchOS

SwiftUI是開發iOS、iPadOS、watchOS和macOS應用程序的現代化方式。 它從“舊有”方式轉變，使許多現有的蘋果框架（UIKit，AppKit和WatchKit）變得過時。 這些框架有一個共同點：它們是命令式的。 作為程序員，您可以確定事物應該以每個像素為單位如何顯示。然後，您會對用戶事件作出響應並手動更新數據。在每次更改時，您還需要決定UI應該如何更改。 SwiftUI是一個完全的變革，因為它是反應式的，UI反映了數據的狀態。不再像在UIKit中“連接事物”。 而且，您需要編寫的代碼要少得多。如果以前曾使用UIKit編寫過iPhone應用程序，您將一直在想“就這樣嗎？”。 談到代碼，使用SwiftUI，您只需編寫代碼即可。不再使用StoryBoard或Interface Builder。 我認為這很完美，因為我可以將我的代碼存儲在Git中，並可以立即看到隨時間所做的更改，而不是一些XML的亂碼。 現在，如果您以前從未使用過UIKit，您可能不明白我的意思。這對您來說是好事，不用擔心。 由於蘋果能夠從頭開始使用SwiftUI，我們有很多優勢。 第一次接觸SwiftUI應用程式令人著迷。 以下是Hello World應用程式的代碼： import SwiftUI struct ContentView: View { var body: some View { Text("Hello World") } } 您導入SwiftUI模塊，並聲明一個符合View協議的結構。 該協議要求該結構具有一個名為“body”的計算屬性，該計算屬性返回“some View”。 這就是我們在結構內部做的事情。 “body”計算屬性返回一個類型為“Text”的單個視圖，其中包含內容“Hello World”。 由於您將始終在SwiftUI中看到“some View”使用，現在是解釋為什麼使用它而不僅僅是“View”的好時機。 該聲明強制“body”始終返回相同類型的視圖，這對於SwiftUI的工作方式至關重要。 其中一個原因是性能。為了具有高性能，SwiftUI需要將某些事情視為理所當然。其中之一是每個結構始終返回相同類型的視圖，以便可以輕鬆檢查是否需要在屏幕上重繪。 在這種情況下，我們返回一個“Text”視圖，這是我們的結構始終返回的視圖，而不管其狀態如何。

過去幾週，我一直在認真學習SwiftUI。 再次嘗試之前，我曾經嘗試過，但只堅持了幾天。 它和React非常相似，除了語言不同，SwiftUI使用的是Swift而不是JavaScript。 當然，這並不是什麼新鮮事。SwiftUI無疑受React和React Native的啟發。我只是作為一位資深的React開發者對其印象做個表述。 React在Web上引入了一些徹底改變我們構建應用程序方式的事物: 声明式UI、不可變性和基於數據的UI更改。 這些都是具有改變思維方式的概念，也是Apple平台(如iOS、macOS、iPadOS、watchOS)的一個徹底變革。 當Apple在2014年引入Swift時，他們做出了一個明智的選擇，即與我們使用Objective-C的現有框架UIKit和AppKit進行無縫集成。 由於這個原因，Swift在早期階段就獲得了廣泛的應用，因為開發者對這些框架的工作方式已經非常熟悉，只不過語言發生了變化。 5年過去了，Apple的所有開發者都有足夠的時間用Swift來開發新的應用程序，這使得SwiftUI(於2019年推出)成為了一個徹底的變革。 我敢說，它甚至比Swift本身的引入更加徹底。 現在距離SwiftUI首次推出已經過去了2年。 除非你是早期採用者，否則在跳入"新熱門"之前，你應該等待一段時間以改善問題。 一開始，只有錯誤和沒有文檔，第三方庫的支援也很差。 現在SwiftUI已經成熟到足夠的程度，每個Swift教程也可以算是SwiftUI教程，而Apple也正在不斷努力使其更加優越。 我對Playground應用程序特別感興趣，因為它可以直接從iPad上構建SwiftUI應用程序。 我認為這是一種非常好的構建軟件的方式，但目前尚不可用。我們只是在WWDC上得到了一個潛在的預覽。 特別適合簡單的軟件開發，特別是初學者在學習編程時所寫的軟件。