To App or Not: When to Choose Native or Web

Okay, I only have like 20-ish minutes but I have an opportunity for you all and I would like to invite you to join me. So I'm building the latest and greatest product these days. It's got a compelling UI library that I personally know and love. It includes a bunch of AI in there so that way we can provide contextual information to all of our users. I gotta figure out the last part but it's something to do with how we can get that app out to everybody. And that's the part I'd like to actually invite you to help me figure out. What is the best way to distribute this? Really at the end of the day I want to make sure that this app is available to everybody. It's a really really difficult thing to figure out because there's multiple distribution paths to how you can ship an app and which path you choose is going to influence how you actually go ahead and build the app. So let's go ahead and try to walk through this process. We're going to figure out if we should app or not, whether or not we should ship this app as a native app or as a web app.

I'm Mike Hardington, I work at a company called Ionic. You can find me basically everywhere online as mhardington.

Before we do that though, let's take a trip back to the very first app I ever built. This is an app, don't worry, logos, company names have been kind of obfuscated a bit. But this was an app I built circa 2012. It was a very interesting time in that space, there was this is pre iOS 7, so we're still dealing with some of this blocky skeuomorphism. But what we do have is an app that was loading a bunch of content from a remote service. We're pulling in images, we're pulling in product descriptions. I mean, we're even pulling in some of the styles that were used in that product because this app was built using a app shell and loading up HTML, CSS and JavaScript. This was truly just like cutting edge at the time, but it allowed us to build out this whole entire product demo that we could then go ahead and distribute to all of our salespeople and all of our technical trainers and give them the information they need right on their device.

Now the questions that I had was, well, if we're pulling in all of this web content, why do we need a mobile app? And at the time, the general consensus was, well, you need an app to become a serious company. And that was the end of the discussion. That was easy enough for the head of the company to say, but me, as a lowly web developer, one of the things that I had to deal with was learning Xcode. And this was truly the time when Xcode looked like iTunes. There was a lot of Objective C, even C, C++, like really, really low level stuff. And this is that, as a JavaScript developer, I was not well equipped to handle this. I basically stumbled my way through it. Thankfully, times have kind of evolved since then where we have a much nicer-looking IDE for iOS development, but also we have better languages that are more approachable for people coming from non-low level system languages.

Android was not as great as, well, we didn't even have an IDE at the time. We were using things like Eclipse with the Android SDK plugin enabled so that way we could go ahead and do some Android development. This was not the great Android development of Kotlin. We were still writing Java. We were still dealing with some of these antiquated approaches to building Android apps and doing things for Android pre 4.0 was pretty challenging. Thankfully, like iOS, Android has also come a long way, where the Java that we do write is actually much more familiar to people who have done JavaScript now and TypeScript, and the IDE is, if you've used any IntelliJ product, it is going to be the same IDE, because it is based off of all of their core editor experience.

But again, I kept pushing for, why don't we just do this as a web app? This is the time of the web, right? Everything's gonna be great. I didn't need to build and deploy up my web app. I just needed to bundle all my scripts together and then bring up the FTP client. I had my credentials. I knew where the folder was on my desktop. I could just drag it over to our hosting provider, upload it, and we're done, right? And that was 2012.

And, you know, it's only gotten better for the web, where now, instead of having to deal with FTP, we can just go ahead and run a commit and push it up to our main Git service and then trigger a bunch of actions, whether or not we are using something like CircleCI, GitHub Actions. All of our builds and our deployments can be automated, so that way, as soon as we push Netlify, Vercel, Firebase, what have you, can pick up those changes and handle everything else for us.

So, it's easy to see that all of those three platforms, Android, iOS, and even the web, have gotten a lot better over the times. And we still have this eternal question as developers, you know, should we build a mobile app or not? Should we build a web app or not? And I want to walk through some of the pros and cons of each of these platforms. I'm a longtime fan of the web so I will try not to be so biased towards it, but there's a lot of great capabilities from both of these platforms that we should really consider as we start to build out our products.

So, let's take a look at the web and what we get when we decide we want to build a web app. Well, first and foremost, we have to mention the languages that we are using on the web. HTML, CSS, and JavaScript. These are the core fundamentals for building a web app that really help us build amazing and compelling things. Yes, we can bring in things like React or Next, but if for whatever reason, React and Next were to go away, we'd still have these core building blocks that we could utilize and build pretty compelling things. I know folks are still on the fence about web components, but once you start building things in a component-based model using built-in functionality from the browser and JavaScript, you pretty much look at this and say, huh, what is the reason for bringing in all these other libraries? The web is a pretty compelling platform in that case.

