In this 2nd article on Understanding SwiftUI, let's discuss how views work in SwiftUI.
Table of Contents
Why SwiftUI prefers Struct over Class?
SwiftUI Views are structs instead of classes. This avoids having multiple inherited properties, keeps them lightweight and improves performance.
SwiftUI Views are passed by value. This avoids retain cycles and reference counting, leading to fewer memory leaks.
-
SwiftUI is based on the core principle of maintaining a Single Source of Truth.
- View rendering depends on properties like the
@State,@ObservableObjectand so on. These are known as a Source of truth. - When the value of these properties changes, the SwiftUI framework asks the view body to render the UI with the updated values.
- With UIKit, developers manage not only the state of the data but also the view changes based on that data. Whenever a view reads a piece of data, it creates a dependency between them. On data change, views should be updated to reflect the new value. When it fails to do so, then it becomes a bug. There can be multiple states in our app and multiple functions reacting to those state changes. If we do not maintain a source of truth for the current app state, UI bugs tend to creep in due to human error.
- SwiftUI tends to overcome this issue by making
bodythe only entry point. Despite the numerous states an app might find itself in, there is only one possible way to update the UI which is by rendering the view body. Views react to state changes by informing the framework. The framework then recomputes the derived values and generates the body with updated derived values.
- View rendering depends on properties like the
SwiftUI Views versus UIKit Views
| Serial No. | SwiftUI Views | UIKit Views |
|---|---|---|
| 1. | Views alone are the fundamental building blocks. | Views and Controllers work together to form the building blocks. |
| 2. | Views are data-driven. | Views and Controllers are event-driven. |
| 3. | Views are a struct that conforms to the View protocol. |
Views are a class that conforms to the UIView class. |
| 4. | Views are passed by value. | Views are passed by reference. |
| 5. | Views stacked one on top of another are allocated on a stack. | Views are allocated their own designated space in memory. |
| 6. | Views do not inherit any stored properties. | Views inherit stored properties from the parent class. |
| 7. | SwiftUI makes use of multiple single-purpose views. | UIKit views are multipurpose and can be moulded as per our requirements. |
| 8. | Views have only one entry point, the body. View maintains a state (source of truth), computes derived values based on the state and updates the body. |
Views can have multiple entry points for updating their UI. If the happy path of the flow and possible edge cases (unhappy path) are not accounted for, it can lead to UI bugs. |
| 9. | Views are independent and isolated until they are bonded to other views by a single source of truth. | View properties can be altered from anywhere within the code, making it difficult to maintain the state and leaving the code prone to UI bugs. |
| 10. | Views are lightweight as they only store properties that are declared in them. No additional allocation or reference counting is required. | Views can become complex as they store not only the properties that we declare but also the properties of their parent. So, there is an additional allocation that we might not require. Reference counting is required as properties might hold a reference to other classes. |
Top comments (0)