Herding Code 244: Ben Scheirman on SwiftUI and Combine

Herding Code

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

https://herdingcode.com/wp-content/uploads/HerdingCode-244-Ben-Scheirman-on-SwiftUI-and-Combine.mp3

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 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 testing the models and, you know, network service related things yeah, there’s support and Xcode for, for writing and running tests, the testing kind of. The community isn’t quite as behind it as I would like. Most people really don’t write tests.

And when you do find the project as tests, they’re, they’re pretty poultry. So it’s something that I think that definitely could be improved. And I think that tooling certainly helps ease that barrier. But it also requires some discipline and how you design. Your software, right? Because if you’ve, you know, if you start tying things together with like singletons everywhere, then it becomes pretty difficult to isolate things out to test if not impossible.

And, and Apple has a long way to go with that as well. You know, I. Worked on a, a, an app that was integrated with the photos app on the Mac for a couple of years. And writing tests for that environment was really difficult. And we basically had to mirror all of Apple’s types with our own wrappers.

You know, it was probably, you know, six or 10 different like core types that we had to wrap and use our own wrappers so that we could stop them out during testing, because it was like this. Central part of the app that we couldn’t touch in a test because it dealt with a photo library and you don’t have access to that in the test.

And nor would you really want to,

Jon: [00:41:23] Yeah.

Ben: [00:41:24] but but yeah, I would say like, you know, I wish that the tools were more accessible and I wish the community was probably more you know, aligned to testing, but there is support for it. And I do some, myself, probably not enough.

Kevin: [00:41:40] so with the, you know, with a new way of building applications there There may be like things that the, the community has to figure out about, like what’s the right way to structure a large scales with DUI application. Right. Like I, you know, I learned some stuff by going through the, the Apple, you know, like intro course, but like, you could see where like, That’s a very rudimentary way of structuring an application.

And if you want to build something big, that’s got lots and lots of screens. Like what’s a, what’s an effective way to, to organize that and separate your models. It has the, has the community sort of figured that stuff out yet, or is Apple giving guidance around that?

Ben: [00:42:16] I would say Apple’s guidance has been really fantastic on the entry level stuff. Their tutorials are really interactive and rich. And you, you see, during the tutorial, you see the code you’re supposed to ride and you see what that’s doing live on the right hand side. And so as you scroll through, it’s kind of dynamically building up the application.

It’s a really, really nice, neat tech for interactive learning on the web. But that said, they kind of stopped there and like, you know, where do, where do you go from there? I think in general, like, Standard architecture still applies up to the point where you get to those models and the view layer that needs to be recreated.

So like who owns the objects that make the network calls for instance There are, there’s some conventions that we can follow. Apple has these property wrappers, which I guess would be kind of akin to attributes for properties in.net, where you can decorate properties with like functionality. And so there’s.

Because like your view is just a struct, right. And it’s meant to be thrown away and recreated anything you put inside that struct will also be thrown away and recreated. So they have some property rappers, which basically say like Swift, you guys going to take ownership of this thing and keep it around so that so that you can still feel free to rerender the views at any time.

And so that’s kind of the limit on what Apple is providing. But from there, I think that. You know, once you have your, your model logics, those are classes and they live for as long as you need them to live. And then, you know, there’s no MVC to like guide you down a path, but you can, you can kind of create any architecture that you want.

I guess there is one architecture. That’s kind of actually, I take that back. There’s, there’s two in the iOS community that, that People know of one of them is called the Viper and maybe to avoid upsetting anyone and I’ll reserve like my, my judgment, but it does tend to remind me of that kind of like the, you know, the Java naming ecosystem kind of like, there’s a, there’s a presenter factory implementation type.

That’s kind of what it reminds me of. And so it’s just not my style. I’ve never personally worked in that environment, but I don’t think I would enjoy it. And there’s another one that’s more geared towards Swift and SwiftUI. It’s called the, the composable architecture. And there’s, there’s a couple of guys who run a screw, like a screencast video training site called point free.co.

And They talk high, low. They, they go deep on the functional aspect of Swift and SwiftUI. And Combine for that matter their, their stuff is very advanced and they came up with something called the composable architecture and it takes lessons from Redux. And there it’s, it’s not for the faint of heart because you look at it and you’d be like, Oh my God, what’s going on.

But if you do know what’s going on, you can express. Things in a really concise way and it’s guaranteed by the compiler to work the way it should. But I would say with, with environments like that, as you know, I’ve done a fair amount of react as well. When you get something wrong, it’s very difficult to trace down what’s happening.

