Things just keep getting better and better.

We now have all of the tools necessary for modeling complex domains and navigation patterns in UIKit apps. If a feature has a well-defined, finite set of possible destinations, then we can model that situation with an enum. Or if we need to have a potentially unbounded combination of features on a stack, then we can model that situation with an array. And thanks to the observation tools in Swift we can build navigation APIs for UIKit that look shocking similar to the corresponding tools in SwiftUI.

But we are still not done.

Would you believe that there is still more we can squeeze out of the observation tools when it comes to UIKit? So far we have used the observe function to accomplish two main things:

• First, we can update our UI components from the data in our observable model in a nice, concise way. We don’t have to explicitly subscribe to state, and instead can just freely access fields on the model and that will automatically subscribe us. And any fields we do not touch will not cause the view to be updated when they are mutated.

• And second we can create navigation APIs that mimic what we have in SwiftUI. We can drive sheets, covers, popovers and alerts from optional and enum state, and we can drive drill-down navigation from flat arrays of data.

But there is another very common task one needs to do in UI applications that we haven’t yet broached, and that is UI components that require 2-way bindings, such as text fields, toggles, sliders and more. Let’s see what it takes to use one of those components in our application, see why it’s a bit of a pain, and then see what we can do to fix it.