What are the advantages of SwiftUI over UIKit?

Recorded January 24th 2021 – watch the full episode on YouTube.

Everyone wants to know about SwiftUI and UIKit. Ish, what do you think are the key advantages of SwiftUI versus UIKit?

Ish Shabazz: There are a few of them. One of them is lower barrier of entry. Even though I've been developing for years and years now, I'm always thinking about what it's like for someone who's just learned for the first time, because one of my favorite things to do is to teach other folks. And SwiftUI just has a much lower barrier of entry. It's easier to write, it's easier to read, it's easier to iterate on and one of the other great advantages is the live rendering.

I think starting in last year's Xcode, there was the ability to basically preview live whatever changes you were making in SwiftUI, which means you don't have to take the time to launch a simulator and then realize, "Oh, this is off a little bit." Then go back to the code, make adjustment to the code, go back to the simulator, and so on – you lose a lot of time doing that. So the ability to just see what you're doing live is a gigantic advantage of it.

"SwiftUI is basically rendering the view see is a function of state. As you're typing, it's re-rendering the views at that speed. And instead of just modifying a view, which is what you do with UIKit, you have this object and you can change a property on it."

Paul Hudson: I mean, I don't know what kind of evil hacks had to be put in place for Swift because you notice Swift is not a particularly fast-compiled language, right? Sometimes it takes a little while to compile, but they've managed to make it so you can literally type, “hello” and it appears as you type. It is remarkable. I think someone said it was like line-by-line swizzling of Swift to replace that one line with a new line of Swift. If that's the case, it's quite remarkable.

Ish Shabazz: I think another advantage is speed, right? Because technically SwiftUI is rendering the view we see as a function of state – as you're typing, it's re-rendering the views at that speed. And instead of just modifying a view, which is what you do with UIKit, you have this object, and you can change a property on it. It's actually rendering an entirely new view and does it so blazing fast.

Paul Hudson: Again, one of the choices they made was to say, listen, let's ditch classes and adopt structs, and often your view structs have no stored properties. So they're literally zero size in memory. Swift effectively calls the body as a function and shows data from it, so it's super lightweight. We wouldn't think twice about making a thousand integers, so why think twice about making a thousand views? There's no difference in terms of the view hierarchy. It's remarkable what they’ve done.

Ish Shabazz: It's really incredible. It's a lot of fun also. I think that's an aspect that's often discounted. For me personally, I like having immediate feedback and it's just a pleasurable experience to make changes, see them, iterate on them and to be able to do that beyond one view. So basically you can pretty much run an app without ever running the app. It's pretty fantastic.

Paul Hudson: Folks, honestly that answer deserves an underline underneath it because SwiftUI is so much fun to work with. I mean, most of us think coding's fun, right? Most of the time, because it is quite fun. It's a very easy job compared to many other jobs you could have in the world, but with SwiftUI sparks fly out of your ears. I can just noodle around and try things and make things and it is genuinely like you're learning coding again, because it's so much fun to build and go, “wow, I made that in three lines of code or 10 lines of code," and it's remarkable and it just brings back a lot of joy to programming again. And I don't know what it feels like to you if you do SwiftUI for a little while and then go back to UIKit. It feels to me like, "Whoa, viewDidLoad()? What's this?"

"The code translates directly to the live preview and then from the live preview, you can make modifications the next code that will directly impact what the code is saying, so it's one-to-one."

Ish Shabazz: It feels a lot like going back to Objective-C after using Swift for a while. You're like, "Wow, that was a lot." So eventually it got to the point where I'm comfortable with Auto Layout. It still has some sharp edges here and there, but why would you use it now? It’s also another thing that SwiftUI solves is that debate – should UI be written in code because we're coders, or should UI be written rather in Interface Builder because you want to see a visual representation? Which one is the way to go?

SwiftUI solves that because it's the same thing – the code translates directly to the live preview and then from the live preview you can make modifications the next code that will directly impact what the code is saying, so it's one-to-one and there's no longer that debate. I like that too; it's like a single source of truth.

Paul Hudson: It has solved the debate by removing Interface Builder!

Ish Shabazz: Basically, yes. Which I'm a fan of, and I honestly love not having to think about constraints.

Paul Hudson: I'm not going to say I liked using constraints with Auto Layout, because I would regularly fight with it. You'd occasionally go, “how the heck do I make this layout?" And the same is true with SwiftUI: not all SwiftUI layouts are just magically in your head, straight away. You're going to think something through very, very carefully.

The whole debate was weird – storyboard versus code. I had heard people say, “only newbies write their stuff in storyboards." Well, no: I've met many, many lead and principal developers at Apple who use storyboards extensively and they are not by any means newbies. So it's always a weird debate, right?

"After a while, it becomes very difficult to in your brain process code, which is why we have computers honestly to do these things for us. So it's great that with SwiftUI you can just kind of let the computer be the computer and do those sorts of things."

Ish Shabazz: I thought it was. And I really thought there was a strength in learning both. I'm a very visual person so I like to see what I'm doing kind of in real time. And if there's a really complicated layout with varying states, where depending on the size class the interface layout differently – after a while it becomes very difficult to process code in your brain, which is why we have computers to do these things for us.

So it's great that with SwiftUI you can just kind of let the computer be the computer and do those sorts of things. But even without that, just reading the layout, it's a lot easier to read. It's a lot easier to understand, even if you have no experience. Even with coding, you can just kind of understand in language, “okay, this is the order in which things are appearing. I kind of see what's going on here." So, it's pretty great.

Paul Hudson: And that's the reason I use storyboards for a lot of my layouts: because I had complicated layouts with lots of things going on and I couldn't visualize that in my head adequately without having literally the drawing in front of me, seeing what it was doing. I made one app for iPhone and iPad and tvOS with the same storyboard all the way through. And it had all sorts of complicated rules in there to get aspect ratio, width, height, and more, but it ended up looking flawless in all these platforms, including split-screen, slide over and more – it all worked great. And that took a lot of effort a lot of constraints down the line, various priorities here at work, but I got there. That being said, I am glad if I never have to write another line of Auto Layout in my life, because it is complicated.

Sponsor Hacking with Swift and reach the world's largest Swift community!