Why should companies go with a cross-platform solution?
- Consistent User Experience (whether that's a good idea or not)
- Synchronicity in Code Base
- Budget - Use existing team expertise
What are the differences between cross-platform solutions?
- Web Based - Cordova, Ionic, PhoneGap
- Bridging Solution - Flutter, React Native, NativeScript
- Language Based - Xamarin - Use C# to Call Native API
What are the challenges with cross-platform solution?
- Dependent on Vendor Support
- Dev teams need to keep Cross-Platform Tooling up to date
- Using a Specific API (Metal, HealthKit, etc…)
- May not be supported by Cross-Platform Tool
- There may be instances such as UI - you want differences between devices
[00:00:00] Leo Dion (Host): Today with us. We have Rob Kerr. You want to go ahead and introduce yourself.
[00:00:05] Rob Kerr (Guest): My name is Rob Kerr. I'm a consultant working primarily in mobile platforms a lot of native development but more and more it's cross-platform with Xamarin, Flutter, and some other tools and I work with primarily business customers who are looking to deliver applications to both IOS and Android with the most efficient development process that they can experience.
[00:00:29] Leo Dion (Host): Awesome, really glad to have you on Rob. I've known you for three or four years now. It seems like.
[00:00:35] Rob Kerr (Guest): Something like that.
[00:00:37] Leo Dion (Host): Yeah, and we've met either at meetups or touch base every so often. So it sounds like recently you've been doing a lot of cross-platform development. And like I said, I have a little bit of experience with that of dabbled a little bit in Cordova as well.
[00:00:54] My bread-and-butter, my expertise is obviously Swift [that is] native Swift development. That's what I like to do. I think it has a lot of advantages but there could be situations like business reasons valid business reasons to go cross-platform, right?
[00:01:10] Rob Kerr (Guest): Yeah, I think so. And I think you and I have similar backgrounds in solutions as far as Apple. I've done a ton of native development in Swift and iOS and some on Android as well. Probably the last year or two a lot of my work has been cross platform and it's kind of driven by that business need or want to you know, hit both platforms efficiently. And currently in the IOS app store has you know about 1.8 million apps and the Play Store has about 2.1 million but the stats tell us that I think AppFigures had a study that only 450 thousand apps are truly cross platform where the same application is deployed in both platforms, which is you know, it's really small numbers less than 10 percent.
[00:01:54] And so when will you find is you know, Everyone would kind of like to be on both platforms at the same time, but not a lot of folks are or at least not not an efficient way. So in the past you mentioned Cordova and PhoneGap and probably five or six years ago that was almost the only game in town.
[00:02:11] But now this cross-platform frameworks are you know sprouting up quite a bit and all of the mega vendors offer something like Flutter or React Native or Xamarin from Microsoft. And so it's definitely coming into its own and there's certainly those those applications like business applications, especially where you need to have both platforms, but maybe don't want to fund building the app twice once for each so yeah, I think so.
[00:02:38] Leo Dion (Host): What are some situations where businesses should choose cross platform as opposed to a native?
[00:02:46] Rob Kerr (Guest): Yeah, that's a good question. And that's you know comes up a lot because the sort of the reasons not to usually drive into accessing very exotic APIs and things like that. In my mind if a business really wants to deliver on both platforms, especially if they like to do it at the same time that kind of tends toward cross-platform if you can particularly if the user experience they wanted to be the same on both platforms then using something cross-platform maybe doesn't mandate it but certainly makes it much likely that an application is going to work the same way so that when the support call comes in then you know somebody who needs to help a user doesn't have to think about you know, how does this work on Android how does this work on iOS. How's the potentially work on Windows?
[00:03:29] Then the obvious, you know elephant in the room is just budget. If you have to build the same application twice that costs, you know potentially twice as much typically usually other different teams that work on IOS and Android if they're done completely native.
[00:03:44] And then you know, you really have to think about in the long term how does that go into support cost? So if the application has to have a life cycle, new features that we added bugs need to be fixed, if they're written in two different languages than two platforms than that's something to think about so. As I think about it and on the consumer market, if you are going to develop an application to compete with one of Apple's native apps or Android and it needs to be really exotic, you know, cross-platform might not be the right choice for that.
[00:04:16] But for the vast majority of apps are content consumpution or business orientated and so on It's probably the majority of the leading cross-platform tools can deliver an app with the same user experience. So something to think about.
[00:04:33] Leo Dion (Host): It's funny you mention user experience. I would say that can be a benefit of cross-platform but also a hindrance in a lot of ways because like recently I was doing work with the client and they were really good about making sure that the user experience was actually different on both platforms precisely because of the expectations that certain like Android users have with their UI and Apple users have with their UI - there are definitely big differences. Specificly I'm just like thinking about like hamburger menus is like we don't have hamburger menus is very much on iOS and that's that's one of the jarring things is when you use a cross-platform app.
[00:05:18] It can be obvious and jarring when you're using an app that is built cross platform, but doesn't like take into account like the user experience differences between both platforms.
[00:05:33] Rob Kerr (Guest): Yeah, there's a little bit to unpack there because as I've worked with clients that you know, definitely wanted pixel-perfect identical experiences in both platforms.
[00:05:42] Now, you might argue that you shouldn't do that right and Google and Apple and tell you shouldn't do that because you're not following their conventions and that's a very valid argument, but the cross-platform tooling doesn't really dictate that you have to have that same experience on both platforms.
[00:05:58] Leo Dion (Host): Right. I think it really depends. It really depends on which cross-platform tool you're using
[00:06:05] Rob Kerr (Guest): It does but even on most of them, I mean you can implement something conditionally. So you say that you know, this is the view used on Android. That's the view used on iOS for example, if that's what you want.
[00:06:17] I don't think cross platform prevents that but conversely if you really want a very identical experience cross-platform probably enables it better than forcing a common UI paradigm into the two different native tools but your central point about you know, not deviating from the design aesthetic of iOS and how it works, you know, whether you want to use a tab view controller versus a hamburger menu is very valid point and an important design issue to think about.
[00:06:48] Leo Dion (Host): Yeah, that's interesting. I'm just kind of curious going a little bit more into that. What is the reasoning behind having a consistent experience
[00:06:58] Rob Kerr (Guest): UX? Yeah.
[00:06:59] Leo Dion (Host): Because your typical UX person would be like no no no, it should not act exactly the same way on every platform. Is that is that usually like an executive decision that's done despite how it's not the right decision? Or is it a business decision typically to do that. Like I'm just kind of curious about that.
[00:07:23] Rob Kerr (Guest): Yeah, because what I think you just said is you think designers would not want that. I've actually worked for designers that exactly wanted that so I think it depends on the thought leadership behind the app the.
[00:07:34] Most compelling I think business reason that I've heard is kind of from a support perspective that that an app is going out and then a support department needs to support it. And when a user wants to know well, how do I go into the settings menu? If it isn't the same then they need to know how to support it in both directions.
[00:07:53] So I think there's some degree of. Validity to that concern but I don't think it should override, you know, the overall user adoption and user satisfaction with the app. So even many iOS apps use hamburger menu is even though that's really not an iOS thing.
[00:08:08] Leo Dion (Host): I don't like hamburger menus
[00:08:11] Rob Kerr (Guest): on iOS
[00:08:12] you know, but a lot of apps do you use it and you know many Android apps will you know use tab bar instead completely and not even have that flyover menu. So I think though the kind of a point is that that you can do it differently or not do it differently. I don't think the cross platform tools necessarily corner you to have to use a lowest common denominator. But if that's in your intent, it's probably more and more efficient way to do it.
[00:08:41] Leo Dion (Host): Yeah, I could see how that might. I'm okay. If the decision is yeah, it's not a great user experience. We're willing to admit that for budgetary reasons. We we just want to like have a consistent experience. I totally get that but I like that makes total sense.
[00:08:55] But if it's like actually like no no we're going to make iOS users have this uncomfortable experience because we think it's better. It's like I don't know about that.
[00:09:06] Rob Kerr (Guest): Yeah, well, I would hope someone wouldn't want to like do it in order to give them an uncomfortable experience.
[00:09:12] Leo Dion (Host): Yeah, I don't mean like purposely but just like they actually think that they know the best way to design on an iPhone better than Apple does it's like or vice versa, right?
[00:09:21] Like that would be an uncomfortable conversation to have yeah, and when we're talking budget. I'll talk to people about the specific subject. There was a great talk last year. I went to in New York given by one of the guys at can't think of his name now Artsy and he talked about transitioning to React Native and how their team transition to React Native and it sounds like that decision was more based on the fact that they already have an existing experience with react.
[00:09:56] Rob Kerr (Guest): All right,
[00:09:57] Leo Dion (Host): and so it seems like when we talk budget, typically we're talking at what and we talked about this in a previous episode on back-end development. Like what your team is already comfortable with is going to be like the healthiest way rather than trying to like necessarily shove Swift or Objective-C in Xcode down their throats if they're not willing to make that sacrifice and training and hiring like it totally makes sense to like just already use what's already existing in your team in those cases. It's a sacrifice obviously because you're not going to get as good of an experience perhaps that specialize in different platforms. But in the end like it might be a way to like save some money is just hey, this team has great cohesion doing react and React Native. Let's just stick with that.
[00:10:44] Rob Kerr (Guest): Yeah, I mean you can't ignore the kind of what resources do you already have what things you're already know how to support if you're building a mobile application to complement a suite of Enterprise, you know other applications and that other team can eventually support the mobile have to because you use similar technology or you know, I mean that that's certainly a benefit and I think there's you know, that is an important factor to consider. So, you know you and I touched on Xamarin earlier and C# - It's XAML.
[00:11:14] If you use Xamarin forms, you know, it uses Visual Studio, you know, if you already have 50 people in your company that use all that kind of thing every day, then yeah that might make a lot of sense versus building a very small team that you know is specializing in Swift or Objective-C or Java.
[00:11:32] If you lose one of those folks then you're in a lot of pain because you have to replace them. And I think you if you look across like what cross-platform tools different people advocate is very often the technology, they already know. So, you know web oriented folks will typically advocate, you know, kind of a phonegap or you know, react or ionic because you know, they're familiar with those those tools already.
[00:11:57] The Microsoft shops probably going to be very interested in Xamarin because it's very C# orientated. Flutter is really gaining a lot of traction from Google and it runs with Dart underneath which which which doesn't really have an installed base some you know, so we'll see where that goes but on some of those other ones, you know, absolutely if you have folks had already have those 80% of the skills. They need to build the app. That might make a lot of sense.
[00:13:56] They want to get mobile as fast as they can so this can make a lot of sense and I think it does make a lot of sense for many kinds of apps especially if they are consumption focused like a mobile news reader or magazine website, you know can be a really good fit.
[00:14:09] Now the second segment I think of is like tools that have some common language for the UI and and then have some way to bridge to native SDKs. And that's kind of the thread here is how close to native sdks are you? How abstracted are you into more of a web environment? And you know, the second one is really a common language and there's some bridge and React Native probably falls into this category because it's using React for the UI, but you can access native sdks through bridges and so on - maybe not as efficient as being fully native, but at least you can you can get there most of the time. Flutter probably is a little bit in this camp as well. It's you know, it's of completely abstracted environment, but you can get to native when you really need to. I think these tools are maybe a little more complex to use because you're sort of have one foot in both camps and debugging can be a challenge and so on but it kind of might be the best of both worlds depending your perspective.
[00:15:06] And then the third is guy can think of you know, there's a few tools to fit in there. Xamarin is probably one and that's that's where you're using the common language, but actually programming directly to underlying APIs. So in Xamarin you use C# to call the same methods in apis that you would in Swift or Objective-C and it generates native iOS code at the other end. There's some complexity there and so on but I think those three kind of segments.
[00:15:35] Are the ones that think about you know web driven, bridged, and just native with other languages kind of tools - that's that's why I think they fit. There's some bleed over obviously and some people say well this one's a little bit more in the first then the second that could be true but from a skills and adoption point of view I think that's a good model.
[00:15:53] Leo Dion (Host): Where does Flutter fit into that is that just basically Dart for calling native apis?
[00:16:00] Rob Kerr (Guest): Flutter is unique because like with Xamarin or no, I think even to some extent React Native. It's your rendering like in Xamarian your rendering a native like UI button in iOS and on Android it's you know, it's rendering a native Android button you're just using C# in that case to do that
[00:16:19] Flutter is different because it actually is everything you see is drawn by Flutter on a Skia canvas. So that's kind of cool because you know, exactly what you're getting both platforms. It's very fast. And I think it'll go 60 frames per second or something like that.
[00:16:34] So it's a kind of like Cordova in a way but better but it also does have access to some native sdks as well - not all of them and that team is working on the bridging but it's if it's somewhere in the middle. I think I put a serve in the center camp of something that's common common language and bridging to native to an extent.
[00:16:55] Leo Dion (Host): Cool. So the difference between like React Native in Xamarin is that like React Native has its own set of apis whereas Xamarin is just using like - you still have uiviewcontroller for instance, but it's in C#, correct?
[00:17:10] Rob Kerr (Guest): Yeah, I think that's the right way to think about it as an react to you guys have kind of using a an abstract paradigm react and then it has a bridge to Native culture.
[00:17:20] So so you can get there whereas, you know examine is really totally native unless you use Xamarin forms but if you Xamarin iOS and Xamarin Android you just using a different language to access the underlying operating system apis. And then Xamarin, you know, the reason you would want from their perspective, the reason you would want to do that is because all that common code like web access and business logic and all that is completely shared. It's on C# and there's just no deviation between platforms. At least that's the concept right.
[00:17:50] Leo Dion (Host): That makes total sense. What out of those three types are out of the platforms that you seen what do you prefer?
[00:17:58] Rob Kerr (Guest): It's really good question. So definitely I tend to gravitate a little bit toward. You know, what's a really good fit for the organization. What's going to be good for long-term TCO and support I do work with a lot of business customers. I think Xamarin is a really good fit there.
[00:18:14] I actually like it like working with Xamarin because it works directly with the operating system. So if I have algorithms and Swift that access HealthKit and can do all the things that Health get does I could pretty much Port those. The Xamarin without any changes and it has source-level debugger going at every level which is kind of nice. So I like that platform, it's not that commonly used I guess in you know outside of the business realm. Then outside of that realm I do like Flutter. I like what Flutters doing right now and the support it has behind it. So I'm hopeful that that will continue to grow and get better and React Native is you know fairly common out there and freely use in there. So there's a lot of folks available to work on that technology. I think it's pretty compelling. I haven't done much work with with React Native, but you know Associates that have used in love it, you know kind of sold me that that's a pretty good solution.
[00:19:07] Probably the ones I avoid a little bit are more the web driven ones. So the phonegap and ionic, you know, I think they're very good and they can have a place but at least the projects I've worked on. Dig more into the weeds with tell using Health Care using Apple pay and so on and so on and and I think the further you get away from the ability to get the Native APIs the less of a good strategic decision that technology is probably going to be.
[00:19:45] Rob Kerr (Guest): Yeah it is. Yeah. It's yeah NativeScript is I mean, it is really interesting. It's some. It's even more native than React Native, I guess right but you know that probably its biggest
[00:19:57] Leo Dion (Host): challenge is that the amount
[00:19:59] Rob Kerr (Guest): of folks out there that you the ecosystem.
[00:20:02] I mean, it's just really not there. Most people probably never heard of it. But and there's so many competitors that I think they're going to have to travel a challenge getting traction, but technically very compelling.
[00:20:15] Leo Dion (Host): I think I hear a lot of ionic and usually if it's a fairly simple app, you don't have to deal with the Native APIs in that case. I know that there's some bridges but not it's not anywhere near as comfortable as working with the other one.
[00:20:33] Rob Kerr (Guest): Yeah, ionic actually worked on a project for a client two or three years ago. And and we did some you know, we were able to get to a lot of native things you can bind, you know at the time Swift was really new so we needed to print some things on Zebra printers which had to be done with Native objective-c and we were able to glue it together. The debugging again was a challenge because you can't necessarily debug that library that that are the framework that you're linking in very easily.
[00:21:03] So that was a challenge. But ionic, I think what we had trouble most with was kind of controlling the UI a little bit because it's a web-based and and then just generally it's the completely open source volunteer ecosystem.
[00:21:17] Leo Dion (Host): Well, the other thing about ionic is you're locked into angular, whereas if you use something like that, I think you know phonegap and ionic.
[00:21:25] I think they're the same thing essentially but if you like break it down to like Cordova, so the correct me if I'm wrong but like Cordova is an underlying Apache open source project that will convert web applications to mobile apps right and then ionic is kind of built on top of that and then also brings in angularjs.
[00:21:47] Is that correct?
[00:21:48] Rob Kerr (Guest): Yeah, pretty much. But you know, I don't necessarily see there's a downside is as much as the reason that you're doing it,
[00:21:54] right exactly. Yeah, so if you already have an angular team, then it makes total sense to go with ionic. You can go a step lower than that and use Cordova. If for instance your a VueJS team that might make more sense as well.
[00:22:11] Yeah, I think Cordova is basically running a web app in. You know in a web view with some, you know specific JS, you know CSS files. So it's pretty plain Jane, but all the platforms I think kind of funny categories if you're you know, Ionic, you know is you know has it has its particular framework, you know, if you like reacts with power like React Native if you like dotnet you probably like Xamarin, you know, and so on so it's it's and that's where these projects came from its, you know groups that specialized in those platforms came up with a mobile solution so it's I think part of part of the package.
[00:22:48] Leo Dion (Host): And then I hear a lot of React Native. That's typically the biggest one I hear and then Flutter is kind of the one that's gained a lot of momentum of the last few months and then here in Michigan. We have a lot of C# and Java developers. So it makes total sense where you'll hear Xamarin being used is typically amongst companies that already have like they're either Microsoft shops, or they have a ton of C# developers and make sense for them to go with Xamarin
[00:23:16] Rob Kerr (Guest): Exactly and all of those if you sort of you know, follow the money kind of thing, you know React Native is Facebook, Flutter is Google, Xamarin is Microsoft and then there are a lot of Open Source volunteer Community Driven things you know it out there as well. And I guess you know Native Script has a corporate behind it as well, but it's not really a mega vendor.
[00:23:35] Leo Dion (Host): Right, yep. Exactly. What are some of the biggest challenges or what are some of the points within a working on a project where you were just like guys you're making this much harder than you need to you guys should really consider switching over and transitioning to doing a native app or what are some like code smells or smells within a project that you're like - okay at this point I think you guys should consider opening up xcode learning some Swift because this is not going to work out in the long run.
[00:24:06] Rob Kerr (Guest): Yep that's really good question and it's definitely something to consider because if you're starting a new product that your likelihood of being able to switch to something else has is low once you have that much sunk cost into it.
[00:24:19] So and I think it's a it's really good. You know, what are some of the challenges probably the first isn't necessarily feature driven, but but just that if you use a cross platform platform or development tool to develop something, you know, you're not going to be going directly to Apple for support you're not going to be using Apple's apis directly.
[00:24:39] So you have to kind of think about that a little bit that's kind of obvious. Right? Because the whole idea of cross-platform is your working abstraction layer, but you know, your team does need to have still a pretty good understanding of the underlying operating systems and so on so there's there's somebody still need to do.
[00:24:55] As far the kind of feature driven [development], I was talking to a client and They said you know, we're thinking cross-platform - here's what we want to do. The red flags I am probably looking for is you know, are you trying to do something that is really really specific to the operating system underneath. So are you trying to use metal on iOS which you might not find any support and most cross platform tools now.
[00:25:20] Or are you trying to you know do something like earlier we talked about, you know, having a completely different experience on the two platforms. Well, if it is really completely different than you're still going to be writing it twice just in a different framework and you know, does that make sense?
[00:25:35] Another thing? I kind of look at her think about is how much of this app is you I how much of the app is underneath logic and code and things like that. So if an application is like 90% not the UI then cross-platform may make a lot of sense why I write a lot of business logic and database logic and calculations in two different languages to hit two platforms, you know, maybe it makes more sense to consolidate them.
[00:26:01] But you know, if the app is primarily, you know, if it's something that is totally UI driven 90% of it is kind of UI stuff and you want that UI to be very different on two platforms. That's like well maybe cross-platform doesn't doesn't make a lot of sense.
[00:26:18] Leo Dion (Host): Yeah. I think those are really good points before we close out. Is there anything else you wanted to mention?
[00:26:24] Rob Kerr (Guest): No, I think that's a pretty good discussion. There's tremendous interest and you probably see it to with you know, being able to ship the both platforms at the same time and you know, but having completely incompatible ecosystems makes that kind of tough.
[00:26:37] So I think a lot of people are thinking about this and you know, unfortunately or fortunately there's probably six really good choices out there to of technology stacks to use and not not everyone is is right for everybody. So it's a.
[00:26:51] Leo Dion (Host): Yeah, I think a lot of folks go into it thinking it's a shortcut it does help but it really depends on your team and it really isn't as much of a shortcut as people realize just to kind of reiterate what you're talking about here.
[00:27:05] Like I think the good ones is like if you really want a consistent user experience like you really insist upon it probably cross platform is the way to go. If you want like your releases to be in sync that makes total sense. And then of course if you're going to have an already existing team that is familiar with some sort of language or framework that's going to be used by a cross-platform solution then using it saves you money will help your budget when you first start off. The other thing I was going to say is like if you want to test an idea like you want to just put an app on both platforms to test that specific idea - maybe cross-platform is a great way to do it as well.
[00:27:44] You talked about the three differences between cross-platform solutions your Cordova based which is essentially a web View and then there's the bridge Solutions like Flutter React Native Native script and then solutions that are strictly language-based if your team is familiar C#, they're probably going to want to go with Xamarin which just basically takes the Swift and objective-c and turns it into C# for your team and just use a platform solution that is something that your team is somewhat familiar with if you already have a react team if you already have a C# team or web dev team that gives you an idea of where to go. But however, the real challenge is if you're going to use a cross-platform solution is that your in end up being dependent on another vendor or another community that is going to add another layer of complexity when it comes to support. So not only are you going to be beholding to Google or Apple? But now you have to be dependent on the react team or Xamarin the folks at Microsoft or the folks at ionic to make sure that they stay up-to-date with whatever changes come to iOS or Android.
[00:28:50] If you're using a specific API that's special to a operating system such as metal or health kit or just thinking of like Apple pay anything like that. That's very specific to an API that might be good indication that you might actually want to go with Swift and Native. Then if you are expecting to really personalize the UI to different platforms and there's a lot of UI involved it might also be a good indication that you want to go native as opposed to going with a cross-platform solution. You think I covered that pretty well?
[00:29:28] Rob Kerr (Guest): I think so. Yeah, I think and you know, it's kind of a thread that runs through there is a how much how much are you going to write code wise or UI development that can be used in both, you know both platforms. So it's something really to think about but I think that's a good summary, yeah.
[00:29:43]Leo Dion (Host): Rob. Are you available on social media?
[00:29:46] Rob Kerr (Guest): I am you can find me on Twitter @recursive.
[00:29:53] Leo Dion (Host): Awesome. And before we close out, I have one question for you actually it's more like two questions for you. It seems like every guest we ask this question. When you do Native, what do you use to build your user interface? Are you a storyboard or coding person?
[00:30:07] Rob Kerr (Guest): So this is the code in storyboard question. (laughter)
[00:30:10] Leo Dion (Host): Yeah. Yeah.
[00:30:11] Rob Kerr (Guest): Yeah, I don't think there's a middle ground answer to that other than saying...
[00:30:15] Leo Dion (Host): Well If you're a coward if you're middle ground, but other than that... (laughter)
[00:30:21] Rob Kerr (Guest): Well I'm not a coward, I I tend to use storyboards because I find it easier to support down the road kind of, you know, rather than writing a lot of code, but I have done both on the Apple platform.
[00:30:38] Leo Dion (Host): Yeah, I go back and forth on it, I think like if you're on a big team storyboards are really really difficult because you're going to end up with emerging issues.
[00:30:47] Rob Kerr (Guest): Yeah merging issues is you know, it's a big deal for storyboards. It gives a visual declarative thing about what's going on with the app kind of like it but it seems like, you know, we're moving toward more declarative UI on this with SwiftUI is doing that's what Flutter does with dart and it seems like the winds blowing in that direction.
[00:31:03] But if I you know, if I have a pretty standardized user user interface, I'll use a storyboard for that. It makes a lot of sense.
[00:31:09] Leo Dion (Host): Yeah, especially when you are first starting off. So yeah Swift UI - I was going to get into it. What do you think of SwiftUI?
[00:31:16] Rob Kerr (Guest): You know, it's a really good direction. It's to be seen but what I loaded up a development Mac with with the new version of Mac OS and installed xcode 11 on there and tried it out and and I really like it. The whole cycle where you In Mobile where you lay out your app screens and you know kind of get it working and then you know compiled build deploy to device and then you know washing repeat the most platforms are trying to deal with that react certainly is React Native as a platform that tries to address that and Flutter to an extent. I think they'll get there.
[00:31:52] But SwiftUI is aimed right at that and I think the way they're implemented that is is just right and you know, as you mentioned merge conflicts with UIKIt and so on and that's kind of solves that problem because it's just code at that point. Yeah, and I like the to definitely the split pane where you can make changes on the UI as if it was a storyboard and it updates the declarative code on the left side. I think that's really cool.
[00:32:14] Leo Dion (Host): I just hate that you need Catalina in order to really take advantage of it. Other than that, that's fantastic .
[00:32:22] Rob Kerr (Guest): It's temporary thing. It only supports iOS 13, which means it's really not going to come into its own for, you know, a couple of years probably - it's right direction. I like that direction.
[00:32:33] Leo Dion (Host): I mean if you're willing for an app to be in the App Store in October and November then I would totally recommend people look at Swift UI for their brand new app if they're willing to wait on it. I don't know like
[00:32:46] Rob Kerr (Guest): it's pretty buggy at the moment. So yeah, it is taking a risk, but certainly if you're starting something absolutely brand-new and you're comfortable only shipping for iOS 13 then sure. Why not? Yeah,
[00:32:58] Leo Dion (Host): that's what I meant. Of course. But yeah, so funny how out of this whole thing people were looking forward to iPad apps on the Mac and marzipan and like out of nowhere comes this like brand new and I love how it's completely severed. My some people aren't going to like it but it's completely severed from Objective-C.
[00:33:17] It takes advantage of like the whole Swift and Swift DLC stuff and creates a decently healthy way to build UIs because even it going back to the question going between storyboards and coding your own you I like I think a lot of people would, going back to [the] cross-platform Development discussion, a lot of people like building their UI in HTML and it makes sense like CSS and HTML are just a lot easier to work with and having a declarative way to build your UI using Swift UI.
[00:33:50] It's a much more comfortable way because like storyboards all that stuff was like it's a black box like you can't go into that XML and figure out how to manually add like a button to user interface using storyboards. It's impossible. And then decode it like I do like the some of the stuff that they've added and last couple of years with constraints, but it's nowhere near as nice as what we've gotten with with declaratively building user interfaces and this is exactly the way user interfaces should be built. It makes total sense.
[00:34:26] Rob Kerr (Guest): A lot of people think so. Yeah.
[00:34:28] Leo Dion (Host): Well, thank you so much for coming on the show, and maybe we'll talk about the stuff again.
[00:34:34] Rob Kerr (Guest): Great. I've enjoyed being here. I appreciate the invitation and great conversation.
[00:34:38] Thank you. Yep.
[00:34:39] Leo Dion (Host): You're welcome.
★ Support this podcast on Patreon ★