Herding Code 244: Ben Scheirman on SwiftUI and Combine

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

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 around that.

Jon: [00:07:53] Sometimes when you move from an imperative style to a declarative style, like 90% of the time, it’s awesome because it cuts down your code and it like allows you to describe what you want to happen. Sometimes it can be a little tough to troubleshoot what the heck is going on because things may have side effects or, you know what I mean?

You change one that you’re not sure what is driving an update. That sort of thing is, is that a, is that a problem you run into with this.

Ben: [00:08:20] Yes. I think that’s probably a universal truth that like the more declarative and the more like magic you get, the harder it is when something breaks down and. And trying to figure out what, what is going on, what I found to be really helpful. Just in general, on the Combine side of things you have it’s basically like a functional pipeline where you say, like, let’s say I have an array of characters from a movie or whatever.

I can filter the array. I can map the characters to their last name or whatever. And I can add delays and debounces and stuff like that. And then when you think, well, it doesn’t really have to be an array. It could be a network response, or it could be user tapping on the screen. Right? Any source of events can be transformed in the same way.

And so they have some tools that you can just insert in the middle of this pipeline to say, I just want to print out and know when this is happening, or I want to insert this little side effect block. That’s just going to sit in the middle and let me set a break point or you know, print out values or whatever.

And I’ll just delete that when I’m done, but it doesn’t affect the chain. It still passes the values downstream. So you have some ability to diagnose like the data flow on the SwiftUI side I find that to be also true, where you’ve got a lot of things happening and the more complicated review becomes, you know, true strives you to say, okay, I want to make this a smaller thing.

I want, I want to design things at really small, granular level. And I mentioned the the SwiftUI preview you know, on the right side of the editor, you can create previews for whatever you want. It doesn’t have to be an entire screen. So I can have say we’ve got a screen that has like a, that avatar that that we want to, you know, round the corners, make it a circle and put a border around it and a shadow or whatever.

I could just like. Create a new SwiftUI view avatar view and just zero in on just that one component. And then I can see how it looks on large screens, how it looks on small screens, how it looks in dark mode how it looks if we have accessibility, like low contrast settings turned on or whatever, and I can have all those previews up at the same time when I’m working on that one component you can also do.

Interactive like user interaction in these previous as well, because it’s running a simulator iOS simulator behind the scenes. So if I’m doing a button component and I want to be able to tell like, okay, here’s the button in? Like it’s 12 different States. I’ve got different background colors. I’ve got one that has a spinner embedded in the, in the button.

And I’ve got like depressed States and highlighted States and, and disabled States and all that. And I also want to be able to like animate, you know, maybe when he, we push the button, maybe we want to animate that the shadow kind of gets smaller or whatever to indicate that the buttons kind of going into the interface a little bit.

It’s, skeuomorphism, it’s coming back. Things like that, I think are it’s, it’s real, it’s really just not fun to be designing something like that. And it’s like that button say is like two screens deep into your UI. And if you run, you have to build and run the application and like, okay. Click to the screen, you know, just that turnaround time.

It’s just. Not fun and the faster I can get to, I would just really like to be able to click on it right there inside of Xcode. And SwiftUI previews lets me do that. I can actually run the preview, which runs an instance of SwiftUI standalone and then, you know, click through and toggle it and be able to design these things at the small level and then use that in a bigger context.

So I think, you know, to, to circle back around to your question, like when things don’t go right. Or, or confusing. I tried to like zero in on little components and try to make their you know, the data flow more obvious and, and to design the UI in a, in a way that I can start small and just grow out from there.

Kevin: [00:11:52] So when I’ve, when I’ve done a little bit, I’ve done a little bit of SwiftUI and I definitely have hit situations where that preview thing sort of breaks and you can’t really tell why, and I’ve never been sure if it’s just me doing something stupid or, you know, I’m hitting some, like, you know, I’m trying to do something in my view that just not supported or is that a, is that a common problem or is that something that.

Ben: [00:12:14] it’s a common problem, but I’ve been able to get around it. Again, just going back to the, make things simpler, you can comment out stuff and, and until it renders, all of a sudden will pop in. You’d be like, okay, it’s something with between this part. And this part, there is a Little like a little diagnostics button, that’ll say like the preview agent crashed and you can click diagnostics and it literally never tells me anything helpful.

