What would you like to see WWDC20 delivering?

Recorded March 28th 2020 – watch the full episode on YouTube.

What's on your wishlist for SwiftUI from WWDC20 this year?

John Sundell: So my main thing would be to, and I know that this was a strategy, in fact, when I spoke to Josh Shaffer, one of the creators of SwiftUI, on my podcast a few months ago, he also mentioned that they deliberately kept the API surface small so that they could focus on the fundamentals. So they didn't go for full coverage. And you mentioned earlier that you have to now bring in MapKit, you have to bring in certain UIKit aspects.

So my expectation and hope would be that this year they are expanding the API surface drastically, that they are covering a lot more frameworks, that you can take MapKit and just put it in SwiftUI immediately. There's just a map that you can just put there, right? That even things like, right now you have to wrap things like activity indicators, right, fundamental things that are not there.

“So my expectation and hope would be that this year they are expanding the API surface drastically, that they are covering a lot more frameworks, that you can take MapKit and just put it in SwiftUI immediately.”

And again, I know that that was a deliberate strategy on their part. It's not that they forgot about it, right? They didn't just forget the activity indicator, it was a deliberate strategy. But I think it's time now to expand that and to also focus on, especially the cross platform stability. Because SwiftUI is quite stable, I feel, when you're using it on one platform, but once you start to try to have the same view render correctly on Mac, on iOS, on watchOS, you're trying to build that dream cross-platform UI, you sometimes need to deploy very platform specific kind of hacks in order to make it render correctly.

So I would love to see that also be kind of addressed as well, the stability aspect, especially the cross platform stability aspect. Which I think will kind of naturally happen as Apple keeps kind of dogfooding it, because at least from what I've heard, what Apple is using SwiftUI mostly for right now internally is on the Apple Watch, for watchOS, at least in the last release from 2019. So my hope is also that this year they will expand that to use SwiftUI to buy themselves a lot more across their platforms so that they will be able to dog food and address those shortcomings.

Paul Hudson: It's also worth remembering that UIKit, AppKit, MapKit, and so forth, they aren't standing still. UIKit is here and SwiftUI is here to support the subset of UIKit right now. And it's going to move forward to hopefully more close to Parity in 2020. But will UIKit stand still? Probably not. They're going to move forward as well. And will that distance, that delta shrink over time? I really hope so, but equally I also want the UIKit folks to keep on pushing that forward, because there are however many millions of apps out there shipping on UIKit, relying on UIKit being awesome and being expansive and being exciting for many years yet.

John Sundell: Absolutely. And again, it comes down to trying to not fall into the trap of having that binary thinking. For SwiftUI to win, UIKit does not have to lose. Just like how, even to this day, for Swift to win, Objective-C does not have to lose. And you could see that with Objective-C, after Swift came out, Objective-C kept improving and they got lightweight generics and all sorts of cool things that made Objective-C a better language as well. And I think the same thing will happen here as well. And I think it's important for us to not just say that you have to go all in on SwiftUI or nothing. I don't think at all that, that's not my mindset at all.

I was coding a lot of SwiftUI yesterday and I was almost using as much AppKit as I was using SwiftUI. And some people might consider that a failure of SwiftUI, I consider that a strength, the fact that you can mix and match and you can gradually move to the new paradigm and you can use the declarative DSL while still bringing in your other views as well. I consider all of those things great aspects of the SwiftUI design, and I'm happy that it's designed that way.

“It's better for Apple, it's better for the stability, and it's better for us who already have existing code basis that we want to migrate to the new platform.”

So if we have to live in this world for a few more years where we have to kind of bridge the gap between the two and we have to gradually move, I think that's just better for everybody. It's better for Apple, it's better for the stability, and it's better for us who already have existing code basis that we want to migrate to the new platform. I think it's just a great aspect of SwiftUI that you were able to mix and match.

Paul Hudson: Yeah. So RaveMaster31 is saying, I thought Apple said, learn once, use everywhere. And this is actually a complicated, obviously Java-inspired phrase of taking some code and running it on all platforms. But Apple have tried to be quite specific about this. They want you to learn the techniques once, learn the basic structure of stuff once, and apply those thought processes everywhere, but then say, okay, I'm on Mac now, I'm optimized for a higher density screen, or I'm on Watch now, I'm going to add digital crown support, or I'm on tvOS now, I'm got to add a play/pause button. And those little things are what stop SwiftUI from being write once run everywhere, but in a good way, because it means you tailor your software specifically to be great on Mac and then great on iOS and then great on watchOS, separately, while sharing many things.

John Sundell: I think, what I meant earlier when I said the cross-platform kind of inconsistencies or bugs or problems that are right now, it's not so much that I'm looking to have one code base that I can just hit run and it will just automatically run on all platforms and it will magically look amazing, it's more about that I would expect things to behave the same way, right? So you can really have that learn once, write everywhere, kind of experience, right? That you learn, for example, navigation view. Okay, I know how that works on iOS, I expect that to work the same way on Mac.

And to most parts it does, but there are some subtleties here and there currently that, especially if you're looking for certain navigation patterns that are maybe not as easy to translate between iOS and the Mac, for example, if you have a sidebar and you want to display something in a content view, that is very different from having a navigation stack and pushing new views onto a navigation stack, right? So the way you use navigation links and how you activate your views are a little bit different and maybe will need to be different, but I think there's ways to kind of make that API a little bit nicer to work with and nicer to learn across platforms.

Paul Hudson: For example, navigation view and navigation link are particularly interesting one because navigation link exists on watchOS and work just like it works in iOS, it pushes a new screen in, but navigation view does not exist. You can have navigation links without navigation view, and it's like, I've just going to take out this thing for no real reason, it makes a simple file incompatible. So you write a little wrapper that basically is a navigation view on iOS and macOS, or it's a simple VStack on watchOS, it's like you can just remove that roadblock for me, Apple.

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