Why Native Apps Really aren't doomed: let's talk facts
I've recently read a blog post by Eric Elliott. The title of that post was Why Native Apps Really are Doomed. As you can imagine from its clickbaity title, the author postulates that mobile native apps are essentially doomed to disappear in favour of the new kid on the block, PWAs. I beg to differ.
A PWA, or Progressive Web Application, is a website that uses the more or less recent Web technologies that allow it to approximate the behaviour of a native application, but inside the browser. Examples of such technologies are Service Workers, that allow background processing and "always on" apps; Web Push, that allow web apps to react to push notifications; local storage; and so on.
I am not sure if and how this context actually influenced the author's perspective, but I think it's important to understand where ideas originate, especially when they are claiming "X is dead", or "Y considered harmful".
Since I like to be upfront, full disclosure here: I'm a mobile "native" developer (in Eric Elliotts' terms, even though the apps I develop run in a VM) by trade and a Google Developer Expert on Android. I work in a mobile agency, Novoda, but what I write here is in no way expression of the company’s stance, or written on behalf of the company. It’s my personal opinion on the matter.
I'll try to be as unbiased as I can in my analysis here, but please do forgive me if something slips through the cracks. I’ll be happy to amend things that might prove inexact or subjective.
What is the thesis?
This post is actually a follow-up to another post, Native Apps Are Doomed by the same author, after he found many people contested his original stance. It's particularly interesting that this is a follow-up to his first post; its goal is to "bring the facts" on why native apps are effectively on the verge of extinction.
So, why are native apps about to disappear, according to Eric? He makes a few points:
- PWAs are write-once, run-everywhere
- By extension, PWAs are dirt cheap and native apps are prohibitively expensive to build
- Native apps have massive friction, because:
- People don't install apps
- When they do install apps, they only install the well established brands' apps (Facebook, ...)
- You can only monetise with IAPs, and you have to give a cut to Apple or Google
- Yes, iOS is missing some crucial tech for PWAs such as Service Workers, but there are alternatives
- Discovery on the web is massively better than in app stores
The post is a great read, but I disagree with some of those points.
The reason why I don't agree that this is a "real thing" could be summarised by this:
Sure, you can technically write a PWA and it should theoretically "just work" across any OS and browser, just like that. The same goes for Java, as Oracle is so keen to remind everyone that installs the JDK. Or, for that matter, Xamarin/Mono's .Net. Or Cordova, Titanium, PhoneGap, and any other HTML5/JS/CSS-based framework out there. Or, heck, the Web itself.
That is the theory. Things in the real world pan out a bit differently. Have you ever heard of any of those frameworks being really at a "it just works" level, universally across compatible environments?
If your answer is yes, I would love to hear about your experience. It would be a first for me.
Let me elaborate a bit further. Cross-platform frameworks do work in some specific circumstances. In some cases, they're the best option you have, so you just go and run with it. That's perfectly fine. Say you are Amazon and you want a mobile app for your immense catalog of items; your best bet is to use a thin wrapper around your mobile website that adds "just enough" behaviour on top of it. The complexity and variety of the items in their catalogue would make for an incredibly complex native application. The closest example I can think of that has a similar level of complexity and is fully native is Facebook's app, which isn't the most shiny example of mobile app when it comes to performances, memory and power usage (and design, arguably). Their website is a vastly superior alternative, because it is a very well done web app.
But unless you have a great engineering team, and you invest enough to bring your web app over the "uncanny valley" of mediocre websites the way Facebook and Google do, your web app risks being worse than an equivalently mediocre native app in terms of performances and user experience. Running in a browser will have an impact on performances, if you don’t optimise, whereas native apps can get 60fps almost for free (almost). Since you can’t have a PWA without a web app, this extends to PWAs.
And that's without considering the profound differences in design and navigation patterns users are used to on Android and iOS. If you build a PWA without keeping that in mind, it will never blend in with a device. Best case scenario, you can make one platform's users comfortable. Worst case scenario, and most common case, you'll end up with a UX that doesn’t fit on any platform and alienates users.
Writing a well-done PWA is neither cheap, nor fast, nor easy. It takes the same amount of effort and care you need to build a good native experience. Sure, you might need specialised devs for each supported platform, but unless you’re doing throwaway apps, your product survival depends on it being better than the competitors, so you will need a high degree of expertise. You can’t put a web dev or designer that has never done mobile before to doing mobile and expect great results from day one. You’ll still need time, effort, specialisation, skills, and thus money. A lot of it. Browser incompatibilities and quirks won't go away any time soon. The tech powering PWAs has limitations (e.g., local storage space caps, implementation-specific JS bugs). And so on and so forth. It's a whole bag of Your Mileage May Vary, these days.
When you start saying "oh, X is not available on Y, but hey for that case you can do Z" you're running into the same fragmentation and complexity you get with supporting native apps, but without the great tools native apps provide you for dealing with that fragmentation. It's a jungle out there, and a naive "workaround all the things" approach ain't gonna cut it.
Oh, and I won't even get into making complex web apps as performant as native code. The mere fact there's more software layers a PWAs is sitting on top of, compared to a native app, means it won't be able to achieve the same performances. When comparing apples to apples, you can make web apps performant and incredibly nice experiences, but it takes a lot of effort and thus money, as mentioned. Then you’re back at square one.
For the sake of being exhaustive, I have to mention that PWAs don't have access to equivalents for a lot of a platform's native APIs. Sensors, fingerprint readers, power management, inter-app integrations (e.g., sharing to or from other apps), close-to-metal and performance critical code, are the first that come to mind. If you don't need them, great. If you do... a native app is your best shot. That is unlikely to change, at least in terms of getting a common and standardised way, in my opinion.
Friction on native apps, discovery woes
Native apps do suffer from friction issues, that much is true. But there are very interesting initiatives going on, at least on the Android side. Instant Apps, while yet to be released, will be a great way for some apps to avoid the problem altogether, since users won't even need to install the apps to be able to use them.
Before that, Google tested a more rudimentary "try before you install" technology, App Streaming, that allowed users to stream a remote device's screen with the app running in it. I'm not sure where that technology has gone nowadays, but I imagine it's being replaced by Instant Apps anyway.
On the other hand, mobile apps still manage to emerge from the mass, sometimes even without the need of crazy marketing campaigns. As a first-hand experience, I had an open source app on the Play Store that, with absolutely zero advertising effort, got to 150k+ users in a year. It was a homescreen widget, that most people don't even realise are a thing that exists on Android. I can’t really think of an example for PWAs here; this might be a symptom that discovery isn’t that easy on the web either.
The author also states that discovery is very difficult on mobile, but he seems to assert on the web it's different and you're almost guaranteed people will use your website and services. In my experience, the bias towards well known and established properties is not limited to discovery on the app stores. People will barely ever go over to the second page of Google results, when looking for something. The first search result gets ~33% of the whole traffic, in real life.
Meanwhile, native apps can take advantage of technologies such as App Invites and Dynamic Links, that allow organic recommendations and referrals from friends. Considering that half of app installs already come from a direct, personalised referral, this has a huge impact on discovery.
It's true that the majority of top grossing mobile apps rely on In App Purchases, especially on Android. But those are mostly games, in which the freemium model is pretty much the only way to go. iOS users are more affluent on average, and more inclined on paying for an app or game; Android users tend to prefer freemium.
Say you don't want ads in your app—that would give you roughly the same monetisation opportunities on native and PWAs, assuming you don't want to go rogue and have annoying, intrusive ads. Let's also say you want to go with the freemium model. You will have to give Google or Apple a cut of your IAPs, sure. But you would also get a whole lot less friction on the actual monetisation flow. The payment flows for native apps' IAPs are extremely simplified to reduce friction to the minimum. In most cases, users just need to touch their devices' fingerprint scanners. I’d like to see some real data there; I haven’t found any comparison, unfortunately.
You can get similar results on the web using things like Apple Pay and Android Pay to reduce friction, but then... you're back to giving money to Google and Apple.
And this is without even considering that those mechanisms take care of the vast majority of the payments business, keep track of who's bought what, when, keep the users' payment details, and so on. You can get some of those things with other processors such as PayPal or Stripe, but you won't get as good of a payment flow with either. If your product is primarily targeting Western markets, your users will predominantly be registered and set up with those built-in processors too. In emerging markets, you face the same challenges as people is mostly used to third party processors that tend to be tied to the local market.
It's not true you always have to use IAPs, even though there are reasons why you might want to. If your app or service sells goods or services that are available through other channels (say, a website) depending on the case the app stores might allow you to use your own payments processing, completely bypassing the fees.
Lastly, there's some interesting new ideas for monetising apps coming up, again on Android. For example, Amazon has launched Underground, a programme in which developers can publish their apps without ads and IAPs, and fully unlocked. Users will be able to download them for free. Amazon will pay the developers based on the amount of time users spend on their apps, or games. I'm not aware of any similar possibility on iOS and PWAs.
PWAs are a great thing to be excited for; it means one can have a good experience on a web app, instead of the crappy one you would've expected a couple of years ago.
New, great tech is surfacing constantly in the web landscape (even a bit too quickly, according to some). The breakneck pace means it will maybe one day catch up with the experience users can get on native.
But as of today, PWAs are not there yet. You can probably still get better results with some (semi-)native cross-platform frameworks. Web-based frameworks like Cordova in my opinion are nowadays mostly used to create cheap, “quick&dirty” apps by companies that don't care enough about their users to get them a proper experience. Their usage is thankfully in rapid decline. React-Native is nice but has its own bugs and limitations; some are turned off even by its licensing terms. Xamarin is the same (but it's nice it's OSS now). I see some potential in Flutter because it's a mobile cross-platform framework that really compiles to native code, but it's still very early days for it.
Most JS/web developers I have spoken to have very little clue what the challenges and gotchas of developing for a mobile platform are. On the other hand, most of those who do know mobile platforms wouldn't touch JS with a stick, either because of the horrible fame it built for itself over the years, or simply because it's not as good as the languages you can use with 1st party mobile SDKs, in this context. JS might work in some contexts but that doesn’t mean everybody loves it. After all JS is getting better, but it’s still that JS to many.
For as much as a nice read the article was, it felt like some sort of naïvety emerged from the author in expressing his point of view. In my opinion, the author’s statements regarding the state of PWAs are simply too optimistic. While the technology is progressing quickly, my personal experience with native development indicates that there are a lot of problems that it’s not yet close to addressing.
For as much as one might really think and hope one day we'll manage to get over "native" apps, I can't get myself to think we're even close to it right now. Sure, the article says native apps are doomed "eventually", but realistically, if it's in five to ten years...who knows what better alternative technologies might arise in that time...
I can't help but think that each tool has its own place in a developer's toolbelt. PWAs make sense in some cases; "native" (as in developed using the main language and APIs for a platform, such as Java for Android and ObjC/Swift for iOS) make sense in others; and "real-native" apps that use closer-to-metal languages such as C/C++ are sometimes the only way to go. In some cases you might get the best results with a combination of all those technologies, or maybe just some. If you’re developing an app with a short shelf life, such as a marketing app or an event app, then a PWA might actually work just fine. If you’re developing an app that is supposed to represent a long-lived product or brand (especially mobile-focused ones), or you hit any of the limitations PWAs have today, then going native is and likely will be the only way, at least in the medium term.
In conclusion: no, native apps ain't going anywhere right now. Maybe they will one day. Maybe we won't have walled gardens and proprietary APIs, maybe we won't even need to know a programming language to instruct a computing device. Who knows.
In my opinion though, with more than 65k new native apps being uploaded to the Play Store every month, and that rate increasing, native apps aren’t nearly as dead as the article would have you believe.
A huge, massive thanks to everyone that helped me out with the editing and their suggestions: Francesco, Daniele, Ryan, David, Anup, and Erik.
A note on the app stores: I find the Apple Appstore is a dreadful piece of software, and I'm absolutely not surprised that 60% of the apps on it are never installed (the video mentioned in the article is not talking about Android and the Play Store, but about iOS). ↩︎
According to AppBrain, on the Play Store only ~8% of apps use HTML5 cross-platform framework such as PhoneGap/Cordova (6.22%), Appcelerator/Titanium (0.77%), Marmalade (0.12%) and Corona (0.92%). In the top 500 apps, that shrinks to 2.89% apps using them. Even more interestingly, although 8% of the apps use them, only 2.15% of the actual installs ever includes any, meaning 73% of those apps are never installed—considerably more than native apps. ↩︎
I'm not even sure the world will not be a nuclear wasteland, by then, given the recent turn of events in some nuclear powers ↩︎
One case is the Financial Times, that left app stores in 2011 to migrate to a responsive web app to avoid paying a cut of their subscriptions to Google and Apple. They reportedly spent a lot of time and money building the website, and as of today, it's still only compatible with iOS devices. On Android, they have apparently given up and resorted to a native app instead. ↩︎