But if you go to on a Mac in your home folder, library logs, diagnostic reports That’s where all your crash logs show up and Xcode will have a crash log in there. And so I just keep that window open. And so when the preview stops loading it’s because they tried to run the app and I did something I’m not supposed to.

And anyway, so usually I can go in there and it literally the crash log shows me the line number of the problem. So Xcode has all this data at its fingertips. It’s just not quite right. It’s not quite helpful enough to tell you exactly where the line is in the editor you’re using. But I think that will improve over time.

Jon: [00:13:15] You mentioned components so different, there’s different. Like it’s useful to build with components and stuff. Is there actually like a, an ecosystem? Do people sell components? Is there like a packaging and distribution thing for components?

Ben: [00:13:28] So we have Swift package manager, which is just starting to become useful. Before that we had a couple of, you know community driven efforts to bring independencies. Nothing like what I remember when I used to be a .NET developer where people would sell like package products and they come with support and stuff like that.

There’s, there’s not a lot of that happening in the Swift community. I can think of one success story. And I’ve met the founder and he’s he’s a good. He’s a good guy and he’s built a huge company off of PDF controls and rendering and stuff like that. So if you’ve used an app that, that embeds like PDF editing or scanning or whatever, chances are, you probably use his component.

And that’s a PS PDF kit, but outside of that, I’m not really aware of like a healthy ecosystem for like selling those types of components. But if yeah, open source, we can definitely see You know, bringing in a Swift package and being able to access all of its functionality, whether it’s it, whether it’s like talking to services or if it’s UI based.

I do think that in the iOS community in general, and I suppose this is probably more of a a community where you deploy software onto people’s devices and they may never update them again. You’re generally a little bit more conservative over throwing other people’s code. Into your projects. And there have been some in the early days especially there, there were some pretty bad horror stories about frameworks that did too much or had bad code in them and stuff like that.

And they might cause your app to crash and it’s, you know, it’s not your fault, but it’s your problem type of thing. And, and so I think that there are pockets in the community that are just like no dependencies ever which that extreme I don’t agree with. But but I do think that the, you should take dependencies like that with a healthy dose of skepticism.

And you should be able to read the code if possible and make sure that you’re comfortable putting it in your project because you are going to deploy it onto, you know, hopefully lots of devices and, and you have no control at that point. You can’t force them to update. Whereas, you know, I also do web development.

So if you make a mistake there, you can always push again. Right.

Jon: [00:15:38] You mentioned  like the reactive Swift and  there’ve been things out there for awhile.  So Combine is new and from Apple, is that the main difference is that it’s now like in the box and official?

Ben: [00:15:50] Yes. Yeah, so I just recently launched a course on Combine and it’s at CombineSwift.com. And in, in the course, it was basically like why now? Like these open source has shown that this is not only a popular choice for iOS developers, but across many platforms that RX star ecosystem is huge. And they generally follow the convention.

So if you’re familiar with one on JavaScript, for instance, you’d probably be quite familiar with it on Swift. The, the differences is that, you know, when. Like for instance, I I’m a consultant, so I’ll go work on a project for six months or something, and then I’ll help them hire a team or, or whatever.

And at some point I’m going to be giving this code to somebody else. And I always felt like that decision, that sort of like the calculus of like, is it responsible for me to choose like insert fringe framework name here? I want to make sure that I enable my clients to be successful. And while I personally think that those frameworks were interesting.

I never came across a situation where a client was asking for that. And especially if you’re trying to hire from the broadest pool of developers unless you’re willing to train them on a topic, I think this would probably be different if it was like my team, my company, you know, I would decide on what tools to use and train the people who are gonna to work on it.

But, so I think that there’s something to be said about kind of sticking with the middle of the road. You know, I, you know, my, my web development platform choices, rails, and in rails, there are strong opinions and they’re strong conventions and I get on a new you know, I’m on a project right now and it’s very complicated, but I can look at their rails app on the backend.