So I don’t have experience shipping apps with this architecture, but it does interest me you know, just as a. At least as an exercise for learning, if not, if not more. But there are some efforts out there to like come up with architectures that people can use for their apps. For, for the most part, I just create objects with four classes with those responsibilities when I need them.

And I don’t try to like fit into a cookie cutter pattern, if that makes sense.

Kevin: [00:45:49] So w when you’re defining an object model for use in a SwiftUI app, like how much does SwiftUI sort of dictate the shape of your object model or sort of perturb the design? Like, are you designing like a pure domain model and then. You know, plugging it into, you know, SwiftUI or are you building more of a, like MVVM ish kind of thing, which is like an object model that, you know, is designed to kind of interact with the UI.

Do you know what I mean?

Ben: [00:46:20] Yeah. Yeah. MVVM is probably the closest corollary to what I ended up writing. You know, the, the models that I keep referring to are. Subclasses of observable object and Swift. And that means that anytime I Mark an property in those models as published it will fire fire and event, basically that stuff has changing and SwiftUI will coalesce all those changes into a, like in the same run loop, for instance.

So if you change like three, three published properties, like it just kind of says, okay, And then on the next run loop, it will, it will cause any dependent views to rerender. And so, so it doesn’t do any like tree diffing or anything like that. So that influences like the shape of my view models. But outside of that, no, it, I can write whatever I want.

On my, on the puzzle app, I was talking about it. It deals with speech recognizers so that I can like tap the microphone icon. And I can say the answer to the puzzle and it will convert that to text. And I put the text on the screen and then we check the answer to see if it’s correct. And if so we flip the card over.

And my naive implementation of that was each of my puzzle screens, which had a card on it, had a puzzle view model, and that puzzle view model had a speech recognizer on it. And so when I loaded up a pack of 50 cards, suddenly I had 50. Of the speech recognizers, which come from Apple being initialized at the same time, because I like, and so, and it was something that was kind of surprising to me because I was sort of used to that, like the lazy loading nature of, of traditional UI kit, like where things get created when they are, when they are called.

Whereas this is all state-based and I was inadvertently creating it all upfront. So I had to kind of design myself around that. But but I would say in general, like aside from the, the view model shape of things and using that published attributes or published property wrapper I still have the freedom to kind of create the code.

I want them right.

Kevin: [00:48:16] Have you, have you gotten to the point in application yet where like the, you know, the, the fact that you’re creating and destroying the views constantly, you know, over and over again. Like, is there a point where that starts to bog down the application? Is there like a point of complexity where that becomes an issue or is it that they really got that kind of tuned?

Ben: [00:48:36] I honestly, I’m surprised how. Like, I don’t have to care about that. The only time I really have to care about it is if I’m mutating state in the view render itself, which would be a problem in any framework. Right. Because then it would just cause like an endless render and XCode will detect this and it’ll give you a well, it’s a runtime warning.

Like, Hey, you probably shouldn’t be doing this. I have a couple of cases where I’m like, Yeah, I know, but I’m only going to do it just this once. And then, you know what I mean? Like it renders once and that gives me the data I need. And then that’s enough for me to say, Oh, okay. Like I actually, the context of this is I’ve got like, I’ve got a card that I want to flip over.

Right. And in reality, it’s a view that I’m doing a tr a 3d transform on. Right. And so I’ve got a front and I’ve got a back. And, and so what I do is. When the front card rotates to like where you can only see the card edge, I swapped them where the other one is there. And then if then, and so I actually have to render the back backwards so that when I flip it it’s looks right.

And so. SwiftUI has this thing called animatable modifiers, where you can basically take control of the animation and they give you a floating point value of zero to one to tell you like, okay, here’s the progress of the, of the animation. And it’s up to you to return, to transform to like squish it or scale it or whatever.

And what’s cool about that is like you’re agnostic to the animation curve. The timing of the animation, it could be easy and he’s out or whatever, or it could be a spring based animation. So that number may not linearly progress from zero to one, but you don’t really care. And so in that, in that animatable modifier, I check to see if that angle is 90 degrees and if it is 90 degrees, then I set some state that tells my UI to flip the display of those cards.

And so I get a warning right there because I’m. There are literally animating I’m in the middle of an animation. I changed state during the animation, but because I only do it once, I don’t know. I think it’s fine. Maybe there’s a better way to do that, but but this is the type of thing that like It it’s surprising to me like how little I have to worry about them throwing away pieces of the view tree and recreating, recreating them.

