In this article I will show the differences between UIKit and SwiftUI, and to learn SwiftUI, the best way is to change the Mindset about UI and UIKit development.
Difference
UIKit is an imperative event-driven framework to build UI for iOS. That means you have to handle all state changes in events such as loading views, pressing buttons, etc.The big downside of this method is the complexity of keeping the UI in sync. with its state. As soon as the status changes, you need to manually add / delete / show / hide views and keep it in sync with the current state. SwiftUI is a declarative framework for building UI on Apple’s platform. The key word here is declarative . Declarative means you need to declare what you want to achieve, and the framework will implement it. The framework will know the best way to render UI optimally.
1 2 | UI = f(state) |
The UI in SwiftUI is a function of its status. That means whenever the view state changes, it recalculates its properties and creates a new view. Let’s look at an example below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | struct ContentView: View { @ObservedObject var store: Store var body: some View { Group { if store.isLoading { Text("Loading...") .font(.subheadline) } else { Image("photo") .font(.largeTitle) } } } } |
As you can see in the above example, we have a view that displays the text while loading data and displays the image when the download is finished. The ObserverObject here is the state of this view, and as soon as it changes, SwiftUI recalculates the properties of that view and assigns a new view. With UIKit, we need to hide / show the view hierarchy view manually, but in SwiftUI, we don’t need to add / remove loading indicators. Let’s go deeper into what happens when the state of the view changes. SwiftUI will snapshot the current view hierarchy and as soon as the state changes, it will calculate a view. Finally, SwiftUI applies different algorithms to understand the differences and automatically adds / deletes / updates the views that need to be changed. By default, SwiftUI uses fade in / out animation to show / hide the view, but you can manually change the transition to any animation you want.
View hierarchy
Now let’s talk about view hierarchy and how SwiftUI actually renders your view. The first thing I want to mention is that SwiftUI cannot render your view by doing one-to-one mapping. You can use as many view containers as you want, but in the end, SwiftUI only displays meaningful views. That means you can separate logical views into small views, then reuse them throughout the project. Performance in this case will not be affected. The best way to understand a complex view hierarchies in SwiftUI is to print out its type. SwiftUI uses Swift’s static type system to make a difference very quickly. First, it checks the type of the view and then checks the value of the elements in the view.
1 2 3 | print(Mirror(reflecting: ContentView(store: .init()).body)) // Group<_ConditionalContent<Text, ModifiedContent<Image, _EnvironmentKeyWritingModifier<Optional<Font>>>>> |
By using Mirror struct, we can print body type in ContentView and learn how SwiftUI works.
Conclude
In this article, we looked at the main differences between UIKit and SwiftUI and looked at the differences in SwiftUI’s algorithm. I hope you enjoyed this article. Thanks for reading, and see you next time!