< What are the advantages of SwiftUI over UIKit? | Has SwiftUI made you want to build apps for macOS, tvOS, and watchOS? > |
Recorded – watch the full episode on YouTube.
So if you were to start a new project tomorrow and need to choose between SwiftUI and UIKit, which would you choose and why?"
Ish Shabazz: I would start with SwiftUI, and the reason is my philosophy of code in general is that it's ephemeral – it's only here for a little bit, until you can write something better. And the code I write today is for me three years down the line, when I'm assuming I am not as well-rested and have less time and just worry all around. So I want to write things now that will be easy for future me to modify and not have to do as much work with.
And you basically have to read the tea leaves a little bit on where things are going, but I can’t see Apple abandoning SwiftUI in the future, right? I think it's clearly the way certain things will just be – we already saw it this year with the iOS 14 widgets, which can only be done in SwiftUI. It's time to really look into SwiftUI. So what I do personally is I recommend SwiftUI first and then anywhere SwiftUI doesn't work, you kind of step back a little bit and start to integrate a UIKit. But I would, for sure if you're going to start something, start with the future in mind and I think the future is SwiftUI.
Paul Hudson: I think the widgets thing was massive, right?
Ish Shabazz: Absolutely.
Paul Hudson: We're talking one year after SwiftUI was introduced. It is now required for a fundamental system feature – a feature that users are going to ask for, if your app even vaguely makes sense of widget, they're going to say, “please give us a widget; we want a widget for your app." And then you've got no choice: it’s SwiftUI or nothing for that.
Ish Shabazz: Yep. And widgets just became instantly popular. I think it's one of the few features that was like, here's the new feature that the general community, not just the tech folks, but the general community just by having an iPhone, they're like, "Yeah, I'm using this, this brand new feature." Right? Something that's like a system level thing a bit. Yeah. Just-
Paul Hudson: To be fair. Apple does a fair amount introducing big features and say, "This is going to be huge," and then often it just kind of just peters out a little bit. Like stickers.
Ish Shabazz: Stickers.
Paul Hudson: I think iMessage apps they've kind done okay. iBeacons kind of okay, bever really hit the big time. Widgets, though, were day one massive, huge and the numbers are through the roof on some of these applications, which is fantastic. So the nice thing is SwiftUI is so finely grained. You can almost take your current layout, your current data model, the current thing you're using and say that’s my widget.
Ish Shabazz: And honestly, yeah, if you're doing a good job with SwiftUI it's transposable like that. So basically your model is separate, and hopefully you can put that in a Swift package sometimes. I wrote this blog post on putting Core Data in Swift Package Manager for the express purpose of if you are making a widget that relies on Core Data, you're going to want to have that in a package just to kind of abstract it. And yeah, you can basically use the same UI elements because your UI is kind of responsive to the size for these particular sizes. You just adapt it so that it works for the widgets. It's pretty neat.
"It's a really fast adoption rate, but you save so much time once you understand SwiftUI that it's almost worth the time to do any of the debugging."
Paul Hudson: Yeah. So I actually ran a survey on Twitter asking folks this question, “if you had to select the next app and what would it be, UIKit or SwiftUI?" And the answer was two thirds said SwiftUI. It was not necessarily a client project or a big enterprise project, even though I know I've had some very large companies email me saying they are using SwiftUI, which is great. But I know for sure folks are a bit more hesitant if it's for client work because any bugs you face you have to try and battle on your time – on your bill rather than the client's bill, which isn't so much fun. But for side projects, for personal projects, it seems for me right now a massive vote for SwiftUI. And it's only been around since September 2019, right? So we're talking 15, 16 months or something? It's remarkable speed.
Ish Shabazz: It's a really a fast adoption rate, but you save so much time once you understand SwiftUI that it's almost worth the time to do any of the debugging. Some things I wrote were like 95% faster – things that would take a week of work to do before I could do in an hour and that's amazing. It's a really big leap.
And another reason that it's good for future projects is you look at things like bringing apps to the Mac – it's just going to make your life a whole lot simpler not to have to rewrite your UI code. There was Catalyst, but that ended up being short-lived. I thought that was one of the most interesting things about WWDC19: the big thing going in everyone was talking, "Marzipan, Marzipan, Marzipan – we’re going to be able to bring iOS apps to the Mac!”
Then Catalyst was introduced, but SwiftUI was introduced also. And the Catalyst bit basically calmed down completely – everyone's focused on SwiftUI because it was so amazing. The demonstration that Josh gave showing just how quickly he could basically build an app that had an AR component and all these things. It was like, “holy wow, that's amazing – that's everything I been looking for." Because so much time was spent building UI, and a lot of that just kind of vanished and it was great.
Paul Hudson: I felt bad for many of the other teams who launched stuff. I mean, iOS 13 was a big year: compositional collection views launched, SF Symbols launched, Catalyst, dark mode, and so on – it was a massive year by any standards.
But pretty much the only thing people were talking about was SwiftUI, and even though it was only fairly small back then because it was the initial release. It still just dominated discussion because it was such a big revolution for all of us.
"Compositional layout is huge. Using diffable data sources, huge. All of this stuff combined makes SwiftUI possible in a lot of ways."
Ish Shabazz: Absolutely. I did feel particularly bad for the folks who worked on collection views – they got such a dramatic update, right?
Compositional layout is huge. Using diffable data sources, huge. All of this stuff combined makes SwiftUI possible in a lot of ways. They didn't get the same amount of attention, but it's still major, huge stuff, I think particularly in the collection view realm, which solved so many prior problems.
Paul Hudson: I would never write an old-style collection view ever again in my life. Never again. The chap who wrote that code did amazing work, and I'm so grateful to him, but there's huge amount of love in the chat here for SF Symbols. And I realized recently I'm using it all the time. In every app I write I'm using SF Symbols. It's huge.
Ish Shabazz: SF Symbols is a really welcome addition. I saw someone using SF Symbols in their code comments! But SF Symbols in general I'm a huge fan of. Last year was great, but this year was even better, particularly with the multicolored ones. I think it's really just classic.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SAVE 50% All our books and bundles are half price for Black Friday, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
Link copied to your pasteboard.