And I. Pretty much know how to read it. And I know where things are and I know how to, you know, so there’s something to be said about sticking with those kind of norms. But now I think it’s different because Apple is committed to supporting it right there. They’re going to be making sure that, you know, it doesn’t break with a future version or they don’t bring out some new technology.

That’s just completely incompatible with that style of development. And so I think that’s where the difference is. There are some. You know, probably some growing pains that they have to go through making the framework as robust as RX Swift, for instance. But the majority of the pieces are there and, and you can build the ones that aren’t.

Jon: [00:18:09] Hmm. Yeah, that’s something I. Working with the net team at Microsoft. We struggle with this all the time. Right? It’s like there can be a popular opensource thing out there for awhile. And then people enterprises, you know, want an official thing in the box. And it’s always that challenge of like, what do you ship in the box and what do you not, you know, rely on

Ben: [00:18:32] Yeah. And I’ve worked for an enterprise insulting and the dotnet space many moons ago. And they had a blanket yes. To anything that Microsoft. Gave us and a blanket. No. To anything that was outside that. And Rob, I don’t know if you, you probably don’t remember this, but this was like eons ago and I wanted to use subsonic on this project and they they said, no

Rob: [00:18:54] What is SubSonic again?

Ben: [00:18:57] I don’t remember.

Rob: [00:18:59] You know, I still get pull requests. I still get pull requests.

Jon: [00:19:03] Yeah. Would you approve mine, please?

Rob: [00:19:05] No, I’m…

Jon: [00:19:06] It makes sense. It runs!

Rob: [00:19:07] Got right, Jon. You’ve got to learn to write you to tests.

Jon: [00:19:11] It’s a fad.

Ben: [00:19:13] Yeah, it’s definitely like, I take caution and saying like, it’s good because it comes from Apple because it’s not necessarily true. You know, I like apples frameworks. I like the platform a lot. But when, when something does come from the company that you. You know, your product is based on, there’s a sense of certainty and that it’s going to be more mainstream for other developers as well.

Rob: [00:19:37] So…

Ben: [00:19:38] Not just a fringe thing.

Rob: [00:19:39] I’ve mentioned, I have a question on that. I, I think you and I talked about this when you were launching your, your service, the CombineSwift.com and, and you were asking about platforms and whatnot and you ended up writing own, right?

Ben: [00:19:55] Yes.

Rob: [00:19:56] Yeah, no. So, I mean, I’m, I’m, I’m sitting here on the site, CombineSwift.com.

I’m looking at it. And this is a, you wrote this, you wrote this with rails. I find that just fascinating. Like we’re having this discussion about. You know, platforms. And what about you is whatever you went with, what you knew and you wrote what you knew. And for me, I sell books, I sell videos, right. And like try and figure out how to try and figure out the mechanism to do that is such a challenge because

Ben: [00:20:23] Well, I wouldn’t necessarily recommend it.

Rob: [00:20:25] But it’s beautiful.

It’s wonderful.

Ben: [00:20:29] The reason why I say that is that I, I am incredibly picky.

I find one thing, you know, I like, I looked at teachable for instance and I know some people have launched stuff on teachable and I don’t even, I couldn’t even pinpoint right now what it was that was like, nah, but it was just one of those things.

I’m like, I it’s it’s, I guess it’s the curse of like, I know how to write this stuff and it’s also fun, at least in the moment to be writing it now that I’m paying for it and supporting it and. I’m having to deal with some stupid web packer issue right now. It’s like, I’m like, why did I choose to

Jon: [00:21:03] it off.

Ben: [00:21:03] Yeah, it’s definitely a trade off.

Rob: [00:21:06] Well, I do find it interesting that, you know, when we’re talking about these things about, you know, what you’re willing to accept or not, I mean, you just leaned into rails and you built the thing you wanted, and I fully agree with you. I started on Kajabi was it a year ago trying to do this thing? And yeah, it took me about three months to realize it didn’t do what I wanted to do.

Same with podia, same with like so many other things. And so I ended up just writing my own I using Firebase and you have pages for mine and it works great in view, I should say there is, I mean, I hear what you’re saying. It’s, it’s troublesome, but at the same time, it’s rewarding when you know the platform, you know how to solve a problem because you can get in there and solve it.

