Recorded – watch the full episode on YouTube.
What is your approach to finding errors in SwiftUI? Often Xcode complains about some random line and you end up deleting a lot of code to get to the underlying error.
Kaya Thomas: You know, they have some compiler improvements that fixed that a little bit with Swift 5.2, so that's helped. But before, a lot of it was deleting things one by one. Unfortunately I did the same kind of approach – I would delete a line, see what happened or change small things. Not changing a lot at once, so changing very incrementally to see what would happen, at least then you know that it's in the scope of a closure, right. So starting out there and then just going slowly to investigate what could potentially be the problem. A lot of my error messages usually ended up being some kind of type error – there was something wrong with the object that I was trying to use because I didn't have it either conformed correctly to the right protocols.
“So starting out there and then just going slowly to investigate what could potentially be the problem. A lot of my error messages usually ended up being some type of type error.”
Because with SwiftUI, there are quite a few protocols that you have to conform to, like
Identifiable and things like that, that have kind of strict requirements. And so a lot of the errors ended up being like that. But because the compile wasn't so great at exposing those areas, it was hard to find. So I would usually, I caught on after a while that a lot of times that was the error and so they were type errors. I'll usually start there and see, okay, are these correct? Are they conforming to the protocol correctly? And then going from there.
Paul Hudson: I think I'd often find three kinds of errors. One is, “you've made a mistake, fool – here's the error,” right? That was good. I liked those. The other one would be something like,
VStack has an unknown tuple thing, and okay, that isn't helpful. It's pointing out the wrong thing entirely. They are the worst kind. The middling kind, I kind of liked actually, were the obviously wrong error messages. Like, can't convert this regular Int to an optional Int or the other way around. Well, no, you can do that, Swift. I know you can do that, Swift. You can totally do that yourself, Swift. But it's choosing not to.
So basically it's a red herring, but it was an obvious red herring. Unlike the useless
VStack error, the obvious red herrings were quite helpful because then you start doing your binary chop. Take out half the code. It wasn't that half. Take out half of the remainder. It wasn't that half. Oh, it's there somewhere and you get there. But as Kaya said, Holly Borla and her colleagues at Apple and the Swift team have done amazing work on Swift 5.2.
“I think we would all prefer a native solution. So I think it's still rough. And I think hopefully, SwiftUI 2 will be a little bit of a saving grace.”
Kaya Thomas: I think it's still quite rough. I think that there are definitely bugs they've fixed, which have been great, but there are still a lot of gaps. And I think some of the things that we had mentioned that don't exist in SwiftUI, but exist in UIKit like collection view and those things, I think those are just kind of essential to basic app development. And so definitely you can use, there are some great libraries up there from the community that have kind of tried to fill these gaps. But of course I think we would all prefer a native solution. So I think it's still rough. And I think hopefully, SwiftUI 2 will be a little bit of a saving grace.
Paul Hudson: When you see Steve Breen's talk from WWDC19 about compositional collection views, you're like, “oh wow, this is amazing." And SwiftUI is like, “see this? Not for you." So that was hard. But UIKit isn't standing still, right? UIKit is going to carry on developing. They're not going to hang around and pause UIKit to fill-in SwiftUI. Which presumably means this year, SwiftUI has to add in all the missing features from WWDC 19, 18, 17, and so forth, plus anything new from WWDC20 in UIKit. So it's a moving target. Do you think that's actually feasible, or will take a few years to catch up?
“So SwiftUI might always be a little bit behind until they make a point to say, "Okay, it's at a good point. We're going to be 100% investing in SwiftUI.”
Kaya Thomas: That's a really good point. I do think that it will take some years to catch up because I don't think they're going to divest in UIKit. I think with WWDC20, there were a lot of great UIKit improvements like you mentioned, the compositional layout for collection views, and table views, and diffable data sources. There were a lot of great UIKit improvements, and so I don't think those are going to be stopping a standstill. So SwiftUI might always be a little bit behind until they make a point to say, “okay, it's at a good point. We're going to be 100% investing in SwiftUI.” But I really don't know when that would happen. I think maybe five years from now or so, but that's just a guess. But I do think that SwiftUI will be playing catch up or a couple of years.
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.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.