Speaker 1: 00:06 [inaudible] Speaker 2: 00:06 frank. It's official. My machine, my computer, my main development machine is falling apart. Speaker 3: 00:14 Oh No. It's this theme like one that you're always so proud of because it was very expensive. I think we did a whole episode on, um, putting together our own machines. Is it that kind of machine Speaker 2: 00:25 or is it a laptop? No, this is the home built machine. Now. It is not necessarily expensive when you compare it to a Mac pro. Speaker 3: 00:33 Oh, right. The bar has been set. You know, the, the best thing about the Mac pro coming out is it's made me feel good. Speaker 2: 00:39 Really good about my imac pro. I'm like, wow, I saved a lot of money. You did it. You did. Except for the problem with the Imac pros, you can't really upgrade it. Right. You can put an external, no GPU, Speaker 3: 00:52 I guess. Yeah, but the external GPU, I got a slower than the one built into it. The saddest thing that I realized was a, I should have got the faster GPU be, I should've got a bigger hard drive. You know, you always think, I don't need [inaudible] Speaker 2: 01:06 that much hard drive. You need all the hard drive every bit that you can get. Well if you remember, if you go back to merge conflict episode 82 when you bought the, I don't know if that's the version on the number of it, but I'm going to say it is. So if you go back to that episode, you'll, you'll remember me telling you that you should have bought, you should've spent more money on more ram, more hard drive space and just all the money give apple all your money. That, that's the, that's the answer. No, all the goal, the goal is to give apple all your money. Now I will say this, frank, at least the stand was included. Speaker 3: 01:39 Yes. Um, and actually it wasn't tall enough. So I stack some books and put it on top of some books. It's perfect this way. Who needs a god? How expensive is it? 5,000 or 6,000 Speaker 2: 01:53 the no, the Sanders Sanders a thousand. I'm sorry. So the monitor would be like 7,000 with the stand. Yes. Correct. Yeah. Yeah. Pretty much. Well cause the stand, I assume you can't use it for any other monitor. But I do hope we'll have some good youtube videos of people buying and stands and just holding up amazing objects with it, creating their own stands wall. I may need to get a new Mac pro because I was doing some live streaming recently. Uh, and none, no one saw it cause it was all film. But I hopped on to Skype, start up a Skype call and all of a sudden everything went out. All of my Webcam's right now I have two webcams cause we're actually live streaming this. But I have two webcams, one for you, one for twitch and everything went out. Am I computer blue screened 100% in some error message that I have never seen before in my entire life. Yeah. Speaker 3: 02:44 I thought they um, got rid of or did they clean up or did they improve the blue screen experience? How is the modern Duluth screen experience? James? Speaker 2: 02:53 The modern blue screen experience is exceptional. Okay. Because an annex, an exception occurred on your machine, you should have it. I'm not gonna pause you in the curl in the colonel. So when you get in, there's a very, like there's a frowny face, there's like something has gone wrong with your computer. There's a QR code that you can scan that has the error code to a help page that will help you. And then what it does is it sits back and it collects a bunch of stuff from your machine, which, who knows where that goes. I'm sure it gets reported somewhere to somebody at some time. Uh, and then your computer reboots. You don't have to wait until that's over necessarily, but you probably should. It seems like, you know, I'm dogfooding my own product here at, I worked for the companies to try to do that to you. But Speaker 3: 03:38 you're not running up Beta windows, I hope. Speaker 2: 03:40 No, no, no. Just normal windows. But here's what happened. Is My computer turn back on. Of course I didn't go to the help page. I don't actually know if it was helpful at all. I assume maybe possibility lower than average. Right? Because there's so many areas I could go wrong and I turned back on my computer and none of my webcams are working. Speaker 3: 03:59 Okay, so these are USB devices all just plugged into the back of this computer or you got some complicated setup. Speaker 2: 04:06 That's what you would think. A very close, and I'll make this a shorter story, but I have these beautiful monitors and I said, well, these monitors have USB ports in them, but you need to do that crazy USB to USB. So I had two webcams plugged into a single monitor and they weren't turning on. I was like, did I break the monitor or something? I don't know. So I plugged in, I plugged in a phone and that didn't charge. I go, oh no. Like I was just, maybe it was something else. So then I took the Webcam off and I plugged it into the front of my computer and the Webcam worked and I was like, Speaker 3: 04:41 I'm so excited, James. This means you're going to buy that $6,000 monitors. That's what this means. This is going to be Speaker 2: 04:47 punchline. I'm away ahead of you. Well, so it gets better because then I said, well, did I break the Monitor? Like what happened? So I take the USB cord that's in the back of my computer and I move it to the unknown working USB port on the front of my computer that I tested the Webcam on and everything starts working again. I blew the USB port that is in the back of the computer that's on the mobile, but only a segment of it like it's gone. Great. Wonderful. James. Brock's amazing. Yeah, I dunno. I Dunno how I did it. So it's now I am running webcams off of multiple USB ports, not all in the Monitor. So I'm assuming that something like obviously terrible happened and then boom, game over and it just didn't know how to handle all of a sudden missing USB ports from the motherboard. Speaker 3: 05:42 USB is simultaneously the best thing in the world and the absolute worst thing. So attached to this computer, I have four USBA port, four USBC ports, something like that. Each one of those has a expansion USB device attached to it. And those are all running off to a thousand different devices and everything under the sun. And when something doesn't work, it's the worst. I literally had it today too. Um, I blew out my own, the USB hubs. So look, we're both in good company with each other here. Speaker 2: 06:17 A USB USB. All right, well that's my story, frank. But I was listening to a little story from one of our best friends of the podcast. Really true friend of the show, Mr. Craig Federighi. I don't know if you've heard of Craig Federighi at all. Speaker 3: 06:32 Well, I know he just sends me emails all the time. So it's just, I try to ignore him a little bit cause I mean it just gets to be a little bit much after awhile. Speaker 2: 06:41 Yeah, he's a fan of your hats, so I get it. You know, I'm trying to get that [inaudible] that's right. So I was listening to Mr. Craig Federighi on the talk show. I don't know if you know about Mr John Gruber. He has a little podcast, tiny just is this underground podcast called the talk show. Speaker 3: 06:57 You know, I feel a little bad because I missed that episode that you're referring to, but I was listening to the episode this week with Jason Snell where they were reviewing the episode that you are listening to. Let's get Meta here. James. Speaker 2: 07:10 Yeah, I haven't listened to that one yet, but it is a very long like two and a half hour live show recordings. There's a different feel to it, but there is a lot, they cover all things from apple and we've been, you know, been going through, we did our, our dub dub DC recap, we did iPad o s last week, which was a lot of fun. They talked a lot about that and then they started to go a lot deeper into swift UI and I've also been noticing a lot of people experimenting with swifty UI. I know you've experimented with swift UI. It's not c sharp, it's not.net at all, but it is mobile. And you know, we like to talk about mobile stuff and we can always cut, contemplate if it should be c sharp a fight or not. And there's a open github issue so maybe someone's doing something no inside baseball. But I wanted to start with swift UI this week from a perspective that you and I are not swift slash swift UI masters. Is that correct? Absolutely. Speaker 3: 08:03 Wait, um, there was a point in my life where I loved the language SPEC. It's the same thing that what actually got me first into c sharp was, it was the first well-written language Spec I'd ever written. I think apple did a really good job with theirs too. And so I got kind of interested in it, but I only know the language from that kind of like I read a book on it, academic perspective. Technically I've written a couple of libraries in it, but constantly googling and stack overflowing the entire time that I do. So I can technically write some swift code, but I am not at all. So it went in any imaginable way. I can, I can read it. I read Speaker 2: 08:39 the swift code. Uh, I've been reading, I've been googling quite a bit. Some getting more. I've been getting really into some Ios APIs recently in some of the libraries I've been creating. So I'm doing, doing a lot of stack overflowing and I am seeing a lot more of here's the objective c, here's this, the stable swift abi stuff. And Ah, it looks, it's, it's not, it's not my Super Cup of tea, but it's a lot better than the objective. See from what I, I've seen and some of the niceties there. So I actually like the swift itself. Um, some of the nice things that it does. Right. And we've talked about the different languages. I like some of the stuff f sharp does. I like the stuff c sharp does a lot. I like some of the stuff that Caitlyn does. I like there. I like you can always like a little bit, but I don't know if matching all of those together into a single language would be a good idea. Speaker 2: 09:29 But I do like a little bit of this, a little bit of that. But you know this, it's crazy because with swift itself, they've always just sort of, that's still new language or coding it with, but you're still coding into UI kit or app kit or watch Kit Watch kit watch get you on. Yeah. Watch, oh, I don't know what Wk wk watch cat watch kit. Yeah. Tbos as UI kit. Yeah, correct. You got it app for Mac. Did you say that one app kit. app Kit. Yeah. So with this you're just coding. It's those API APIs but swift UI different. Speaker 3: 10:09 Yeah. Um, I really appreciate what, um, I forgot who is presenting, nevermind, I'm not going to give a name, but one of the presenters at the keynote said something like, we, okay, we have this new language but we're using these old libraries, libraries designed basically for objective c and as we all know, coming from a.net c sharp background, the languages influenced the library design, the API APIs, how things are expressed this way and that, and they said maybe it's time that we have a new UI library tailored to the language, take advantage of all the features of the language, which is pretty neat because, um, swift has some awesome features to it. I think it's kind of a little bit of an ugly language, but it's, it's cool cause it's up there with um, rust and go of being, um, very efficiently compiled. Still not, um, I'm sorry, go is a garbage collected language but rust isn't so swift and rust are playing kind of in this interesting playground of being native compilation like that. Anyway. Yes they did. Uh, they did a whole UI thing and I think it's really interesting, um, because like I said, it's like, let's see how we can take advantage of the language. And in fact they even changed the language a bit to make parts of this UI. I almost called it a UI kit, can't call it that. Make part of Swift UI works. I'm gonna, we're gonna have some fun here. Let's dive into it a bit. Speaker 2: 11:36 Yeah. And I was talking to some apple developers recently and that had been experimenting with, with Swift UI and uh, they were like, oh, it's really, it's really intriguing. And they didn't really know too much about Xamarin and okay. I said, well, what's, you know, they're like, I was explained to them. What's unique about Xamarin is that you have UI kit, you have app kit, you have storyboards. And I go, the funny part is that when you think of cross platform libraries, like what Xamarin forms data, at least for Ios, android, windows, it says we had just abstracted, but it's still the same thing under the hood and what swift UI does. And everyone first came out and thought it was like a sh just a shim wrapper over UI kit. But it's really not necessarily that from what I'm getting is that there is a button or there is a stack or there is a label or whatever the different names of the controls are at that control comp. Speaker 2: 12:33 It's a whole composition frame. It's a composition animation. It's a framework. Right. Um, the difference is, is that from what I can tell and what I've read and heard is that yes, you run that maybe on an iPhone and you may get a UI table view, but you may run that on a TV ios device and you may not get a UI table view. You might get a new implementation under the hood that makes sense for a t vos device. So it may be something new that's not in UI kit. So it's like you're either going to get the thing underneath that could be a UI kit or an app kit version. You don't know. Right. You don't really care, but you might get something new that's part of swift's UI. Woo. Speaker 3: 13:20 Lots said there. So I think the comparison to Xamarin forms is the best way to look at it because as he said, yeah it's doing these tricks. So sometimes labels a label, sometimes it's not and you're really not supposed to care or know because it's a high level UI line language and what's called a language API. But the, it's written well enough. It almost seems like a language in parts. So I think it's fun how we can break it down in so many ways. We can look at it. What platforms does it run on, what controls does that have? How does it do data binding? How do you specify user interfaces? How do you customize those user interfaces? So there's so much to cover when it comes to like a new UI framework because it is interesting and new. So I want to start, I find it interesting the cross platformness but to me that that's, that's just hard work. Um, we know how to do cross platform. You just write interfaces and then deal with the implementation. It's a pain but it can be done. I think the more interesting things are the animation support. The data binding and the editor that they came up with for it. Speaker 2: 14:37 Yeah, I I agree with that too. I mean to me it is nice that it runs on a lot of different platforms and you know, they're, their motto though is better apps and less code and I'm not, I mean I'm 100% sure that that's what will actually happen. I mean I will, I mean maybe less code than UI Kibbeh maybe not. I, I, I want to believe but when I look at a very simple like here's a list, right? There's, there's instead of UI table view as a list and you have this model thing which, which we can talk about more this different pattern, but you know, you have an image and you give it an image and there's some taxed. But like that's just going to give you the default stuff. Like I don't, I want to see the full examples of here is a like, let me see the podcast app code. Speaker 2: 15:27 You know what I mean? If that is with DUI, which I don't know, I know it is project catalyst, but if that is a swift UI app, I want to see it, you know? And, and like same thing was Amerind forms. Like I can go in and I can write a list of data that's a few lines of code. We've done that, that's what you do on a marketing site. But when you go look at real apps and you're like, here's all of the styles and all of the, you know, things that cascade on top of it and you get into the code, it is larger. And that's always been my fear of, uh, I mean I fear in a way a fear of a declarative UI, which I know that you're a little bit more of a fan of than me, is how does that scale and how does that refactor in production, not, you know, and, and maybe you can, you can talk a little bit more about supplementing my fears of moving away from any XML base. Right? Cause Android XML is based, you know, um, storyboards are more wind forms Z in a way. But you know, um, that's kind of my, that's my longterm. How does it scale? Speaker 3: 16:25 Well, I think what you're saying is I don't, I don't know why people love those designer things. Sam All and story boards, any of that stuff, it all should just be in code. And so I'm actually a big fan of this approach. It's how I honestly write my own Uis, my own apps. And so I think the fact that they went with a code first approach is kind of like, um, it's a, it's a boon for me. It's like good job frank code first. That is the right way to go. But you're right, it's not for everyone. Obviously there are people that absolutely love separating out what the design, the declarative part of what the UI looks like versus the data back end of it. For me, I'm just trying to write apps and I don't mind mixing those layers very much, but they're definitely mixing them. Speaker 3: 17:15 Uh, we are definitely doing, you know, database access on button handlers here a little bit. You can create abstractions on top of it of course. But at the low level, like you said, they keep showing these trivial examples. So it's like, okay, good, nice trivial example. But how do services work? How does the event mechanism work for those? All that stuff? I'm not sure it's going to be less code either. Um, we should talk about the data binding and the animation. I think that's actually where it will save code. But as far as setting on a text box, no, you gotta say you gotta say, you know, color and a color, you know, you just have to somewhere. Speaker 2: 17:59 Yeah, it's, I could do a squiggly background color equals this color or I could do, you know, dot color equals this color. I mean, to me it doesn't seem like that much different of code. I don't understand in general. I mean, so let's talk about then the, what you're saying is some of them may be the advantages of this declarative UI, which is perhaps the animation system and the data binding mechanism that seems to be, if it's not less code and maybe you prefer a, all of your code is in one file versus multiple files. That can be a fight and battle. But you know, one thing I do struggle I'll say with, with all XML, whether it's android or XAML that I've done in silver light or dub pf or UWP or Xamarin forms is is animations data binding. Sometimes like simple data binding, sometimes complex. You got to figure out weird syntax, this parent property and this binding and this thing, you know, I just want to shove it together, but so how does it, how does it actually simplify that in a way or make it better or make it worse? Speaker 3: 19:04 So the, the two mechanisms are combined the binding system and the animation system. I think that's what kind of makes a comfortable from that first standpoint is that there's a lot of implicit stuff that can happen. Or at least if not implicit, then it's setting up property to true are saying, you know, do this thing and then the rest is done for you. I think that's always been my complaint with the um, XAML UI frameworks, forms included is animations were, are explicit for the most part. You have to create them yourself. You have to think through do this and that. Whereas even in UI Kit, there are a lot of implicit animations or at least easy to do implicit animations just by wrapping something in a, in a block or something like that. I love how easy they make it, but they tried to make it even easier with this, a swift DUI thing, so when you're doing your data binding updates, you can say, oh, I'm going to set this right now, but at the same time, animate it while I set it. And so you get this going on and that going on. Then perhaps you'll say this animation might take two seconds, but then what happens if the data changes in between those two seconds? Have you ever done that? And one of your apps, James, you add two animations to the same control Speaker 2: 20:24 [inaudible]. Yup. Yeah, yeah, yeah. And then sometimes you might want, you might want it to bounce a little bit and you might want it to fate a little bit and you want to, you know, you want it to, to, to, to catch. Speaker 3: 20:33 Yeah. And the problem is you try to put all those things together in the code, but then it's not always easy to put them together in the code. Sometimes that happens on this event handler or sometimes on that event handler. So just the orchestrating all that stuff is complicated now nicely just from their architecture, which we'll get to eventually. This kind of falls out of it because they can see this animation should be active. This one just got canceled by that one. And so with just a few, uh, they, they do that, um, that chaining kind of thing where you say, you know, um, oh, create this object, set the color to blue dot. Set the tech font to this dot. Set the width to this dot. It's kind of like that kind of chaining of doing things. Speaker 2: 21:18 Yeah, there's a good one in here which I see you. So there's an image for instance, which uh, they have, they have a few animations built up. So I mean it's Kinda Pretty, pretty interesting. So you have an image and the idea is that you may want to rotate it 90 degrees and then you may also want it to scale from either like one to 1.5 or something. So you can say, you know, here's my image dot rotation effect. And then in this instance that you give it a degrees and then there's like logic inside of it, which is show detail due 90 l zero and then the same thing for scale effect. If show detail is true, do 1.5 else do one. And that obviously has to do with the MBU model, the state model of it, because there's a simple boolean. So whenever you change that bullying it reevaluates in which that animation that applies. So you're not having to say when the boolean changes go do this. It's more like a, in a weird way, like a visual state manager, which is like very proposed. I'm not a huge visual state manager, but in that instance you can say when this happens, go do this thing. But here it's kind of seems like it's cascading off of the, the creation of the object or the the UI. Speaker 3: 22:35 Yeah, and I think that that's the most, and I'll, I'll use this word specifically, powerful feature of this library is that it's saving you code. So when we were saying less code before, is it, we're debating whether it was less code before we were talking about setting up the UI, but when it comes to these more complicated interactions, you said it yourself, visual state manager. It's a wonderful concept. I have an implicit concept of it in most of my uis cause we all have different modes and different states. The UI can be in, but it's just so verbose that I hate to use it and I don't remember how to use it. I don't remember the syntax. This is shorter syntax, therefore you can take advantage of it and use it more often. I think that's what excites me. I know I've mentioned in this podcast before, but it's probably been years. The thing I always feel most guilty about in my Ios apps is not having enough animation. And so cause it's they, they make it pretty darn easy to add animation to your apps now. And then with this it's trivially easy if you buy into their architecture. Speaker 2: 23:41 Yeah. And I'm always curious what could like the forms team do? Cause the thing, what's people don't know about forms, which like I always look at my own apps and I'm like why? How come my apps don't have more animations? And then I'll see like Kim do something or I'm like Brandon, we'll create an app and there's all these animations, you know, in it. And in forms that I'm like, why? You know, how come? Because they're just like, well you know, I just think about being okay with putting the different, kind of go to statements almost in a way. Like the apply this animation, apply this grouping of animations and when you tap on something, play this animation and it scales out. Or when this fades in, go left and right, but that has to happen in a different file, right? It's not in the file. Speaker 2: 24:26 So that's one thing that I am like, I'm curious what the, the teams could do. That's always been a challenge for me, even an android world and, and inside of Ios world because there's in a storyboard and then there's the code behind and then I gotta I gotta think about it afterwards. Uh, so that's, that's something I'm interested, but let's talk more about the architecture and how it goes. But let's first thank our amazing sponsor in brand new sponsor this week, uh, for the Pod, our good friends over@clubhouse.io. Now maybe you never heard of clubhouse.io, but hey, listen, are you looking for a better way to track your product and engineering backlog? We're building apps all the time. We have huge backlogs. Like, do you want a product management tool that's powerful and simple to use? Like literally who doesn't want the power and simplicity? Then really you should give clubhouse a try. Speaker 2: 25:18 Now I've been trying out clubhouse really super cool thing. It's really just software. I'm in product management designed for software engineers and software teams. Like you're an engineer, you want to manage your product and your backlog. This thing is built for you. And what's really nice though is that not only do you get kind of like your boards with like ready and development, dragging, dropping, you can set different project types. You can look at unfinished, your stories, your epics are Muslims, all the things you can get burned down towards and kind of go as much or as little as you could possibly want. But the nice thing is that they also have a full rest API. Everything's there. And of course, just like anything out on the Internet, there's tons of integrations to all the things that you could possibly want. Now as a special offer for a merge conflict, listeners, you can get a free two month trial, two months for free. Speaker 2: 26:11 Go to clubhouse.io/merge conflict. That's it. clubhouse.io Sacha slash merge conflict and give him a try. And thanks to clubhouse io for sponsoring this week's pod. Thank you clubhouse and thanks for introducing that one, James. I have to go check them out. You kept that one back from me. I didn't know about this secrets. That's what I do. That's what I do. Okay. So architecture, architecture, baby. We gotta do architecture. Can we finally do it? To do I have to put in show title? Do I need to put something about architecture and Swift UI? And then really whenever people see the word architecture in one of our podcast titles, it's like the most popular podcast ever. So Swift UI architecture for developers, Speaker 3: 26:58 Swift DUI architecture with taste. Speaker 2: 27:02 Huh? I love it. Okay, Speaker 3: 27:05 so this is, this is classic. Um, let's say roughly the swift architecture. Swift UI architecture is that functional reactive programming stuff that we've talked about before where you're given some data and your job is to write a function that translates that data into UI. So if I have a list of monkeys, I guess I create a, um, whatever. Um, what are those? What are they called? Oh, oh my God. I don't know. What's the Xamarin forms vertical stack called stack layout created. Speaker 2: 27:44 I knew it. I would want to let you, I wanted to let you figure that one out frank. Speaker 3: 27:49 Right. I could create a stack layout, I could create a bunch of some views, some children views for it, put some images in there and I can write a function that generates all that. The problem is if one of those monkeys were to ever change, it would be terribly inefficient and other problems, but to call that function again, recreate the UI redisplay the UI, it would, it would just be bad. So their whole thing is solving that problem of we like to be able to write that one function that generates the UI because it's so simple. It makes creating UI is very easy. You take full advantage of all the power of the programming language, but how do you actually get it to update in a object oriented world? Speaker 2: 28:34 Yeah, that's always been a struggle in, you know, in in the terms of most like apps that I build. I have some, you know, MVVM architecture and things are changing and Uis are changing and I can do data binding back and forth to say this thing, when this boolean changes then hide this thing or make it visible and then the UI just updates magically. For me that's like mostly what I want to do and I think of the view model as a uh, represent. It's not a representation of like the UI stack though. It's sort of, it's a representation of, I guess it's a representation of, I guess it's the model of the view. It's the view model that's in the name. Speaker 3: 29:18 Frank, you're overthinking the name. Can I, can I give you a higher level look at it? Yes. The way that we generally achieve data binding in forms and in.net is we create reactive observable objects that mutate state. We are object oriented programmers, so whether you have a view model better, you have a model, it kind of doesn't matter. You have an object out there that has, I notify property change on it. Basically it's expected that you'll always have that one object and its internal state will change its properties will change and it's lists and things like that. This model of um, the way react works, the way Amish works. Fabulous. The way swift UI works is that they, uh, don't have reactive objects like that. Instead they just take a value approach. Students say in general when the person object, not the person value changes, then we'll regenerate the whole UI whenever. Yeah, whenever values change. Not Objects, not with internal state, but just big hunking value up things. Try not to use the word object. It's hard. Speaker 2: 30:31 Well you have this then sort of class if you will, of of state for your app. And we talked about NBU a little bit in the past and a bunch of reactive stuff. But yeah, this sort of state and may Matt not be everything that the UI is displaying or doing or whatever. It's just like this is stateful things that mutate, that the UI needs to know when to update. Is that, is that accurate? Speaker 3: 30:55 Yeah. I just, well, yes, but I think that that applies to both the reactive object oriented world too. Um, because it's that the biggest thing here is, I probably should have used this word or where's immutable. These value objects don't change. They don't, their internal state doesn't change. So if you, um, if you have a large hierarchy, a list of people and the person has an address and an address has a street and the street is an object and you want to mutate that street and an object or around the world, you set the property on it. And then if you're, if you're, if that thing is in a UI somewhere, it'll bubble up event, bubble up in event, bubble up an event that that works pretty well. It's a tiny bit efficient. If you're setting a million properties on a million things because you're going to bubble up all these events, but whatever computers or fast, it doesn't really matter. Speaker 3: 31:48 This model's a bit different. Um, I would have that list of people each with an address with a street. If I want to change a street, then I have to change that address. I have to create a new address thing. I have to create a new person person thing. I have to create a new list of people thing I have to keep. I'm not bubbling up an event. I'm bubbling up a new data, new immutable data. It's a different tact. It's a million events versus one event. The problem is you have fine grained control with reactive objects, but with immutable objects it's not fine grained because they're big and have lots of data in them. Well I think the Speaker 2: 32:26 real different, there's two differences I'm seeing already as had that bubbling events that you're saying and how it knows how to update the UI. But you're saying that it, what I've noticed in the swift UI Eco that I've seen and, and the fabulous code that I've seen before too, and if people know fabulous, says it's sort of, it's AV sharp with Xamarin forms and a react. Um, MBU it's an NVU style, very similar to this of constructing UI as and, and reloading. But there's always this like one method to sort of build your UI in general. And that's, and that's the thing where you be like, hey, like don't, don't try to like, this is where you build it. Like this is where it goes is very prescriptive in a way. So you're not generating a bunch of UI and other places like, no, this is where it happens and this is where you inflate it. Speaker 3: 33:15 Yes. But it's still a programming language. So you have functions, James and you have different objects. So I worry that people are thinking you're gonna throw this all into one single file. No. The whole idea here is that programming languages have abstraction. They have very powerful tools for doing algorithmic work. And so we should be using that to build our Uis, not relying on a whole different language with its own semantics and its inability to do logic and things. Anyway, I'm fabulous is actually a good comparison to swift UI in a lot of ways. Fabulous. Is, um, a UI API for f sharp. It's tailored pretty well to f sharp to make the syntax work out very nicely. In that and it's also cross platform, the differences in the details. Exactly. How is um, that state distributed, when do things get updated? Obviously the programming language, all that, but let's say on the architecture side, I think the nicest innovation that swift UI did was they gave you a way to organize the state and decide what is a reference to some data and what is the data itself. And so there, there are binding system is explicit. You say when you're binding to an object and you get a binding object back and that's because they want to be very clear that this is not the data itself. This is just a mirror of it. Speaker 2: 34:50 Yeah. And one thing that, that I've noticed in the keynote or that was maybe as a developer deep dive, they were talking about these Bible states and the states themselves and the mute mutation of them and they go, and this is something that I took back to my own project a when I looked at my source code is they're like, oh you should, you'd be really surprised of how often or actually sorry, not how often, but how little your objects mutate. Like honestly they, you have, what if you looked at your entire app like of your model and like how much of it is ever Ma, you know, mutating after you create it. You know, maybe if you're editing a person, but if you just have a list of people that stuff is never chasing, maybe your app never changes that data. So why would you create sort of the [inaudible] parts and pieces of it and why even in my code do I have set properties that are doing comparisons of values and doing a bunch of extra stuff because it's been ingrained in my head. That's what I do. But, uh, you know, if I looked at it again, I go, oh, maybe I don't need to set up this complexity on every single object unless I'm actually going to change it. Speaker 3: 36:02 Yeah. Reactive objects are kind of viral. Once you have one property that is observable, you're like, well, I might change the other. I might change the other. The problem is you don't know which ones you're ever going to change in the future. And so you end up having all that extra crud. But I appreciate what you said about how changes over time are actually minimal. This is completely how we works. My, um, web UI Library, when it's communicating, uh, we app has always communicating with a server, whether it's off on a different computer or whether it's a web, um, what's it called? Web Assembly thing. [inaudible] all it's ever doing is communicating those differences. And that's why I can work so well because they're actually quite rare. Um, we rarely mutate our Uis once we've presented it in front of the person. And I think that's why we all just kind of, at least myself enjoy the idea of that's why I just want to write a function because obviously I'm just going to show at once and darn it, it's annoying when data changes and you're like, ah, how am I going to update this thing? Speaker 2: 37:10 Yeah. Well there seems like there's a lot of good, but I want to talk about sort of the other trade offs that we have here because you and I were talking before we did the pod and I said, you know, well now the swift Abi, the, the, the, this, the arc. What is the Abi application Speaker 3: 37:26 binary interface and it's the binary part that makes things native in scare quotes. We as.net programmers live in a glorious managed world. Managed usually means, um, the fact that we use a garbage collector, but it also means that we distribute our binaries not tied to a machine. We ship l code around to each other. And that means that we can have cross platform libraries pretty easily. But swift is totes a native compile all the way down language technically can go to LLVM intermediate language. We've talked about that before, but that's still a pretty low level thing. It's still kind of tied to a machine. And so we, you have this problem of swift test to be compiled into a binary on every platform and distributed on every platform. Speaker 2: 38:19 Yeah. And I then said, okay, well swift has a stable Abi. And then I said, um, well what about swifty? Why are they distributing this as a library? Like a cocoa pod if you will? And you said Nay, they are not distributing it that way. That's not how that works, Jane. Yeah, Speaker 3: 38:38 no. And instead a in classic apple style, it's a built in framework right down at the ols level. You need to install for yourself a west Catalina and ios 13 if you want to be using this library. Now I'm curious if that'll stay true forever. Like you feel like they should back port it to older Ios is, but Apple's not really a backporting kind of company. So maybe not. Speaker 2: 39:07 Well and you know, this happened to be sort of the, the downside of swift in the early years, which is it w we didn't, you had to ship it in your app app actually for a while because there was no stable area. Speaker 3: 39:21 Like we're doing that with.net core now I'm all for SCHIP the run time right in the app because then you're not dealing with system level stuff. Speaker 2: 39:29 That's how Xamarin works. You have the money, you have the don at runtime, you ship it with your app works and that and that, that version can use c sharp features with it. And yeah, so I guess, I guess that actually then wasn't that bad because you know your app, which may be against swift one could ship, it'd be totally fine. There's different performance issues there. Sure. But I think size, Speaker 3: 39:50 they made the right decision because they knew that they were going to be changing the language quickly. So tying it down at the Os level, we can talk about Microsoft history too. We'd dot net one and.net two like problems like tying run times at down to the ls level. It creates issues. And so apple was smart there, but not so much for this UI framework though. Speaker 2: 40:14 Yeah. And Emma, I'm imagining that there's things that are built into the operating system itself just at the level of UI kit in which, um, that this stuff is needed or, or even advocate for that matter if they're making any changes there. So it's built into it. So if you want to start this development, you're going to have to have those oss install those Betas. And then I'm imagining though, and like I couldn't imagine any other way of working is that if you build a swift UI amp, you can't ship it to Ios 12. It has to be an ios 13 only feature feature. Correct. Speaker 3: 40:52 Yeah. As far as I understand, I wish we were wrong, but when I was trying to do some swift UI development, I had to go find, um, I had to go install Catalina and it destroyed my computer for like a few weeks. So I, as far as I know, yes that's, that's the price to pay, which is good and bad. Um, the good, it means that they did have that cross team relationship. Like you said, if they had to change app kit, if they had to change UI care to make this thing run well rarely. No, they had to change the swift programming language a little bit to make this thing run well. So I imagine that when across to the other teams too. And that's good from app developers perspective, that means that they're trying to deliver a better library. It's also bad because as an app developer it limits the amount of people that I can distribute it to. Speaker 2: 41:46 Yeah. I mean I, I, I couldn't imagine a world where, you know, the like even and like react native flutter Xamarin, they come out and they say you can only, you can, you can only use this on ios 13, you know, like, oh here's, here's, here's all these new controls. You can only use this on ios 13. Like, I just don't think that that would be a thing because it swift UI comes out with new controls and ios 14 then you can only use those new controls on ios 14 cause again, you don't backport like android. Google got something, right. They back port all of their controls and to mega libraries for better or worse. Google did something right with android. I'm not going there. I it Speaker 3: 42:27 earlier when you were like, Oh, I was doing animation on android. I'm like, you can do animation on hinterland. Of course it's in a compat library. It's all in a compat library. All of the libraries, frank, I was, I was also thinking I get upset at the Xamarin team because uh, the Xamarin Mac minimum deployment target is 10.9 now for Mac Ios. And now I'm thinking, well at least it's not 10 dot 13 cause oh my God, at least, or at least going for back four years, five years, whatever. There you go back. Compat it's hard. No one wants to do it. So I guess I should stop being grumpy when people force me to move on with versions. Speaker 2: 43:07 Well. And so the, the longevity of of it is if you're going to create a new app now, I don't think you can use it. Um, right. What are you talking about? Swift UI. I mean it's, we have to, I like if you, okay. So I would use the always you would do it now and only target ios 13. Yeah. Speaker 3: 43:26 Ios has enough uptake that if your app is going to be at all successful, there is enough people yeah. Speaker 2: 43:33 Running ios 13 or will be that you'll be fine. So 100% new app. I would do it especially because I don't know if we've been clear. It's good. They did a great job with the library. I W I don't think we've praised it enough. Um, it is far better than programming UI kit. UI Kit is not the nicest thing on the planet. Well, it's going to have to come down to your business requirements and this is sort of the integral part, right? So we still have, I still have developers in my libraries asking for Ios nine support two. Right. So Speaker 3: 44:09 different debit, right. Are you going to a consumer market or are you trying to satisfy businesses that won't upgrade or users that won't upgrade? It really depends on your market. And that's the reason I have back compat to back to 10.9 because I have stats showing that people with older oss are using my apps. Speaker 2: 44:30 Yeah, I see devices that are not getting updates. Right. And is ios 13 iPhone five I don't think is getting ios 13 I think five s's. Speaker 3: 44:39 Uh, that would make sense because you want a 64 bit one at least. I'm surprised they're still doing the five s that's, that's good. And all that one too. Speaker 2: 44:48 Kids getting up there. So I mean there are the trade offs there. So I mean this is the same problem. I think that the swift's I've had for a while, it could, you took the trade off of the app size versus whatever and that a lot of people were like, oh, I'm going to stick with objective c for a while, then I'm gonna Start Mingling and then I'm going to go all in. Right. And it's the same thing we see with basically anything that's new and that everything is new and shiny and awesome, right? Like everyone's like, I'm going to do.net core. Then they're like, all right, now we're at.net core quarter and then three like, okay, now we're all in, right? Just it takes some time to move along. But it is fun to play with things while, while they're brand new and shiny, I guess. Speaker 3: 45:20 Yeah, absolutely. And you can't write, I'm sorry, you can write tons. You could probably write 80% of all apps in this thing right now, but the kind of apps I write, I can't write in it, so I won't actually get too many advantages from using something like swift UI because I do graphical apps that have a lot of touchy kind of interactive things that happen and so there, there's still going to be time, you know, we don't have seen kit running on there. You don't have any 3d engines built into it. So it's, it's a baby framework, but it's really fantastic out of the gate. And honestly, I'm a little bit jealous of all this swift people getting to take advantage of it. So Speaker 2: 46:02 good job man. And Yeah, and as people explore with it and I see it, it's, it's again, it'll be when it comes out fully, like if people will be able to take advantage of it and build the things they want to build. And that's always any problem of anything new is it has, this is what it does. And then, you know, Developers Aka us, I would like everything. Please can I just have everything right now? Give it to me. So I, that's what I'll see you I'll be interested in. Speaker 3: 46:28 Yeah. And, and rumor on the street is that apple is going forward with those things. This is not some baby pet project or anything like that. They're serious. They're hoping that this will be used there. We've mentioned this on the last episode. They're trying to unify their platforms from the watch to the phone to the pad to the w what are they going to have an ankle bracelet or something next year yet Speaker 2: 46:49 everything. Yeah. Well, and, and, and the funny part, in the best part, not even funny, part of the best part is that this'll, this will maybe whether it was declarative or not, this will get rid finally of the one thing that I absolutely hate about Ios Mac watch and t VUS development Speaker 3: 47:10 storyboards. Speaker 2: 47:12 Yes they are the worst state. Literally the worst thing ever created. I hate all of them, but are, I mean there are now, no, they're not excellent. They are XML but they're not XML. If you're gonna make an XM, I'll make an Eczema, I'll be very happy. But the, the win win nibs, all these new developers, I don't even know what names are the zip files, those nip files came out. It was, it was like, you know, we've always mentioned, cause we're old timers now at this point, my 3.5 iPhone with four 80 by three 20 when I was developing for these, it was amazing. You know, it's just like, here it is. So that was a little bit okay. And then all of a sudden as as things progressed and now we're worried about all the different resolutions. The notches, the iPad oss, the split screens and like the, what is that thing called for the different screen? Sizings Speaker 3: 48:06 Oh, I know what you mean. And now you made me forget it because you didn't know it. But size classes, Speaker 2: 48:13 size classes often, you know. Yeah. Oh terrible. Speaker 3: 48:18 It's all good man. I, I've been, I've been writing some new apps. It's good. It feels good. Um, I updated in all the app. Felt good. Um, I love, I love UI frameworks. I, you know, my favorite old one was shoes from Ruby. I love these things and so I'm just excited by all this and I hope that, uh, we'll steal some ideas from them for our UI frameworks. Speaker 2: 48:45 Yeah. I like, as things evolve. Now I will say this before we get out of here, here, I was listening to this podcast, I'll put it in the show notes. If you have three hours to kill this talk shop said that's any, that's basically any talk show episode, by the way. Um, I've now moved, by the way, to 1.2 x on my podcast player up from one dot. One pretty excited about it. Speaker 3: 49:05 I was a two to three person for a time. Speaker 2: 49:09 Awesome. Pasado train yourself. It's fun trained in neural network. So I will say one thing that I didn't know that happened that is inside of the, I guess it's new iPad o s slash the new Macko ass is a feature called sidecar. Now I know sidecar already sidecar. You can take a Mac and it extends your Macko ass or an iPad and extend your Macko ass. But did you know that when you do that it will put your touch bar onto your Mac or onto your iPad Speaker 3: 49:46 screen? Touch bar? You mean I'm finally going to have to start writing touch bar support into my apps. That's insane. Yeah. I've been completely ignoring that piece of technology for forever. Uh, darn it because Speaker 2: 50:00 I said like they were, they were saying they'll be, we'll put the touch bar onto your iPad. Now, the funny part is that iPad is not a touchscreen, so you can't touch it when it's inside car mode, but you can use an apple pencil to interact with it as a mouse. I'm so confused. You're joking. That last song about the touching. That's not a joke. Yeah. Oh, okay. But you would think that they w would, the best part would be is like if, if it, cause a Mac is not a touch screen device, but it would be, I don't, they said they didn't do it, but I'd imagine the touch bar, it's in the name, but here's what's really cool about this. Okay. If you build an app and you build touch bar support for it and your users are using it like a Mac book or a macbook air or something, it doesn't have a touch bar and they use sidecar, your touch bar shows up on the iPad still. Speaker 2: 50:52 I love it. I can't wait. I'm sidecar everything. I'm so sad though because I've totally avoided programming for it. I guess I read the docs once, but I never implemented any code. You got to do it. All right. Well anything else from you on this? We've gone way too long. No, and I'm sure we'll be talking about it over the next couple of years. I mean, you should start using it as swift UI version to skip the first version. It's always the roughest if you're a swift developer. Oh we didn't, we didn't talk about the editor at all. That's a super hot editor, but we'll talk about it some other time or we'll just make allusions to it. Alright, well thanks everyone for sticking with us and this, uh, conversation today. I'm excited about something. I love when things evolve and things change. It just drives, you know, ideas more than anything. Speaker 2: 51:40 Um, so yeah, we'll see what you can do with your wee, uh, application and then you can make it all crazy and declarative and awesome. Yeah. Declarative and awesome. I'm running my app like that right now. It's going well. I'll let you know what I see. Weeks I've seen, I've seen, I've seen continuous, so I know how you build your apps, frank. It's crazy. So, um, alright, well thanks everyone for sticking with us. Of course you can find us everywhere on the internet at James Mountain magnet app or Claire on the podcast is at merge conflict FM. You can also go to merge conflict.fm. You can subscribe, you can do all the things. You can check out, show notes, you can click on the things you can rate us and apple podcast. We would love that. And if you're already on, what is the new version of Macko called? Not Catalyst, but also Kadana Catalina, Catalina. If you're on that, you can use the new podcast app and rate us from your Mac. Now, how cool is that, frank? I love that it's an iPad app running on the Mac, but future is now all this is going to do for this week podcasts. Until next time, I'm James Monta Magnum and I'm frank. Thanks for listening. Speaker 1: 52:49 Peace. [inaudible].