And the languages that we know for building these features and these UI are also compelling. With those tools and these languages kind of in our skill set, our ability to build something on the web is incredibly fast. Compared to what we can do in native, we're not spending a whole lot of time with this build, compile lifecycle. We are literally opening up our dev server and then we can see the changes happening in our app instantly on the client. Which is super valuable. The ability to be able to inspect everything right in the environment that it is actually going to be deployed in, and actually look at all of those nodes, means that we're spending less time having to debug the actual app itself and more time just figuring out, how are we building the layout? Why is this style not being applied? Where can I make some changes to optimize it for usability? Our ability to take all of the stuff and just iterate and iterate really quickly, cannot be undersold.

Now, this may look like the USB symbol, but this is actually the symbol for universal. At least in my headcanon. The ability to be able to take something for the web and deploy it, is pretty universal. I can only think of maybe a handful of devices that actually cannot render web content. Where as I can think of so many places where web content can be rendered. Obviously, we have our desktop environments, we have our mobile browsers, but we also have payment kiosks. We also have the control center for NASA. They are all using web technologies to actually render out the UI. Because it is so fast, because it is universal, because it is things that they all know, and can be able to be productive really quickly.

Moving on with that, we have things like, we have powerful features inside of the web that allow us to build better apps than we have ever been able to. If we take a look at some of the features on what the web can do, you can show us that obviously we can do things like WebRTC, we can do some push notifications, we can do USB and NFC, all these cool features that are baked into the browser that the native devs have always kind of hung over our heads as, oh, the web will never be able to do this. But the web is a story of always being able to catch up. And with those features, we're seeing that the web can be pushed forward to do new and incredible things.

And not only do it in a way that gives us powerful features, but do it in a way that's going to give us very performant features. We're going to be conscious about the energy footprint about what we build. We're not going to be shipping things that prove to be able to reduce the user's battery their device. As well as their desktop. Because we're just not going to do that. It's just a bad experience for users.

And probably, you know, my favorite feature of the web is that it's just fun. It's not necessarily something that you can use as a measurable effect. But I find building for the web just an enjoyable experience. I mention it because if you're having a good time actually building for the platform you're on, you're going to actually care about it. You're actually going to want to build for that platform. We've heard of things like used in anger or used in frustration. I like to think that the web allows me to build and use a web with enjoyment. I'm having fun dealing with CSS. I'm having fun working with the latest JavaScript frameworks. I'm having fun being able to see what the future of the web can bring and how can I take advantage of that now. For me, all these features really make the web a super compelling platform.

But we'd be remiss if we don't talk about the amazing abilities of native. Now, native devices have always had a core feature set that really stand out from what we do in the web. First and foremost, they're powerful features. There is a really interesting cross-section when you see the environment that these devices run in, the languages that are used on these devices, and then the people who build them and basically own them. They're able to make a lot of assumptions about your code. That way, by the time you actually hit Build, they're doing things far, light years ahead of what we can do in JavaScript right now. Code elimination, being able to do rewrites to make sure that it's more performant, optimizations and minifications.

Then, at the end of the day, when they are building that app, they're not shipping a bunch of files that need to be loaded up and fetched. They're shipping one binary, which is incredible, meaning that we're not having to have all of this extra fluff, we just have a single binary that holds all of the knowledge of our app. And, really, that's it. The optimization aspect of these build chains cannot be undersold. You can write really, really bad Swift in Java, and then the optimizer is going to come in there and actually make sure that it's turned a little bit more performant. Which is really, really nice, especially if you don't know what you're doing, like me.

Native apps tend to be a little bit more resilient towards network changes. If you've ever tried to load up a native app when you have no Wi-Fi, no cellular network, you're still going to get a snapshot of whatever the last state of your app was, and you're still going to be able to say, if you're on Twitter, you could scroll up and down, see some of the tweets that people have posted, profile photos. You might not be able to go into details and interact with said tweets, but you still get something better than what you have in the web. Now, the web does have things like service workers, which allow you to cache all your assets and responses and be able to show your users something when the app is offline. But the thing about that is that you need to be able to cache some of that before your app actually is able to show an offline mode. With native, you actually are able to download an app, turn off Wi-Fi, turn off cellular, open up the app, and you're still going to get some UI that can be shown. It doesn't have to phone home to some network to download some assets. It has everything already installed. You have the main app screen that people are going to see to log in. You have all of the tab bar logic, all of the UI that is going to be represented to your users, because again, we're compiling it all down to one binary, and we're shipping that to the users, not a whole bunch of separate JavaScript files.