So I don’t want to take us to too far on a tangent, but you brought up rails. And I think, like you said, you know where the code is, you know, where the thing is, that is huge. A year down the line when you’re like, why didn’t this thing work? Well, I’m going to go right to the spot because I know that’s where it is.

Kevin: [00:22:02] So when SwiftUI first came out, it was pretty bare bones, pretty rough, as I recall. And then the last, the last big upgrade, they added a bunch of stuff. I’m like, where is it in terms of maturity? Like what kind of apps would you build with it? What kind of apps would you have not built with it?

You know, whereas it, it sort of in its life cycle,

Ben: [00:22:21] So I would say I’m both a extreme optimist and also somewhat pessimistic. If that makes sense at all, like the 80% you, it is unbelievable how fast you can get to the 80%. Like it’s, it’s so enticing when you see how fast it can be to develop things as small components. And when you think about Like there’s, there’s some ceremony and stuff like that that happens.

Like when you, when you’re building like a to-do list app on iOS and all of those things make sense when you’re building like a big project and you need to you need to modularize your code and you need to like isolate things. So you’ve got, you know, a controller and a view, and that view has subclasses for sub views and things like that.

But Sometimes those things are just there because you need a view to go in that spot. It’s not like you don’t necessarily need to create, like, how do I say this? Sometimes there’s just too much ceremony for the level of application you’re building. If that makes sense. I like that kind of a fine grain structure and, you know, attention to detail and the ability to split things off into components when my application is complex enough for that.

But if I’m building it to do app for, for instance, my screencasts that I do, like all the time, I kind of get frustrated with how. Mundane like creating a, a collection view for instances like there’s, there’s just a lot of steps to it. And I find that like in SwiftUI, I can get, I can get there in like 10 minutes, like full to do full, to do app.

I probably shouldn’t have said that cause now Rob’s going to challenge me to do it. But I just feel like there’s like the easy stuff is so unbelievably easy. That said the remaining 20% is sometimes you hit a brick wall and I’m working with two apps right now that I one is just a personal project of mine.

I’ve been struggling with tinnitus for like a little over a year now. And I decided to build an app that would help with this particular type of tinnitus therapy. And so it deals with audio and it’s like, it’s super fun. And I decided to do this, like a bouncy little wave form animation to sort of give you some visual feedback as you’re changing the frequency and the volume of your of your tinnitus frequency.

And it looks pretty amazing and I’m very happy with it. But it crashes in a way that I can’t reproduce, and this is the only thing preventing me from shipping it. And so I just kind of put it on the back burner for now because I’m like, I got to ask, I think I’ve got to ask Apple about that one.

Cause I, I’m at a loss and I don’t want to ship something that I know crashes. So anyway, and then I’m working on another app with a designer friend of mine. I know, I know the podcast, people can’t see it, but it’s basically, there’s this book that he wrote full of these puzzles and the puzzles are called the Rebus puzzles.

And so they have like these icons and your job is to figure out what it is. So, yeah, so I’m holding up this book and it has a spider and a man icon. And then the other one is a bacon and eggs on the top and a golf club on the bottom. So that’s breakfast club. So this is all movies, right? And so the idea is for it to be kind of like a, a puzzle app that responds to texts and voice and stuff like that.

And it’s pretty amazing, but I’m starting to hit those edges where like those quick wins are gone. And now I’m like, I don’t know how to hide the navigation bar when I scroll up because, and this is like the stupidest thing to get hung up on. Right. But it’s because I don’t have the hook that I need. And there, there are things like that, which I get kind of frustrated with.

So I wouldn’t like say a hundred percent SwiftUI all day, every day, but I would say that, yes. Whatever project I go with from this point, onward, a significant portion of it would probably be in SwiftUI UI.

Rob: [00:26:09] I have a question. And given, given that all of y’all have done this right. It’s I swear to God, I’m not trolling anyone here, but in you describing, I think what you said was I can build a, to do app and, you know, and you said to, Rob’s going to make me do it. No, it actually made me think of. ASP.NET 2.0, where you could drag and drop your data sources and line stuff up and bang stuff out so fast.

