The State of Mobile Development

>>On today’s Toolbox and the time it takes our producer to
take a 20 minute walk, Sam Basu 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 Basu. 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 I guess toast ones.>>Yes.>>About a year ago.>>Yeah.>>Yeah.>>Yeah. We love your show.>>The theme is hour-long
Blazer episode.>>Yeah, and then things have come
a long way, and there’s a land, but glad we could talk about
Blazer way back in the days.>>Things have come a
long way in many lands, and when I thought we would do today is apply that lands 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, in 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. Don’t sit too far back.>>All right.>>Sit back and just review
the state of mobile development.>>Sure. So informal chat
between developers.>>Yes.>>So you look 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 the 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, which technology you pick does not dictate the type of app you
can build. It’s all the same.>>Okay.>>Despite the complexity, there’s actually some clarity. If you want to do.Net,
here are your options. If you want to do JavaScript,
here are your options.>>Right.>>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? Then we’ll go back and talk about where we’re at in
each of these fields.>>Sure. I’m sure there are more ways of building for
mobile, not just mobile apps. But these are the five
broadways 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, especially if you’re doing like games and
things like that. But it’s 2019, you’d ideally want to build
cross-platform solutions.>>Okay.>>That’s where we
look at other things. So number one in this list
is mobile web which I, sometimes considered that to
be the lowest-hanging fruit. If you have a website, it should work nicely on a mobile phone factor. There’s a lot of help in terms
of open source frameworks. There is Twitter, Bootstrap. There’s all the spa frameworks. We make Kendo UI. So your controls
should be [inaudible] zoomable and work nice to
any mobile phone factor with touch. Then the mobile web
concept you can 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 homescreen, the icon to your homescreen. You can receive push notifications. You can have some service workers. 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.>>Okay.>>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 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, and anyway, 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 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.>>Okay.>>So this is the JavaScript
in the web side 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.>>Okay.>>But if you are
somebody who has done any C# or.Net in the past or if you have other
desktop applications, then you’re looking at
the cross-compiled solutions. For that 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. This cross-compiled story
is getting more love. We see UNO platform, we see things like Flutter. So just a lot of choice. 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 types is mature enough, and
the tooling is very good.>>So which bucket
is Blazer fit into?>>So Blazer is not for
mobile technically.>>Right.>>It is going to run on WebAssembly, it’s going to run fine
on mobile web browsers, so it is cross-compiled
at this point.>>Okay.>>It is going to
run C# compiled down into through LLVM into
WebAssembly stacks. So yes, it will run. But Blazer is the way of coming to the browser with C# and
Asp.NET Razor syntax, while if you just want
to come straight. 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. 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 couple of options
and it’s still early days. But WebAssembly is really opening up a lot of different choices,
options for us.>>Okay. So I’m a mobile web slash PWA developer
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 that a user can pin an icon to my homescreen. So at this point, there
is quite a bit of help. For any of these tuning 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 I think
called PWABuilder. This was also what Microsoft put out, and it’s gotten a lot
of community loves. 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 manifest file, and here’s where you should start. Here is 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 Windows Store.
So that’s all good. Safari is lagging a little bit
behind because Apple is kind of, 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 can you see happening in
the next year in that space?>>Yeah. So since PWAs 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 Hybrid or a Native app. So all of the things like camera,
geolocation, accelerometer, these are things that
are hard to do from just pure web because of
their 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.>>Okay.>>So I think that story
needs a lot more improvement, but otherwise, the core pieces are there for PWAs to be successful.>>Okay. Cool. There’s not much to
talk about on native except for support for
new versions and new SDKs.>>Newest stuff is coming out, iOS 13 is coming out. One exciting thing with Native Land, I think it’s going to be
a game changer is at Dub-Dub DC, Apple announced that Apple has
a similar app store problem. Everybody wants to build for iOS, but not many people want to build for the Mac desktop because
that’s 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,
but it’s hard to do. So with macOS desktop and iOS 13, you should see that light
up, that story. It’ll also 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, 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.>>Hybrid, not a whole lot is new, because again, it’s
been out for a while. You might almost argue that if I’m building a hybrid app
today with JavaScript, why would I not build a native app? So again, Hybrid is
a mature platform at this point. If you go to Apache Cordova. If you pick up frameworks like Ionic, they will help you build
a nice hybrid mobile app. You do have access
to all the plug-ins, which are the little pieces
of code that gives you access to the device
sensors that 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 new.>>It’s a mature space.>>It is.>>Yet there’s not much going
on in there necessarily.>>Yeah. The last two is where you’re seeing 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 there are blurred lines here.>>Yes, of course.>>So a native app has
to have native UI, native performance, and
native access to APIs. 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 your- and all of
these things are open source. Your 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. If you’re building
websites with React, then go with React Native. So again, all of these things
are mature tool sets.>>Which ones would you call industry leading or most
popular at this point?>>They’re all about the same, it depends on what
else you are doing. If you’re doing React, then React Native is very popular. If you’re okay doing Angular, and then NativeScript
is very popular.>>Okay.>>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, and Visual Studio code
or Visual Studio, they are 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. 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 things like Webpack to 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
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. 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 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, really big projects which need
to drive products forward, you have 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 in 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, this is in-between what you consider JavaScript and what
you consider cross-compiled. Google has a programming
language called Dart, and that’s what you
build flutter apps with. It is native, in a way, for Android it is
native because you are building things from the scratch, and they have rebuilt all
of Android UI in Dart. For iOS, you’re painting
pixels with SkiaSharp. But if you think dart is
leading towards JavaScript then that’s a very upcoming way
of building mobile apps.>>Okay.>>Yeah. But otherwise, the tooling is top notch. A few of the 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. Your story of code sharing between web and mobile
is very, very good.>>DevOps support, is it is good
as for what we’re maybe used to?>>Yeah. So the good
thing is Microsoft has over time consolidated
all of the DevOps stories, and DevOps is hard for a mobile. It’s not just ship and forget. It’s 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’re picking 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 would 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, they will deploy to small screens
and then give you screenshots. So I think the DevOps 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.>>Okay. Cool.>>Then the cross-compile things, a lot of things that are
happening, which is good. Xamarin, I think is a very mature
stack for Dart developers. It’s being 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. The way they do that is through
something called Renderers, which is what renders to Native UI. So the community has stepped up, and we have now written
renderers for other platforms. So the Xamarin Forms score that you write runs not just
on iOS or Android, but on a Mac, but on
also on GDK Linux, and also on the web. You can style your XAML with CSS. This is old news, coming from Xamarin Forms 3.0 day’s. Xamarin Forms had a 4.0 release, which was a 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 awhile to
run in the emulator, they did a previewer thing
which was nice, because you could not run the app, and could you 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
on the emulator, it just picks up that one page
and just shows you the refresh, which is very, very nice. 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. You can 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 XAML 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. There are other things that
the Xamarin Forms team, Xamarin teams have done. You might want to have your app be styled by one of
these common design paradigms, like Cupertino theme
or Material theme. So I used to have to put it in a lot more effort nowadays
or prior to this release, but now there are
Xamarin Form Visuals, which is a structured way of
adhering to a theme all throughout. There is 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 gives you
a one-stop shop from starting at a place where it
has some navigation built in, a slide view or 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 add to the productivity side of
being a Xamarin developer.>>Cool.>>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 catered for mobile devices, if you’d rather write UWP XAML, then you can do Uno platform, which runs on top of models. So same architecture as a Xamarin, but their renderers will take you to 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 Krueger, he’s
a local gentleman here, he has a framework called Ooui. 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’ve ever
done it in Silverlight. So yeah, that’s the state
of where we are.>>All right. Cool. Awesome.
It’s only 20 minutes?>>Yeah.>>Perfect.>>A lot of stuff.>>A very good overview
of where we’re at. Thanks so much for
coming and doing this.>>Yeah, thank you. Again, I think it’s good to have
choice as a developer, look into what else you’re doing. 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.>>Cool.>>So yeah, thanks for having me to 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. [MUSIC]

Tags:, ,


Add a Comment

Your email address will not be published. Required fields are marked *