Native also has the advantage in being able to get a lot of low level device features, things like Bluetooth, NFC, more refined geolocation, and file system access. These are things that the web are trying to get today, and if you've been following along with some of the features that are trying to be shipped in the browser, it's a pretty contentious conversations that are being had. A lot of this is being led by folks who fly under a certain browser flag. While the step towards progress is great, they are missing out on a lot of features and alienating a lot of other browsers and browser vendors. Compare that to native, which has all these features and then actually is able to provide a permissions management system so that way users know exactly why the device is asking to be able to connect to things on Bluetooth, be able to connect to things on NFC, or on your local network, or even store data onto the file system. There's a permission model that does not exist on the web that is clear to the users, and developers have the ability to provide meaningful descriptions. If it comes to find out that a developer is doing some nefarious action, their app can be terminated.

There's a safety in the fact that we are giving privileged access to those features that the stores and the platform providers are able to protect the users from, which is really, really, really nice. In addition to that, Native also has a little bit of a better discoverability story. Now, discoverability can mean a lot of things. It can mean just, hey, here's the link to the app, go ahead and click on it and it automatically downloads it for you from the store. Or it can just mean going into the store and being able to search for the app that you want and the store is being like, we got you, no need to provide any more, here are the search hints, here's the app that you want. Compare this to the web discoverability. People actually have to know what they're looking for by being able to search for it through various search engines. And if you haven't played really good SEO games, you're not going to rank well. We have to play the ranking game inside of these search engines. Otherwise, we're just not going to be available. You could be third fourth fifth, you could be all the way on the dreaded page two of your search results. And if you're not first, you're last. So discoverability for native apps tends to be a little bit better. And I think the thing that's the most important monetization. I don't like to talk about monetization too much because you know, it's it's a very sensitive subject for for folks, but building a native app actually gives you more opportunities to monetize your work. Whereas the web, one of the common ways to monetize your work is with ads. You can actually charge for your app on the App Store, 99 cents, $1.99, $4.99 I've seen it where people actually want up, people actually see the amount of value you provide and are encouraged to pay for it. And if that's not your way of working, you could provide a free version of your app and then add on features using in-app purchases. Now you do have to pay a little bit of a tax to the platforms, both Google and Apple. But you still have a chance to be able to recoup some money on the time and effort you put into building your product versus a web where, yeah, you got third-party ads. No one really likes them. You have ad blockers. It's really not a great story unless somebody is directly supporting you through, you know, Patreon or other sorts of direct creator monetization models. The web does not succeed here. Native actually does a pretty good job with this. So we come back to the question. There's a lot of goods from both sides. Is there any way we can kind of combine those two to create the benefits of the web but with the capabilities, the reach, the platform security, and the extra efforts and niceties of Native? Well, yeah, there's ways we can do this. There's libraries out there that exist today that allow you to take, say, your simple React app, provide some extra functionality through extra libraries where you can say, hey, I want to have access to a file system. I want to be able to deploy this to iOS, to Android.

And on here, we can see that we're just calling file system.makdir, file system.readdir. We're even able to hook into those permission models using file system.request.permissions. Now, this is something using a library called Capacitor. It allows you to take your web app, be able to package it as a Native app, and still have access to all the Native project configuration and Native code that you could add in addition to whatever you're doing in the web.

And I'd be remiss if I didn't mention stuff like React Native, where you can take your existing Native app and start to sprinkle in some of that React code as well. Now, both of these options allow developers to create not only a web app but also a Native app and be able to reach more users and get the best of both worlds.

So, how do we break this down again? We're going to pick the web if we want familiar languages, a very fast development environment, and a kind of common, ubiquitous approach to being able to deploy and load that app everywhere. Well, we're going to also pick Native if we want something that's resilient to network changes, having access to rich features like Bluetooth and NFC, and if we want to have a good monetization model. But if we want the best of both worlds, we're going to want to reach for something like Capacitor or React Native, where we can take our existing web knowledge, and actually go ahead and load all of that and build a better product.

Now, I'm biased because I do work on some of the stuff inside of Capacitor, and I would highly encourage you to check it out. If you go to CapacitorJS.com, you can check out how easy it is to adopt Capacitor into your existing projects without having to go through any migration or bug fixing. Evaluation of your existing libraries. You can just drop it in there, and you're off to the races. So with that, I think I have a good idea of how I want to build my app, so I would encourage all of you to go forth and build really cool stuff. I'm curious to see what you all build, and best of luck out there.