It’s, it’s definitely different than the like from what I understand to be like the react model where you, where does like DOM diffing and stuff like that. And there was a lot of A lot of tech that makes that fast. But Apple has chosen a different approach and it’s, it’s all purely based on States.

And I don’t know. They’ve, they’ve been able to, to make it pretty fast. So.

Jon: [00:51:08] So you talked about like the cases where you want to directly control the animation or stuff. Is there a kind of a good. System for just kind of transitions, you know, kind of like trans yeah. Transitions.

Ben: [00:51:21] Yeah. So there’s implicit animations and explicit animations. So I can say here’s a rectangle on the screen. It’s got a color and the color comes from my model might be model. And I can just say dot animated. And then when I changed the change, any attribute of the view tree that came before that modifier.

So the, the frame of the color, the alignment or whatever, the, the borders any of that stuff, it turns out if any of it, that is animatable, it’ll animate whenever any of that stuff changes, which is great. If you just want a free animation. But it sucks if you want to animate the frame, but not the color.

So if you want to do that, you have to either get clever with the position of where you add the animated modifier because order matters. If you add it before the color, but after the frame, then the frame we’ll modify it, be animated, but the color won’t. And so the other, the other approach is to do an explicit animation and those explicit animations, you can be more precise about what you want to animate and, and how but the, the simple stuff about just moving stuff around is really, really easy.

Jon: [00:52:26] okay. How, how much do you have to care about lifetime? I’m thinking of things like most app models have a way of like putting your app to sleep or something for a low power mode or that sort of thing. Do you just basically like set, set your properties in your mind and like it takes care of it for you behind the scenes or

Ben: [00:52:46] So from the beginning, actually iOS has been really really aggressive about Killing apps that, that are are like the tie up the CPU, for instance or take too long to boot or whatever. When you go into the background, you’d be surprised how many of your apps are actually being suspended and evicted from, from the running state.

And until you come back in and, you know, there’s, there’s probably some stuff where it’s taking the memory and putting it to the, to the flash storage on the device. And then when you come back at re it’ll restore it, and your app is still running in the same place it was before. For the most part, you don’t really have to think about that stuff.

If you do need to do like background stuff like if you’re playing audio, for instance, especially if you are like transforming audio samples or whatever, then you need to be running like all the time. And so there are special background modes you have to elect into and Apple has to approve those.

So they’ll, you know, if you’re an audio processing app, they’ll say yes. And if you’re, you know, if you’re I don’t know, a game that has nothing to do with audio, then. They would be suspicious. Right.

Kevin: [00:53:50] So one of the, you know, one of the compelling things about swept UI is that it’s designed to be truly cross-platform. You know, you could run it on, you can write apps. So the work on the Mac, on the phone, on the watch, Apple

Ben: [00:54:01] You said that we’re truly cross-platform

Kevin: [00:54:07] In the marketing sense of truly is that something you’ve experienced? Is that, is that something you’ve been able to take advantage of? Do you, or have you mostly worked in the iOS

Ben: [00:54:15] I’m a little afraid of, to be honest. Cause I have some friends that are embracing the SwiftUI for the Mac. And some things are easy that I would say that Mac is much farther behind iOS in terms of like viability for launching like a true first-class product. But, but that said, you know, w a app kit isn’t going away.

So if you need like, kind of a robust, like a tried and true method of developing mock-ups, you can still do that. I would probably try to suffer through SwiftUI and trying to make it work. And if things didn’t work exactly how I wanted, I would be stuck with filing bugs or just dealing with it. And so I guess it just depends on what your priorities are.

It is pretty amazing that this puzzle app that I’m writing right now. Well, it already works on the iPad, which wasn’t very surprising, but with minimal effort I can get it to work on the Mac. So that’s pretty nice. And I haven’t been given Mac a single thought actually, until you said that, but. Yeah, it’d probably work and I’d probably have to like fix things here or there, but I guess the question is, does it need to be on the Mac and is there, is there a market for it on the Mac and maybe there is.

Jon: [00:55:24] What’s the way that you, how do you write responsive views or do you write a different view for each platform or do you, can you write things at scale to the screen size?

Ben: [00:55:38] Yeah, more, more likely you’d write things that are just adaptable in general. Like You can say like, Oh, this, this particular modifier only applies to iPad or only applies to this platform or whatever, or only applies when in dark mode or whatever. So, so you can make things reactive to the environment in many different ways.

