Episode 244

Kevin, Jon and Rob talk to Ben Scheirman about developing user interfaces for the Apple platform with SwiftUI and Combine.

Ben screencasts at NSScreencast and is the creator of the Combine Swift course.

Download / Listen: Herding Code 244: Herding Code 244: Ben Scheirman on SwiftUI and Combine

Links:

Ben is @subdigital on Twitter
Combine Swift - a Combine course for mere mortals
NSScreencast - Top-notch tutorials for Swift developers
SwiftUI overview in Apple developer docs
Combine overview in Apple developer docs

Transcript:

Herding Code - March 5, 2021 - Ben Schierman on SwiftUI and Combine

Kevin: [00:00:00] Hello, welcome to another episode of Herding Code , our quarterly episode here. This is being recorded on March 367 2021. And today we were talking to Ben Schierman. Ben runs NSScreencast, which is a video training site for all things iOS and Apple development, and Ben's going to talk to us today about SwiftUI, a relatively new UI framework from Apple for writing Apple platform applications. So thanks for joining us, Ben.

Ben: [00:00:40] Well, thanks for inviting me. It's good to be here.

Kevin: [00:00:42] So why don't we start with the sort of high level, you know, what is SwiftUI? What makes it different? Like what, how is it different than what came before it.

Ben: [00:00:50] So there's a lot of history and the Apple development community. We've had AppKit for 30 years now which follows a kind of model view controller based approach. And then when the iPhone came out, they, they sorta took lessons learned from that. And. And created UI kit. And so when you look at creating apps for the Mac or apps for the iPhone, if you squint, they're extremely similar.

But app kit has that, you know, 20, 30 years of legacy cruft that they just can never throw away. And so you know, things are a little bit different. Like, you know, you have UI color versus NS color UI being the UI kit version for the iOS. And, and then you have things like the coordinate system on the Mac is.

The origins in the lower left corner, which hearkens back to the, I guess the, the way they used to send commands to the printer or something, I don't really know, but on iOS, the, the origin is, is you know, top left. And so there's, you know, minor differences here and there, but ultimately you've got views that know how to draw themselves they're object oriented.

So you can have a subclass of a view that is a button or a label. And you know, the API is, are, are pretty strong, but There's there's always, you know, as our applications get more complex sometimes people complain about the patterns not being enough. And people joke about MVC standing for massive view controller instead of model view controller.

Because, you know, when you give somebody a pattern and say, this is where you put your logic, they tend to put all the code there. And anyway, so last year wait, Time is meaningless nowadays. This is, you know, at least five years ago in, in COVID time Apple released a SwiftUI, which is kind of a radical new UI framework for, for writing in air quotes, cross-platform applications.

As long as your platform comes from Apple it will work on T V U S and the Mac and the watch and the iPhone and the iPad. And SwiftUI takes just a totally different approach to, to writing user interfaces. So instead of model view controller, instead of your views being object oriented you know, and the model view controller world you would typically have of you that you would create say, I'm going to create like a new UI label and I'm gonna attach it as a sub view of my main view.

And then I might read a model. In order to tell what the text property of my label's going to be. So like on a viewed load, I could say, okay you know, a model dot first name, I'm going to assign that to my labels, text property. But there's nothing in that relationship. That's going to continually keep that up to date.

So I have to respond to events and note or re sort of update my model again. Well, SwiftUI is totally different where the view that you create in SwiftUI, Is a struct it's, it's meant to be thrown away and recreated anytime the model changes and it's balanced to the model. So you can say that I have I have this object that I'm going to observe, and whenever those properties changes, I know I need to rerender myself.

And because it's a struct and everything that we're building is value types. They can be thrown away and recreated really quickly. And so it's a totally different approach and kind of, you know, from a traditional model view controller mindset. It kind of bends your brain to think about how, how you write this.

That said it's pretty amazing because they have you know, the support in Xcode is you've got your code on the left and a UI preview on the right. And as you type, it shows you what you're building. And so you can kind of flesh things out, like really quickly without even hitting, you know, you don't have to compile it just updates.

And so these live previews that you get when writing SwiftUI are just really incredible. And it's, it's one of my favorite features in doing this because the feedback you get is so rapid.

Rob: [00:04:17] It sounds like they're trying to do a more of a functional approach if they're using strucks and like immutable data. I mean, is that how it feels to you?

Ben: [00:04:27] Yeah, absolutely. It fits in really well with like there are, there are things that you just don't really. Like most, most of the examples are like, if I have a user object and I'm going to create a screen that shows like a profile view, I can, I can create an image view and I can set the image property to the, you know, some URL that came from my model.

And I can set some text labels to, you know, the properties from my model as well. And that all works really well. But then you have these other things that don't really seem state driven. Like I want to present a modal screen on top of this, if the user's account is delinquent or whatever. So that modal sheet presentation is usually like some imperative logic that would happen in you know, in a method you would just check for the condition and say, Oh, I want to present this now, but in a functional world, it's all state-driven so.

Instead you'd need a source of truth that says like, is the sheet presented? And that's like a property on your model object that you then mutate. And because you decide to, or when you want to to show that sheet, you have to set that property to true, which, you know, it just, it's like a, definitely a different style of thinking.

But as you start to build your UI where everything, every interaction in the UI is driven from state. You know, it starts to lean straight toward the functional style of building applications and having your UI sort of just be a function of the state.

Rob: [00:05:57] Interesting. You know, like in my head, I'm imagining a kind of render pipeline process pipeline that you're going to send an NSMonad through. I wonder when that's going to happen. Yeah.

Kevin: [00:06:10] It's too early in the conversation to go to monads.

Rob: [00:06:14] How long ago did they speak functional? Monads got followed within two minutes.

Ben: [00:06:22] I don't even know how to follow up with that.

Rob: [00:06:25] And thank you. This is Rob's podcast. Interview ability right here. Just created the interview straight away.

Ben: [00:06:31] So I would say that rather than, than focusing on the, like the functional nature of it, it's, it's definitely leaning more towards the reactive nature, which I think a lot of people are familiar with. We have frameworks like reactive JS and the whole reactive ecosystem. Reactive Swift is are pretty popular or RX Swift, RxJS, those, those platforms I don't know if you call that that's more of a framework, but those are pretty popular and Apple just released their Combine framework, which is basically the, their take on a functional, reactive framework for processing streams of events over time.

And I've dug in deep to combine and I find it, some of the aspects of, you know, porting my event driven code to combine has like, Just change the way I write software in general and combine and SwiftUI kind of fit hand in hand, it's like peanut butter and jelly. It it's like when you start using one, you'll probably start using the other because they just, it, it makes things so much more decorative.

And so it being a declarativeframework that tends to like drive how you write your application from the get-go because. Things aren't so imperative. There's not like one place where like, okay, here's where I write the code. It's like, you're you're instead you're thinking more about models and state and then building up your views aro...