All apps change state. For example, the user might have tapped a button to reveal more information, they might have entered some text into a text box, or chosen a date from a date picker – all things that involve the app moving from one state to another.
The problem with state is that it’s messy: when it changes we need to spot that change and update our layouts to match. That might sounds simple at first, but as our state grows and grows it becomes increasingly hard – it’s easy to forget to update one thing, or to get the update order wrong so that the user interface state doesn’t match what was expected.
SwiftUI solves this problem by removing state from our control. When we add properties to our views they are effectively inert – they have values, sure, but changing them doesn’t do anything. But if we added the special
@State attribute before them, SwiftUI will automatically watch for changes and update any parts of our views that use that state.
When it comes to referring to some state – for example, telling a state property to change when a toggle switch changes – we can’t refer to the property directly. This is because Swift would think we’re referring to the value right now rather than saying “please watch this thing.” Fortunately, SwiftUI’s solution is to place a dollar sign before the property name, which lets us refer to the data itself rather than its current value. I know this is a little confusing at first, but it becomes second nature after an hour or two.
Remember, SwiftUI is declarative, which means we tell it all layouts for all possible states up front, and let it figure out how to move between them when properties change. We call this binding – asking SwiftUI to synchronize changes between a UI control and an underlying property.
Working with state will cause you a few headaches at first if you’re used to a more imperative style of programming, but trust me – once you’re through that it’s clear sailing.