 On today's toolbox, in the time it takes our producer to take a 20-minute walk, Sam Bazoo is going to review the state of mobile development. Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and joining me today is Sam Bazoo. Hey, Sam. Hey. Welcome back on the show. Thanks for having me back. Sam's a developer advocate with progress software and a frequent guest on the show and a guest host once. That was about a year ago. Yeah. We love your show. The famous hour-long blazer episode. Yeah, and then things have come a long way in Blazor Land, but glad we could talk about Blazor way back in the days. Things have come a long way in many lands. What I thought we would do today is kind of apply that lens to mobile development. So we know that there are many ways you can build mobile apps. We'll quickly review those. But what is the state of mobile development? What's going on in Xamarin land and PWA land, etc. What are things that people should be aware of, should be looking for? Kind of we'll just sit back, we're actually sitting. Yeah. Don't sit too far back. Right. We'll sit back and just review the state of mobile development. Sure. So informal chat between developers. Yes. See which way you should go. What's new? So I think the state of mobile dev is complicated. Yeah. Because again, there's a lot of choice. So that's a good news. There's a lot of choice. Your technology stack can be whatever you have expertise in. The downside is sometimes as developers, we see too much choice and it's a little crippling. Okay. But the silver lining is no matter what stack you choose, the tooling is very mature. And it really, which technology you pick, does not dictate the type of app you can build. It's all the same. Okay. And despite the complexity, there is actually some clarity. Like if you wanted to do .NET, here are your options. If you wanted to do JavaScript, here are your options. Right. And again, the tooling is very mature in every stack. Okay. So for each of these, let's just quickly review what we mean by these, who's going to be doing this, and then we'll go back and talk about where we're at in each of these fields. Sure. And I'm sure there are more ways of building for mobile, not just mobile apps, but these are kind of the five broad ways I see it. Okay. So the thing we don't have or we don't talk a lot about is native. Because there isn't much to talk about. There are three big platforms, iOS, Android, and Universal Windows platform. You essentially go to Apple, Google, or Microsoft. You get their SDKs. You're building closest to the metal. Great experience. Everything is good, except it's expensive. These are three different platforms, and you have to maintain three different code bases. It's hard for a single developer. It's harder for enterprises to do three different code bases. So again, I'm not saying don't build native, but if you have the resources and if you want to target one platform first, go for it. Socially, if you're doing like games and things like that. But it's 2019, you would ideally want to build cross-platform solutions. And that's where we look at the other things. So number one on this list is mobile web, which I sometimes consider that to be the lowest-hanging fruit. If you have a website, it should work nicely on a mobile form factor. There is a lot of help in terms of open source frameworks. There is Twitter Bootstrap. There is all the spa frameworks we make in the UI. So your controls should be pinch and zoomable and work nice on a mobile form factor with touch. And then the mobile web concept, you can kind of take it to a very advanced level of a progressive web app, which is something I think Google first started pushing. Microsoft is absolutely behind it and Apple surprisingly is also on board. So it's a way in which your mobile website is a good citizen on a mobile device. It is something that you can pin the home screen, the icon to your home screen. You can receive push notifications. You can have some service workers. So it's a nicer experience, but you are still using the web as a distribution mechanism. If you want to hit the stores, that's when you look at some other technologies. That's when you look at hybrid, which is the whole Cordova and the PhoneGap days, which may be falling out of flavor a little bit, but I think it's still a legit strategy for like simple line of business apps. You are using web assets, web technologies, to build up an app that you're going to bundle up and put it in the store. If you do a good job, the user should not notice that it's not a native app, because it is not a native app in any way. It is running literally inside of a web browser shell inside of the sandbox. So performance isn't the best, but again, if you don't care about down to a millisecond thing, it's fine for you. But if you want that kind of performance, and again, if you want to use web technologies, you can actually build native apps that are cross-platform. So there are lots of developments that have happened in the last couple of days. We call this thing kind of the JavaScript native way of building mobile apps. There are frameworks like NativeScript, React Native, which will help you build native apps that are also cross-platform. So this is the JavaScript and the website of the story. If you are building a website today, you may want to stick to the JavaScript ways of building mobile apps, because your code sharing story between web and mobile might be better. But if you are somebody who has done NEC-Sharp or .NET in the past, or if you have other desktop applications, then you're looking at the cross-compile solutions. And for that, I mean, I think the boat has sailed, Xamarin has done a phenomenal job in the last five or six years to make it super easy for .NET developers to take their apps to iOS, Android, and other platforms. And this cross-compile story is getting more love. We see Uno platform, we see things like Flutter. So just a lot of choice. And I almost always say, take a look at what else you are doing if you want to plan your mobile strategy so you can have the best possible code reuse. Because any of these stacks is mature enough and the tooling is very good. So which bucket does Blazer fit into? So Blazer is not for mobile, technically. It is going to run on WebAssembly. It is going to run fine on mobile browser. So it is cross-compiled at this point. It is going to run C-Sharp-compiled down through LLVM into WebAssembly stacks. So yes, it will run. But Blazer is the way of coming to the browser with C-Sharp and the ASP.NET razor syntax. While if you just want to come straight, so a lot of us who, I'm going to show my age here, but I did Silverlight back in the days and it was beautiful because the tooling was nice. And so XAML is slowly making its back into the browser. So if you want to do like Xamarin forms type thing in the mobile browser, you can do that now. There are a couple of options and still early days. But WebAssembly is really opening up a lot of the different choices and options for us. Okay. So the mobile web slash PWA developers sitting in that first bucket, what should I be looking at? What do I need to know? Okay, so technically a PWA is a website. So every website could be a PWA, but whether it should be is debatable. So at this point, your website should have some characteristics that make it a good citizen on a mobile phone. It should have a manifest file that declares to the browser that I can do a few more things. I can have a service worker running in the background. I can receive push notifications, user can pin an icon to my home screen. So at this point, there is quite a bit of help. And for any of these tooling, like really for your audience, like Visual Studio is fantastic for all of these things. You can do all of this from inside Visual Studio. And there's a lot of help. One of the best things that anybody has put out for PWAs is the thing called PWA Builder. This was what Microsoft put out and it's gotten a lot of community love. So you give it a public facing URL. It's going to tell you for your website to be a PWA, you need to have a manifest file. And here's where you should start. Here's where your service worker should be to run offline, to be able to cache pages and to be able to push out notifications to the users. So there's a lot of help in terms of where the state of PWA is. It's a little complicated. Chrome is obviously way ahead of the curve. Edge is very much on board. In fact, you can write a PWA today completely with web technologies. Put it in the UWP store, in the Microsoft window store. So that's all good. Safari is lagging a little bit behind because Apple is kind of in, they're reconsidering their whole monetization strategy because Apple wants you to put apps in the store, but whether PWA is the right thing to do. So in terms of just the features that your browser can use as a mobile website, Safari isn't there close to what Chrome or Edge is. But again, if you want to use the web as a distribution medium, if you just want to have a website that works nicely on desktop and nicely on a mobile device, mobile web, PWA, that's the way to go. Okay, so what do you, what can you see happening in the next year in that space? Yeah, so since PWA's are purely web apps at this point, you are not going to have as much access to the device, the sensors that are on the device as you do from a hybrid or a native app. So all the things like camera, geolocation, accelerometer, these are things that are hard to do from just pure web because there are security concerns. So I think over the next couple of years, we're going to see that story evolve. So a mobile website should be able to do just as much as what a native app does. So I think that story needs a lot more improvement, but otherwise the core pieces are there for PWS to be successful. Okay, cool. So there's not much to talk about on native, except for support for a new version of the new SDKs. Yeah, so newer stuff is coming out, iOS 13 is coming out. One exciting thing with native land, I think it's going to be kind of a game changer is at WWDC, Apple kind of announced that Apple has a similar app store problem. Everybody wants to build for iOS, not many people want to build for the Mac desktop because that's kind of a niche thing. So they are trying to run iOS apps onto the Mac desktop and every one of those iOS apps can be written with Xamarin. If only they had a universal platform. Sort of. Sounds familiar, yeah, but it's hard to do. So with Mac OS desktop and iOS 13, you should see that light up, that story. And this will be a nice story because now you can have iOS apps that have just been written for mobile work on a bigger surface area with maybe like a hamburger menu, a little more surface area to play with. So that'll be a nice story. Android is coming along features, as you can envision, UWP is coming along, a lot of inking help, a lot of new web browser components. So again, the tooling for the native SDKs, that's just evolving as the platforms evolve. Okay, yeah. Hybrid, not a whole lot new because again, it's been out for a while and you might almost argue that if I'm building a hybrid app today with JavaScript, why would I not build a native app, right? So again, hybrid is a mature platform at this point. If you go to Apache Cordova, if you pick up frameworks like Ionic, that will help you build a nice hybrid mobile app, you do have access to all the plugins, which are the little pieces of code that give you access to the device sensors that are on your phone. So you can do a lot more, even though you're using web technologies, you are making an app. So you have access to all of the sensors, but otherwise, not a whole lot of new. There's kind of a mature space that there's not much going on in there necessarily. Yeah. The last two is where you're seeing like explosive growth and a lot of investments because that's where developers are. We want to be building native apps. I think traditionally, I've always enjoyed how the Xamarin folks have defined what makes a native app? Because I mean, there are blurred lines here, right? So a native app has to have native UI, native performance and native access to APIs. And all of these things will let you do that. So if you look at the JavaScript native stack, you have platforms like NativeScript, which work with pure, and I mean, all of these things are open source, pure JavaScript or TypeScript or with Angular or with Vue. So if you're building a web application today with Angular or Vue, grab NativeScript because it's going to give you that code sharing story. You can build the same components that work on web and mobile. Just your UI stack is a little different. And if you're building websites with React, then go with React Native, right? So again, all of these things are mature tool sets. A lot of these tool sets are... Which ones would you call industry leading or most popular at this point? They're all about the same. It kind of depends on what else you're doing. If you're doing React, then React Native is very popular. If you are okay doing Angular, and then NativeScript is very popular. So all of them are very, very good in terms of the tooling. All of these things are CLI tooling first. So a lot of command lines, but you have integrations inside of Visual Studio because at the end of the day, what you're writing is JavaScript or TypeScript, right? And Visual Studio code or Visual Studio, they're rock stars in helping you write that code. So the tooling is right there. One of the things that the JavaScript native side of the story has done very well traditionally is a very, very fast dev loop, a cycle. Like as a developer, I want to write some code and I want to hit one button and I see it on my app as quickly as possible. So almost all of those things use like, things like Webpack to kind of grab all of your components, configure them, and they can push out just one component. So if you edit one line of code, you see it immediately in the app, be it on the emulator, so be it on the device. So that cycle is very, very quick. So I think JavaScript native at a point is at a point where again, you have complete access to all of the native APIs. So anything iOS or Android come up with tomorrow, you will have zero-day support. So one of the criticisms of the JavaScript world, particularly from people not doing it, is the framework flavor of the month. Don't blink, there's a new framework out, right? There's so many frameworks and just when you learn one, a new one's come along. It seems to me though that it's kind of stabilized. Is that true? Yes, in a way. So you still have new frameworks coming out every day, but when you look at enterprise adoption, like really big projects which need to drive products forward, you have kind of settled on three or four big ones. So Angular, React, and Vue, I think those are the three main big ones now. I don't think jQuery is really dead. So that's another way of doing cross-browser things. So yes, you will always have the problem. So tomorrow, React might completely fall off the flavor, but today it is. And this is the truth of modern web development. Is there any rumblings of a new killer framework on the horizon, anything people should be looking at? Not a whole lot on the JavaScript side. So Dart, which I mentioned, it's kind of in between what you consider JavaScript and what you consider like cross-compiled. So Google has a program language called Dart, and that's what you build Flutter apps with. And it is native, in a way, for Android it is native because you're building things from the scratch and they have rebuilt all of Android UI in Dart for iOS, you're kind of painting pixels with Skiasharp. But I mean, if you think Dart is kind of leaning towards JavaScript, then I mean, that's a very upcoming way of building mobile apps. But otherwise, the tooling is top-notch. A few things that the JavaScript native things can get away with is you can refresh part of your app without going through the app store all the time. So those are things that it's good at. And then the tooling is cross-platform, like I said, Windows or Mac, it doesn't make a difference. And your story of code sharing between web and mobile is very, very good. Dev Ops support, is it as good as for what? Yeah, so the good thing is Microsoft has over time kind of consolidated all of the Dev Ops stories. And Dev Ops is hard for mobile. It's not just ship and forget. It's like, how do you distribute? How do you get crash analytics? How are you figuring out how much people are spending on a screen or how many times they are clicking on a button? So for me, again, there are solutions out there, but I really like the Microsoft story of Visual Studio App Center. It is one thing that does everything for you under the roof, and it works for both JavaScript and .NET side. So any of these things will work just fine with VS App Center. You can distribute to an enterprise. You can do on-device testing. So especially if you're doing Android, you can't deploy to every Android device. There's just too many out there. So let them have the app package that will deploy to small screens and give you screenshots. So I think the Dev Ops story is hard to do everything by hand. So go to a cloud provider if you can for both JavaScript and native. I think Visual Studio App Center is really good. Cool, yeah. And then the cross-compile things, a lot of things are happening, which is good. Xamarin, I think is a very mature stack for .NET developers. It's been the preferred way of taking your apps cross-platform. What has happened in the last couple of years is since Xamarin was open sourced and became a part of Microsoft, it's gotten a lot more love from the community. So when you write, especially in Xamarin Forms, when you write an abstracted UI, Xamarin turns around and renders native UI on iOS or Android. And the way they do that is through something called renderers, which is what renders the native UI. So the community has stepped up and we have now written renders for other platforms. So the Xamarin Forms code that you write runs not just on iOS or Android, but on a Mac, but also on GTK Linux and also on the web. And you can style your XAML with CSS. This is kind of old news, coming from Xamarin Forms 3.0 days. Xamarin Forms had a 4.0 release, which was pretty big. One of the things that Xamarin, I felt, was a little behind compared to other frameworks was that dev cycle. It was a little slow. You write some code and you either hit F5, it takes a while to run in your emulator. They did a preview or thing which was nice because you could not run the app. You could kind of see the UI in Visual Studio. As of Xamarin Forms 4.0, they have a very hot new feature called hot reload, where you can actually literally write some XAML and your app is running in the emulator. It just picks up that one page and just shows you the refresh, which is very, very nice. And a lot of Xamarin developers have been looking for this for a while, so that's a very good development. Right, so that's a great feature to have, given that we don't really have XAML designers, right? Yeah, back in the blend days. And you can kind of see both ways, like maybe some of those tools were a little too heavy handed for what you're trying to do in Xamarin. So yes, we never really have had a Xamarin designer in Xamarin Forms, and maybe people have asked for it. Well, now at least you can see your code running. The moment you edit Xaml, you can see it running. And there are other things that the Xamarin Forms teams, Xamarin teams have done. You might want to have your app be styled by one of these common design paradigms, like cappuccino theme or material theme, right? So you used to have to kind of put in a lot more effort nowadays, or prior to this release, but now there are Xamarin Forms visuals, which is kind of a structured way of, kind of adhering to a theme all throughout. There's a whole concept of Xamarin Forms shell, which is optional, but most mobile apps end up being similar. There are multiple pages, and there is some navigation connecting it. So the shell kind of gives you a one-stop shop from starting at a place where it has some navigation built in, a slide view, or like little icons, tabs at the bottom. So you can start from a very good place. So these are some very good enhancements that has happened to Xamarin Stack in the last couple of months, and all of them kind of add to the productivity side of being a Xamarin developer. Cool. And then other things are coming along, like you mentioned WebAssembly, Uno is a platform or a framework that does UWP XAML. If you didn't want to write Xamarin Forms XAML, which is kind of cater for mobile devices, if you rather write UWP XAML, then you can do Uno platform, which runs on top of Mono. So same architecture as Xamarin, but their renderers will take UWP XAML and push it out to iOS and Android. But one thing they have done quite well is WebAssembly support. So again, this is all new. Frank Kruger, he's a local gentleman here. He has a framework called UWI. So there are multiple ways in which you are bringing XAML back to the web browser. Still early days, but it's exciting if you have ever done it in silver light. So yeah, that's the state of where we are. All right, cool, awesome. So in 20 minutes, perfect. A lot of stuff. A very good overview of where we're at. Thanks so much for coming on and doing this. Yeah, thank you. And again, I think it's good to have choice as a developer, look into what else you are doing. And the good news is no matter what you pick, you have very mature tools and you have full API access. And again, the story keeps getting better in every stack. So yeah, thanks for having me to kind of come out and do a quick informal chat. This is fun. Thank you. Hope you enjoyed that and we will see you next time on Visual Studio Toolbox.