I wanted to write down what I think the reasons are here in December of 2021 so that we might revisit it from time to time in the future and see if these reasons are still relevant. I’m a web guy myself, so I’m interested in seeing how the web can evolve to mitigate these concerns.
I’m exclusively focusing on reasons a native app might either be a distinct advantage or at least feel like an advantage compared to a website. Nothing subjective here, like “it’s faster to develop on” or “native apps are more intuitive” or the like, which are too subjective to quantify. I’m also not getting into reasons where the web has the advantage. But in case you are unsure, there are many: it’s an open standardized platform, it will outlast closed systems, it strongly values backward compatibility, anybody can build for the web, it runs cross-platform, and heck, URLs alone are reason enough to go web-first. But that’s not to say native apps don’t have some extremely compelling things they offer, hence this post.
Because they get an icon on the home screen of the device.
It’s a mindshare thing. You pick up your phone, the icon is staring you in the face, begging to be opened. A widely cited report from a few years back suggests 90% of phone usage is in apps (as opposed to a mobile web browser), even though there is plenty of acknowledged gray area there. So, theoretically, you get to be part of that 90% if you make an app rather than being booted into the sad 10% zone.
If reach is the top concern, it seems like the best play is having both a web app and a native app. That way, you’re benefitting from the share-ability and search-ability that URLs give you, along with a strong presence on the device.
Looking at my own phone’s home screen, the vast majority of the apps are both native and web apps: Google Calendar, AccuWeather, Google Maps, Spotify, Notion, Front, Pocket Casts, Instagram, Discord, Twitter, GitHub, Slack, and Gmail. That’s a lot of big players doing it both ways.
Potential Solution: Both iOS and Android have “Add to Home Screen” options for websites. It’s just a fairly “buried” feature and it’s unlikely all that many people use it. Chrome on Android goes a step further, offering a Native App Install Prompt for apps for Progressive Web App (PWA) websites that meet a handful of extra criteria, like the site has been interacted with for at least 30 seconds. Native App Install Prompts are a big tool that levels this playing field, and it would be ideal to see Apple support PWAs better and offer this. There isn’t that much we can do as website authors; we wait and hope mobile operating systems make it better. There is also the whole world of software tools where what you build can be delivered both as a web app and native app, like Flutter.
Because they launch fast.
Native apps have a bunch of the resources required to run the app locally meaning they don’t need to get them from the network when opened.
Potential Solution: This is only partially true, to begin with. When you download the app, you’re downloading the resources just like the web does. The web caches resources by default, and has more advanced caching available through Service Workers. PWAs are competitive here. Native apps aren’t automatically faster.
Because it’s harder for users to block ads and easier to collect data.
There are all sorts of ad blockers for mobile.
iOS Ad Blockers
Android Ad Blockers
But those work only in mobile web browsers, not native apps. If you’d like to block ads in native apps… too bad, I guess? If the point of the thing you are building is to show ads or track users, well, I guess you’ll do better with a native app, assuming you can get the same kind of traffic to it as you can a website (which is questionable).
I’m hesitant to put “because native apps are more secure” as a reason on this list because of the fact that, as a user, you have so little control over how resources load that it doesn’t feel like an increased security risk to me. But the fact that native apps typically go through an approval process before they are available in an app store does offer some degree of protection that the web doesn’t have.
Potential Solution: Allow ad/tracker blocking apps to work with native apps.
Because users stay logged in.
This is a big one! Once you’re logged in to a native app, you tend to stay logged in until you specifically log out, or a special event happens like you change your password on another device. Web apps seem to lose login status far more often than one might like, and that adds to a subconscious feeling about the app. For iOS specifically, client-side cookies are capped at 7 days.
When I open my native Twitter app, it just opens and it’s ready to use. If I thought there was a 30% chance I’d have to log in, I’m sure I’d use it far less. (And hey, that might be a good thing, but a business sure won’t think so.)
There is also a somewhat awkward thing with web apps in that, even if you’re logged in on your mobile devices primary browser, you won’t necessarily be logged into some other app’s in-app browser context — whereas, with native apps, they often intercept links and always open in the native app context.
Potential Solution: There isn’t any amazing solution here. It’s largely just trickery. For example, long cookie expiration dates (six months is about what you can get if you’re lucky, I hear). Or you can do a thing where you keep a JSON Web Token (JWT) in storage and do a rolling re-auth on it behind the scenes. There are some other solutions in this thread, many of which are a bit above my head. Making the log in experience easier is also a thing, like using oAuth or magic email links, but it’s just not the same as that “always logged in” feeling. Maybe smart browser people can think of something.
Because the apps can have that “native feel.”
Typically meaning: fast and smooth, but also that they look the way other apps on that platform look and feel. For example, Apple offers SwiftUI which is specifically for building native apps using pre-built componentry that looks Apple-y. Replicating all that on the web is going to be hard. You have to work your ass off to make it as good as what you get “for free” with something like SwiftUI.
Potential Solution: Mobile platform creators could offer UI kits that bring the design language of that mobile platform to the web. That’s largely what Google has done with Material, although the web version of it isn’t ready to use yet and is just considered a “planned” release.
Because they aren’t sharing a virtual space with competitors a tap away.
There is a sentiment that a web browser is just the wild west as you aren’t in control of where your users can run off to. If they are in your native app, good, that’s where you want them. If they are in a web browser, you’re sharing turf with untold other apps rather than keeping them on your holy ground.
Potential Solution: Get over it. Trying to hide the fact that competitors exist isn’t a good business strategy. The strength of the web is being able to hop around on a shared, standardized, open platform.
Because they get the full feature set of APIs.
All the web can hope for is the same API access as native apps have. For example, access to a camera, photos, GPS, push notifications, contacts, etc. Native apps get the APIs first, then if we’re lucky, years later, we get some kind of access on the web.
Developers might literally be forced into a native app if a crucial API is missing on the web.
One big example is push notifications. Are they generally annoying? Yes, but it’s a heavily used API and often a business requirement. And it makes plenty of sense for lots of apps (“Your turn is coming up in 500 feet,” “Your driver is here,” “Your baggage will be arriving on carousel 9,” etc.). If it’s crucial your app has good push notifications, the web isn’t an option for your app on iOS.
Potential Solution: The web should have feature parity with device APIs and new APIs should launch for both simultaneously.
Because there is an app store.
This is about discoverability. Being the one-and-only app store on a platform means you potentially get eyeballs on your app for free. If you make the best Skee-Ball game for a platform, there is a decent chance that you get good reviews and end up a top search for “Skee-Ball” in that app store, gaining you the majority share of whatever that niche market is. That’s an appealing prospect for a developer. The sea is much larger on the web, not to mention that SEO is a harder game to play and both advertising and marketing are expensive. A developer might pick a native app just because you can be a bigger fish right out of the gate than you can on the web.
And yet, if you build an app for listening to music, you’ll never beat out the major players, especially when the makers of the platform have their own apps to compete with. The web just might offer better opportunities for apps in highly competitive markets because of the wider potential audience.
Potential Solution: Allow web apps into app stores.
Because offline support is more straightforward.
The only offline capability on the web at all is via Service Workers. They are really cool, but I might argue that they aren’t particularly easy to implement, especially if the plan is using them to offer truly offline experiences for a web app that otherwise heavily relies on the network.
Native apps are less reliant on the network for everything. The core assets that make the app work are already available locally. So if a native app doesn’t need the network (say, a game), it works offline just fine. Even if it does need the network to be at its best, having your last-saved data available seems like a typical approach that many apps take.
Potential Solution: Make building offline web apps easier.
Podcast on this subject
ShopTalk 497: The State of Native Apps and Web Apps in 2022 with Thomas Steiner
I’m a web guy and I feel like building for the web is the smart play for the vast majority of “app” situations. But I gotta admit the list of reasons for a business to go for a native app is thick enough right now that it’s no surprise that many of them do. The most successful seem to do both, despite the extreme cost of maintaining both. Like responsive design was successful in preventing us from having to build multiple versions of a website, I hope this complex situation moves in the direction of having websites be the obvious and only choice for any type of app.
I think this would be extra interesting to see with some data on how many developers develop for apps, and how many develop for the web.
Second, what would be the cost if you develop for the web vs developing for native apps? How much would you need to invest to get started, hardware & all?
I think you don‘t see that often enough, the true cost comparison of the before & after the fact. Because I didn‘t even take into account the fact you need to know everything about all thos platforms tbw too.
So how would you distribute risk on sticking with either if you look at the distribution of said iOS and Android developers, Windows often neglected but there.
I would say another reason would be dependable storage/easy access to the file system. IndexedDB can save data for a website, but all browsers handle the longevity of that data differently. There’s no guarantee that your offline data is permanent with the web.
As far as Material Design, there is a production ready framework available for Angular: https://material.angular.io/ It has an Android feel to it with FAB buttons, etc.
Thanks for sharing, that Angular Material looks pretty decent from a quick look. The tree component is impressive.
Don’t forget control: no one can limit, moderate, reject your web app because it completes with their business model.
Another one: you can ship your web app with a native wrapper to an app store to get (more) of the best of both worlds.
A small sidenote there is a “adblocker”/firewall that is actually blocking (Not all) in-app adds: LockDown: and it’s free!
Don’t forget we are reading this article from website not from app
I don’t know if it is possible or wanted that web apps and installed apps will share the same access permissions and the same limits. Installing an app represents user choice, to make a certain service closer, more accessible, having direct access to their device’s resources.
I bet there will be a time that the exact same code will run the web app and the device app, yet you will have an “install” option. And bussinesses may offer some “PRO” features to the installed app, not because those features require it but because they want to enocurage you to choose their app for your selected list.
There is one overlooked issue, which is most people tend to have their first few screens on a phone filled with their most used apps, such as FB, IG, Google apps etc. I have installed plenty of web apps but they often get forgotten and lost. Or they end up in a home page folder which is rarely opened.
I am surprised you have an iPhone Chris, you are missing out on Termux and KDE Connect (now in beta testing on Apple Flight Test). Termux is amazing for web dev on a phone!
Thanks for an interesting post, lots to look into and think about, much appreciated.
I mean, there are hybrid platforms like Capacitor that let you build code once and deploy cross platform, and let you bridge into the native layer as needed…
I think its important to consider a few things that seems to be forgotten when making choices like this:
It is really hard to get people to download an app to their phone. And even if you manage to convince them to do so, studies has shown that people really only use a handfull of them, the rest just lies there idle (which often results in the always logged-in argument to fail).
In addition, managing the apps in app-stores creates an overhead that is often forgotten.
The main reason why I as a developer would rather make a native app than a web app is probably the same reason why I would actually sometimes choose to go web app. The reason is Apple. More about it in a moment.
The main advantage of going web first is that you immediately have a product compatible with any platform.
The main drawback for webapps though and the reason I would love to go native, is that each browser implement their engine differently. Each interpret that html and css code in a different way and I don’t want to be that guy, but I can’t help it, Apple devices are where the web breaks the most in my experience. The reason isn’t their technology, which is honestly good stuff.
The reason is that they are kind of dicks towards developers. If I want to test a webpage on an Apple device before making it accessible from the internet, I need to either own the apple device I’m trying to test it into physically (and all sorts of trickery goes on for being able to debug a page on an iPhone for instance if my PC is a Windows machine) because you can’t have an iOS emulator running outside of an Apple device, or own a Mac PC, which defeats the purpose of why I would go web first as a developer.
If I own a Mac, I might as well develop a native app for their platform. Since I don’t own a Mac, I go web first, but I still have literally zero ways to test my product in an apple product before release, unless I buy one just for that, which isn’t in my plans.
The most important reason: web apps suck.
I say this as someone with more than 20 years of web developer experience and more than 10 years of iOS developer experience.
Stop being “the web guy”. If the only tool you have is a hammer, you tend to treat every problem as a nail.
Native is vastly superior in both developer and user experience. The only advantage for “the web guys” is that there is less to learn (except that there is still is). And who has a time to learn anything, when there is a new framework around the corner, right?
So if you are lazy and want to push the same half-backed crap across all the platforms, please, use web tech, which was never intended for apps, and which is still looking how to solve problems that had solutions on day 1 with SDK.
If you actually care about your UX, learn native.
Yes, anybody can build for the web. And it shows.
You succeeded in being super rude without making a single point.
native? make it “store distributed” as barely any app is native, especially ones that easily could be a website are built using Cordova-like technologies and basically displaying a website, often downloaded on demand (to allow updates skipping the store)