And then I, you know, my, my brain kind of locked onto that, but then all of the things that you’re describing now, but the fringe cases, I can’t quite get the property hook. I can’t quite

Ben: [00:26:48] Yeah, this is not a new problem at all.

Rob: [00:26:50] Yeah. Well, it’s funny because like, sometimes I think about this and, and you know, of course maybe it’s just me being an old guy.

I don’t know. Dude, what we had with web forums was insane productivity. It was insanity, of course, right. There’s a bunch of problems with it, technically speaking and testing and all that stuff. But I mean, sometimes I think about this, like you want a sortable draggable droppable grid that has search built in with a, you know, an event hook that you can go and do stuff.

I think about that. And I just keep thinking, like, sometimes all of this stuff just seems so sickly. So anyway, the reason I’m bringing this up to you is, and this is a legitimate question. I swear. I’m not trolling you, does it ever feel like you’re doing this again? All the things you did back then, and now you’re doing…

Ben: [00:27:33] Yes, but I have the context and the hindsight to like recognize some key differences. I think because I was there during that time and I was one of the people who said like, Oh, this designer thing, isn’t going to work because five minutes after the demo is over, I’m going to need to like. I I’m going to need to like transform this data.

And I just, I just selected that field from a dropdown in a GUI somewhere, and now I’m lost right now. I need to like hook in and actually on the Mac, this is a good sort of similar point on the Mac in app kit. You have bindings. And so there’s, you can, with a GUI tool, you can say like, Oh, I’ve got this array of people and I want to take the first name and I’m going to bind it to this thing.

And this is how like grids and stuff like that are built on. On on the Mac app. And so like there’s a row controller and it’s got a model and whatever, that’s amazing. As long as you type all of the things correctly, there’s no code completion. It’s in some property pane, GUI, somewhere in a drop down and good luck getting a source control.

If that makes any sense that these are all the problems that like, I think that ASP.NET also had You know, when we’re trying to do these things. What I like about the SwiftUI part of this is that I think that the, the good architecture and the ability to hook in where you need to is almost there, like for the majority of stuff it is there.

And I think that the, the cases where I’m getting hung up on are, are things that I’m certain I can get around. But I, I like the fact that it’s not like there’s a design time experience and a code experience. And I, and like, in, in, when I was doing ASP.NET, I was like, Oh, I’m a, I’m a code behind type of person.

Like, I don’t need that designer. It’s not like that. It’s like, there’s one representation and it is the code. And the UI is, is you know, automatically update actually the UI, the preview, you can right. Click on it and like, Manipulate stuff. And it actually writes the code for you also,

Rob: [00:29:23] Okay, honest question.

Ben: [00:29:24] Crazy.

Rob: [00:29:25] When’s the last time you had to edit XML?

 Ben: [00:29:28] I don’t know, five years ago. I don’t know.

Rob: [00:29:31] Now, you know, I do want to make it clear I’m I, I’m not, I, I am not trying to like, and excavate in SwiftUI and all that to you know, technology that’s 10 plus years old. I’m just to me, it’s like the idea, the idea of the designer, the idea of we can abstract this away now to a visual interface. I think it’s fascinating.

In fact, I feel like it’s coming. Like, I feel like. If someone was to come out with a rails UI or something like that, like it would make perfect sense. Cause it’s all just so known. Like we can now put a UX or UI on top of it and just drag and drop stuff. You know what I mean? Cause

Ben: [00:30:06] Well, I mean, this isn’t drag and drop, right? It’s it’s declarative UI code,

Rob: [00:30:11] Aye. Right. I’m sorry. I’m not really I’m not trying to conflate the two. I know I am, but I’m not trying to conflate the two. I’m just saying like the ease. Of getting from zero to whatever, you know, zero to a hundred is so

Ben: [00:30:22] Yeah. I think that.

Rob: [00:30:24] cases,

Ben: [00:30:24] The differences are what happens when you do go off the rails and how painful is that?

