Declarative, compositional, sequenced and simple. View structure is defined as a one piece structure— declaratively.
Intends to have your code match your view structure:
A container view is a composition with a closure called “View Builder” that contains multiple sub views. An example of one is the VStack.
The @ViewBuilder attribute tells the compiler to translate a closure into a dedicated type of closure that returns a single view containing all views inside it: @ViewBuilder content: () -> Content
The VStack example:
The @State attribute indicates that our struct manages a state object’s lifecycle for us.
The Dollar sign prefix indicates we are view binding to a property in the state. (It’s a managed reference). Without it, access to that member is read only.
A modifier is a chained, fluent method that creates a new view from an existing view. For example:
You can chain any amount of modifiers. Creates multiple wrapper views for each chained modifier. SwiftUI, however collapses these views back down into an efficient data structure. Modifier chaining also enforces a deterministic order to chained operations. So the order of modifiers applied matters. (Ordered behavioural composition).
A List example:
Each view is optimized for storage because it only serves 1 unique purpose (or applying one modifier). A view just becomes a protocol.
SwiftUI provides baseline primitive views to compose your views on top of. These are: Text, Color, Spacer, Image, Shape, Divider.
Updates to the data model result in automatic updates to the view. A List view automatically updates with animated insertions and deletions based on changes to the data model.
By default, when views are added or removed, SwiftUI fades the views in and out.
Conditional logic should be pushed into modifiers as much as possible on the same view, as opposed to generating a whole new view based on conditions (improves code quality and allows for other animation than the default fade in/out).
Here is OrderHistory refactored by adding a OrderCell object, to contain all the details of a single order cell:
Creating more views is “effectively free” because SwiftUI optimizes it down behind the scenes.
Here’s how we can generate multiple views from a collection. (no animation is applied when using ForEach):
A Picker element automatically adapts to MacOS, iOS or iPadOS. Depending on the content in which it’s used, it will function differently. For example, in a Form element, it results in a Section row with a clickable item which brings up a separate Picker table view where you can select a value:
A .contextMenu() example on MacOS:
Controls are defined by their core purpose, not just visual presentation. So they are reusable on different platforms and will behave differently in various contexts. They also have accessibility support built in.