To App or Not: When to Choose Native or Web

Rate this content

In today's landscape, deciding between building a native app or a web app can significantly impact your project's success and user experience. As technology advances and user expectations continue to evolve, the decision-making process becomes increasingly complex. Let's dive into the key considerations that can help you determine what is right for you, a native app or a web app. We'll also look at real-world examples of apps and examine the reasons behind their choice of development approach.

23 min
12 Dec, 2023

AI Generated Video Summary

The Talk discusses the choice between building native or web apps for software development. It explores the benefits of building web apps, such as fast development, easy debugging, and universal rendering. It also highlights the power of native apps, with their advanced features, better offline experience, and monetization opportunities. The Talk suggests using libraries like Capacitor or React Native to combine the benefits of both web and native apps.

1. Introduction and App Distribution

Short description:

I have an opportunity for you all to join me in building the latest and greatest product. It includes a compelling UI library and AI for contextual information. I need help figuring out the best way to distribute it as there are multiple paths to choose from. Should we build a native app or a web app?

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.

2. The First App and Native vs. Web

Short description:

This is the story of the first app I built in 2012. It was a time when mobile apps were necessary to be taken seriously as a company. As a web developer, I had to learn Xcode and deal with low-level languages. Android development was also challenging at the time. However, both iOS and Android have come a long way since then. I questioned why we didn't just build a web app, but that was the time of native apps.

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.

3. Building a Web App

Short description:

The web has improved over time, with automated builds and deployments. As developers, we often debate whether to build a mobile or web app. Let's explore the benefits of building a web app. With HTML, CSS, and JavaScript as core building blocks, we can create compelling experiences. The web's component-based model and built-in functionality eliminate the need for additional libraries. Development on the web is fast, allowing instant changes and easy debugging. The web is universal, rendering on various devices and platforms. It offers powerful features like WebRTC, push notifications, USB, and NFC.

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.

4. Web Development Benefits

Short description:

Not only does the web provide powerful and performant features, but it also offers a fun and enjoyable development experience. Building for the web allows developers to have fun with CSS, work with the latest JavaScript frameworks, and explore the future potential of the web. These features make the web a super compelling platform.

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.

5. The Power of Native

Short description:

Native devices have powerful features that are far ahead of what we can do in JavaScript. They ship a single binary that holds all the knowledge of the app, making it more performant. Native apps are resilient to network changes and provide a better offline experience. They have low-level device features and a clear permission model for users.

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.

6. Native Apps vs. Web Apps

Short description:

Native apps have better discoverability and monetization opportunities compared to web apps. Native apps can be easily found and downloaded from app stores, while web apps rely on search engine rankings. Native apps allow developers to charge for their apps or offer in-app purchases, providing more opportunities to monetize their work. On the other hand, web apps often rely on third-party ads or direct support from users. However, it is possible to combine the benefits of the web and native apps using libraries that enhance web apps with additional functionality and platform access.

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.

7. Building Web and Native Apps

Short description:

Capacitor and React Native allow developers to create both web and Native apps, reaching more users and getting the best of both worlds. Choose the web for familiar languages, fast development, and ubiquitous deployment. Choose Native for resilience to network changes, access to rich features, and a good monetization model. To combine the benefits, use Capacitor or React Native to leverage existing web knowledge and build a better product.

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, 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.