Jon: [00:30:29] that’s the whole thing. I’ve been thinking this the whole time. It’s like that transfer, like getting started, getting something going quickly, hitting 90% of the use cases is great. As long as when you get to that, that cut-over where you’ve got to get down and you need the hooks you need access to, you know, and you need to be able to find where is this thing set up or where is it, you know, where do I hook in and how quick can I fix this?

Ben: [00:30:54] And can I put a break point on it?

Jon: [00:30:56] Yeah. Yeah.

Ben: [00:30:57] One thing I want to bring up about the, like Kevin, back to your question about like, would I use this in a real app or how big of an app or whatever. And I mentioned that I would use switch UI for a major part of it, if I could The Apple’s done a pretty good job of making the UI kit and SwiftUI be able to include each other.

So in a UI kit based app, I view controllers and views. I can create a, what they call a UI hosting view and put a SwiftUI inside of that. And it renders. So I can have just like my settings screen or just, I could just have that avatar view that I designed or my custom button that could just be my only SwiftUI.

Part of the entire app if I want it. And then the, the reverse is also true. If I’ve got something that I wrote in UI kit, either a UI view or a UI view controller, including all of Apple’s stuff, I can I can create a UI view wrapper that includes that. And then there there’s some necessary hooks that you have to create to make sure it stays up to date because in a, in a world where all of your views are value types.

They get thrown away and recreated because it’s cheap, you know, it’s, it’s not free, but it’s super cheap to do so. Whereas objects on the heat are, you don’t want to throw those away and rerender every time a user is typing in character. And so you, those stick around and then there’s an update to method that you can use to kind of synchronize that view with your, with your model.

And so I use that a lot so that I can kind of mix the two. And because of that, my SwiftUI preview functionality and Xcode works actually for almost all the code that I work. I write now because I can create that little wrapper just for my preview and get that live editing experience on stuff.

That isn’t, hasn’t nothing to do with SwiftUI. It’s a little bit slower because it has to create that stuff behind the scenes. But this kind of my main approach to working on applications these days, Mike, my current client that I’m working on doing a fresh build takes like four or five minutes. So if I’m like, Oh, this needs four pixels of padding instead of six.

Like that is just a nightmare. And I don’t want to do, I don’t want to build and run and have to like make those kinds of tweaks and have that feedback cycle be so long. And so, you know, breaking the app out into smaller components and being able to use these previous right. And Xcode I think is just hugely powerful.

Kevin: [00:33:21] Both ways like you have an existing UI kit based application, you can start building some stuff, some parts of it in SwiftUI and integrate it and vice versa. You can, you know, you have SwiftUI application. You can. Yeah. Great. Cool.

Ben: [00:33:38] There’s a, there’s a chocolate and peanut butter joke in here somewhere.

Jon: [00:33:43] So what’s the overall like workflow. Okay. You, you, haven’t an idea for a new app. You want to build what’s your general, like, it sounds like there’s a lot of like iterating on the design side, but how do you actually, like, you know what I mean? How would you, how would you go from, I’ve got an idea to I’m shipping an app.

Ben: [00:34:00] So I really like working with the designer. If a designer can give me like a Figma or sketch marks of an app, I feel like I’m most productive in that environment. I feel like as it, as far as developers go, I think I have a pretty good eye for design, but I wouldn’t call myself a designer. So I can like, if like w w the way I work, I feel like designers don’t need to tell me about things like You know, color choices and font, weights, choices, and things like that.

And proper spacing and consistency and all that stuff like that I recognize it and I do it as a matter of practice, whatever. But sometimes having somebody think about the flow and the bigger picture and the, you know, and being more creative with the design is something that I really value. So, so that’s my preferred approach is when I have some, some Figma mocks, they don’t have to be pixel perfect.

But you know, You know, rough or near, near final designs are really nice to have for things that I’m creating on my own like this, this tinnitus app, it’s got some nice colors and it’s got that nice animation, but when you’ve like squint, it’s like two screens and it’s, you know, it’s, it uses some basic controls.

So it’s got some some, some nice looking lipstick on it, but it’s ultimately just some stock controls and So I think, you know, it, it’s definitely something that, like, I know enough about design to be frustrated with what I can produce myself, if that makes sense. But yeah, I just try to iterate started this, this tinnitus therapy app.

