Recorded – watch the full episode on YouTube.
You've mentioned that you think UIKit will eventually be overtaken by SwiftUI. How long do think it will be until SwiftUI really becomes the standard rather than UIKit?
Sean Allen: Yes. For new stuff. I think that is sooner, of course. Obviously we're all kind of waiting with bated breath to see what kind of improvements we get at WWDC here in a month, allegedly. And I think that will really, it's really hard for me to say that now, right.
Ask me in a month and that picture will be way clearer when we see what new stuff is announced for SwiftUI. If they announced some small incremental thing, it's going to take a little bit. If they come out of the gate with some crazy big monumental features and changes like, okay, now, now it's real.
But to kind of put a date on it, I do think after Dub Dub this year, you will start to see new projects grow and grow. And then almost certainly by, call it SwiftUI 3.0, who knows what they'll call it. But that's when I think it will turn the corner and I'm kind of basing that on how long it took Swift to turn the corner, right? We all know that the Swift two to Swift three horror stories, once Swift three kind of, that started this stabilization. And I think a lot of people really started taking Swift more seriously after that, the great renaming of Swift two to Swift three.
Paul Hudson: It's always amazed me how quickly Apple developers do jump on new stuff from Apple. It's usually very, very fast. And obviously as, as that drawback of, we have to support iOS 13 and iOS 12 and for some companies iOS 11 as well, that holds them back. But people really, really want to push forward and use the new core stuff.
So in iOS 13 that was things like compositional collection view layouts. They were huge. And there are the new diffable data sources, the really powerful features, and folks are really desperate to get there. And I think with SwiftUI there's a sort of fear of missing out. People see other folks going “oh SwiftUI is amazing.” And they're like, “no, I must write UIKit still.” And they just feel like they're being held back a little bit from where they want to be.
“In my experience, the bridge between SwiftUI and UIKit are very strong. And so as, as long as you can divide your work between SwiftUI work and UIKit work, it works brilliantly.”
Sean Allen: Yeah, I hate the iOS N minus one even, I just want to be on N. Get rid of the minus one. Like 75 to 80 percent people jump up right away on the upgrade. But I definitely agree with you. And I guess I have a question for you is... Because I'm just starting my SwiftUI journey with this project, and I'm a little worried about a certain feature.
Are you thinking right now again, before SwiftUI two comes out. Is it worth it to go all in, even though you're... I guess what I'm asking is are the headaches that you're inevitably going to run into because it's new, nobody knows nobody's like an expert yet. You're probably the closest thing to it. Is that headache worth it right now, before SwiftUI two?
Paul Hudson: In my experience, the bridge between SwiftUI and UIKit is very strong. And so as long as you can divide your work between SwiftUI and UIKit, it works brilliantly. The actual pain points, the real problem areas become when you've got your SwiftUI and put UIKit in there somewhere. And directly in there, not pushing to a new view controller, because that’s easy to do in SwiftUI. It's when you want to say, “huh, my table view in SwiftUI, a list, I want to adjust separators.” And you can't.
“As long as you separate your concerns compartmentalize, you'll have your little UIKit compartments, that when SwiftUI, is ready. It's very siloed off for you to just replace with SwiftUI. So, that's pretty encouraging.”
You can't inject UIKit in there. It doesn't work like that. You can push to a new UIKit screen. You can imbed a UIKit, UIView. But you can't just modify the underlying table. You can't monkey around with the navigation control or the navigation bar because there isn't one there with SwiftUI – it’s hidden away. That's the real pain point. And that is what I expect them to fix in a month, or two months when SwiftUI 2.0 lands. Of course, collection views, of course text views, all things that are missing currently. But, all of the linking points that we can’t currently fix the problems like the separators in lists for example. That's got to be top of the list surely.
Sean Allen: Yeah. But that's encouraging though, because like you said, as long as you separate your concerns compartmentalize, you'll have your little UIKit compartments, that when SwiftUI, is ready. It's very siloed off for you to just replace with SwiftUI. So, that's pretty encouraging.
Paul Hudson: I think that's really how it worked with Objective-C as well. People would have existing view controllers or whatever, model data in Objective-C and they'd do the new stuff, separate stuff in Swift. They wouldn't necessarily try and extend the Objective-C in Swift. That'd be problematic and painful in places. Better say, okay, this new controller, this new model, this new, whatever it is, that'll be in Swift. And let them to sort of incrementally adopt Swift rather than trying to rewrite because no one wants to rewrite.
Look, we've got brilliant UIKit code. We've got extremely talented UIKit developers out there. Years of maturity and testing, whatever works, no one wants to throw it away.
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.