In general, it’s like you’re gonna have some branching logic somewhere, and it’s probably better that that’s not like. In the first line of code. If I’m on the Mac, I’m going to run this app, whole view, tree, and experience. And if I’m on iOS, I’m going to do this. You know, hopefully there’s a little bit more reuse you could, you could have between your views because you know, the, the views that you get, the, you create like buttons and lists and images and stuff like that.

Those are trying to create a conceptual model for you to write. And then on the platform, it renders what is appropriate for that platform. So. Yeah, for Apple TV, you would get a list that responds to the TV remote and has focus rings, which doesn’t really exist on iOS or the Mac and, and things like that.

So like I, the idea is that you write at one time and it does the right thing on every platform. But like I said before, I’m really picky. So if it didn’t work exactly how I wanted, I would be probably pretty frustrated. And I might go back to saying, I have a TV experience and I have a Mac experience and I have an iOS experience and maybe they’re not all the same thing.

Rob: [00:56:57] Yeah, it’s reminding me of I learned tailwind CSS in the last year. I hate CSS, but like, you look at, you look at tailwind CSS on the page and it’s just like, what? But then you take some time to learn it and it, it changed everything for me. Yeah. Yeah. It’s it’s interesting. Yeah, it’s really interesting stuff.

Kevin: [00:57:19] So I was just going to say that, you know, I have my, my little toy SwiftUI app that I built. It didn’t take too long. Mostly I’m running it on the Mac. So I did it from the Mac and it didn’t take too long before I hit something. It was like, Oh, I want to do this. And then you read the documentation and it says only support on IUs iOS or, you know so it’s definitely some, some stumbling blocks.

There were some, some stuff in the platform only works on one operating system or the other. Yeah.

Rob: [00:57:49] So I have one last question for Ben. You learned guitar when, what it was, it was like, I mean, when I say relatively recently, like within the span of time, I’ve known you write like,

Ben: [00:58:01] No, no, no.

Rob: [00:58:02] Oh really?

Ben: [00:58:03] Yeah, I mean, I, I got my first guitar when I was seven and I, and I learned he’s got the whole world in his hands and that was about it. And then I put it down forever and then I got a guitar. I got an electric guitar when I was 13. And so, you know, it was my goal in life to learn how to play Nirvana and Metallica and rage against the machine and all that stuff.

So yeah, so I, I played electric guitar for a while. And then I didn’t really like my amp or my pedals and I couldn’t sound like the people that I liked. So I just played acoustic guitar for like 15 years or something. And I just never really progressed. And then one day I was like, Oh, I actually have a job and I can afford to like buy toys.

I’m going to buy an electric guitar. And yeah. So now I’ve got multiple electric guitars and amps and a pet pedalboard and it’s, it’s a, it’s a fun hobby.

Rob: [00:59:00] Well, I was remembering the very first I think you said it was the very first app you made was guitar tab,

Ben: [00:59:05] Yeah. Yeah, it was. That’s what made me leave dotnet and change my whole career up is I was like, I could tolerate objective C if it meant that I can work on a Mac and you know, make money in the app store or whatever.

Rob: [00:59:20] Yeah. Well, I was just thinking about that. Cause you and I were talking before we started recording about a Pink Floyd and in your, your Pink Floyd you recorded two two songs that you’ve done, which I actually watched. Well, We were getting ready here and they’re really good. Like they’re really good.

And I was like, Jesus, if he’s only been playing for like the last seven or eight years, I’m jealous, but I guess why didn’t know you when you were 13? Did I? No, I don’t think I do so. Yeah. It’s very impressive stuff. I don’t know. Maybe Jon can, Jon can let that play us out. When we went, when we ended up today.

Jon: [00:59:51] Oh, sure. Yeah. If I can get the artists release signed.

Ben: [00:59:57] Well, thanks. That’s very kind of you to say. It’s it’s I think it’s important to have hobbies that are not software development, because if, I mean, if that starts to stress you out, then your hobby stresses you out. And that sucks for, you know, for That’s just not a good state to be in. And so I’ve taken up guitar and baking and cooking, and I think it’s good to, to have other hobbies as well as programming.

Kevin: [01:00:24] All right. So I think we’re at a time. So thanks a lot, Ben, for coming on and educating us. Tell us the websites of your training projects so people know.

Ben: [01:00:34] You can find the Combine Swift course at CombineSwift.com. I, my regular screencasts on iOS development are at NSScreencast.com. One day, I’m going to have to change the name of that because the NS is probably not long for this world. Yeah. And I guess you could find me on Twitter at @subdigital. And it’s been a pleasure.

Thanks a lot for inviting me on.