At this point, I am primarily working in SwiftUI. At work right now, we are doing macOS and iOS, and we’re not using AppKit or UIKit at all. Where I’m at right now in my thinking is that while I do like SwiftUI, I kind of miss the old way of doing things.
UIKit and SwiftUI represent two different approaches to writing user interfaces — imperative versus declarative. I would define imperative as kind of inside out and declarative as inside out. With imperative code, you call a function or method to say “do this thing,” while with declarative UI, you say “render it this way based on the current state.”
Declarative systems like SwiftUI are great because they make a lot of things very simple. Try setting up an AppKit NSTableView versus a SwiftUI Table. It’s way less code the declarative way.
The thing is that I still miss the imperative approach a lot of the time. Being able to say expand this row when I click this button is extremely convenient. With a declarative system, if they don’t give you a way to declare it, you’re just out of luck. When you can declare it, that becomes something like set the variable of expanded row IDs to X so that my view can update and read that variable to show the expansion. It’s pretty circuitous.
I do wonder how much of SwiftUI works the way it does to be more familiar or natural to people coming from web development. Or maybe it was just inspired by those systems?
Here’s where I’m landing. It’s not that I want to go back to the old way — I don’t. I like writing less code. What I’m saying is that both systems have a lot of value, but that treating the SwiftUI approach as inherently better is wrong. Neither approach is better or worse, they’re different. I will probably continue to pine for the other whenever I work in one for the rest of my career.
Collin Donnell 