I’m actually, you know, it’s, it’s basically an implementation of a white paper that I skimmed you know, skim down to the conclusion section anyway about like what frequencies, it’s basically a pattern that it plays based on your tinnitus frequency and so I came up with this, this idea of like, okay, it would be really cool for me to play this on my phone.

I’ve seen tools like this on the web as well, but I’m never, you know, I want to be able to like put an AirPods or whatever and just do this, like when it happens, not when I’m like in front of the computer. And so And so, anyway, that’s kind of where the idea came from and I just kind of started iterating and I wanted to also get some practice with SwiftUI.

So I decided just I’m going to do, I’m going to do this on a hundred percent SwiftUI. Which I think is fine if, for me, because I’m using it also as a learning tool. And I also like to teach this stuff. So I want to make sure that I have, you know, have some apps that I’ve created and stuff like that.

For somebody else who’s like just wants to ship an app. I think the decision of like, There’s no, like badge of honor to be like, Oh, it’s a hundred percent SwiftUI. You know what I mean? It’s like, I think that people aren’t gonna be able to see the source code and as long as you ship it and you’re happy with it, like, it doesn’t really matter what it’s written then.

Jon: [00:36:39] Hm. Yeah. There are platform restrictions, right? Like Combine is only. There’s OS level requirements, or I guess that’s just developer level.

Ben: [00:36:48] IO. Yeah. Runtime requirements for Combine. I’m not quite sure why, but but yeah, so I was 13 for both SwiftUI and for for Combine, which typically we have a pretty healthy update cycle and the iOS community, you know, kind of the current version minus one is, is usually pretty standard.

The project I’m on now is unfortunately like two versions behind. Current. So maybe in the fall we can bump up. And in that case, then we’ll be able to start using SwiftUI and combine and stuff like that. But yeah, in the fall is when iOS 15 will be, will be announced.

Jon: [00:37:22] I, what I was wondering about earlier when I was asking about the kind of workflow is I guess, how painful is it to refactor and, and like on the code side of it, how, you know what I mean, how. How easy is it to just kind of quickly refactor your code as you’re going there? Like where you don’t have to think too much, because if you make a mistake, it’s not going to be too bad to rip it out and change it around in there.

Ben: [00:37:49] I would say that it’s in general, it’s, you know, Swift is a statically typed language. So you have the ability to do refactoring and get compile errors if you’re wrong and stuff like that. codes, refactoring tools are. Pretty hilariously bad. Every year I think, Oh, maybe, maybe I can actually rename a class and have it properly rename the file as well and rename all the usage usages.

And it usually works. Sometimes it doesn’t It’s just, I don’t know. Like, I, I, I was a big fan of ReSharper when I was using visual studio and none of that stuff. I mean, it’s just like, and that was over a decade ago. And so ex-co just doesn’t have that same, like, it’s just not as important to them.

Unfortunately, there is a jet, a jet brains IDE for Swift called app code. And it’s great, but it’s kind of like, They’re always chasing a moving target because it’s not first party. It’s not a plugin. It’s a separate ID entirely. So for instance, when SwiftUI came out, they had to like scramble to get their stuff, like to have some support for SwiftUI, because otherwise you’re just editing Swift in app code and looking at it in Xcode, which, and if you’re going to have to run both, I don’t know.

So I’ve just never really made that, made that switch. I do know people who, who use it full-time because of the refactoring support. But that said, I think that, you know, as long as the compiler can, can catch all these errors I’m pretty confident, like ripping things out and moving them around and stuff like that is, especially in SwiftUI, it’s actually a lot easier and SwiftUI UI.

Jon: [00:39:26] one other related thing is like testing. Do you, do, are you able to do like, you know, unit or integration level testing or like, can you test UI component stuff?

Ben: [00:39:37] I actually entered the world of trying to test SwiftUI views yet. Just, I basically treat that as like, I can see it working and I can create previous for all the different States. So if there’s like a, a state that is. That I’m unlikely to ever see happen in the wild, like the missile launched screen or whatever, you know, I can simulate it in the preview and see it.

So for that stuff, I don’t really necessarily see the value in it. But for t