My day job is leading teams that build native and web versions of applications for clients, so it’s strange how much I agree with the sentiment, except for the world “replace”.
Steve Jobs’ original iPhone announcement gets brought up a lot. You don’t release an entire development platform in a couple months as a course correction. They were working on a native SDK before the first iPhone launch. The talk about developing web apps as being the primary way to develop on mobile was a bit of face saving and Jobs style misdirection since the SDK was delayed.
Native apps will never go away, because mobile platform owners can’t wait years until their hardware features are accessible through standardized web interfaces.
That said I agree that too many mobile apps out there should have been made as a website. Also many digital experiences take just seconds or minutes of interaction to be meaningful, so the overhead of App Store reviews and publishing is total overkill. About 80% of apps I have on my phone are not used daily and just taking up space.
However web apps historically have been painfully negligent in persisting user data, and lost some trust among non technical users in my experience.
I suppose devs who programmed e.g. calendar or SMS apps for "dumb phones" using assembly will scoff at today's devs using XCode/Android Studio with "fancy languages".
Everything is developing to make development easier and easier, HTML, CSS and JS is even easier, but I guess "it'll have more performance" is not the correct argument.
I (a web developer) do not find HTML/CSS/JS easier than native development tbh. It's just a lack of familiarity that pushes people to use javascript for absolutely everything (despite it being unsuitable for many of those tasks).
As a guy who makes most everything in HTML, CSS, and JS I still don't understand the logic of it will be lightweight and fast, given how many crappy things that are not lightweight and fast I see all the time in the web stack.
It'll have more performance is the correct argument, if you can prove it. But I have my strong doubts. I would make the argument on
it will be easier to develop and maintain because you will have a unified stack.
Meaning it will be cheaper.
If you increase performance in one you will probably increase performance in the other, meaning the work you do to increase performance in your website will probably translate into performance improvements in your app.
I feel the same when I see people arguing that ESP32 class processors should only be written in Assembly and C, having used high level languages on MS-DOS, Amiga and ZX Spectrum compatible hardware.
A progressive web app also includes a manifest.json file to define how the app launches when it's installed, a service worker for background operations, app icons for the user's device homescreen, etc. An HTML5 app and a PWA are similar but really they're not the same. https://developer.mozilla.org/en-US/docs/Web/Manifest
> Well, the problem with this number is that these app users spend 77% of their time on only 3 apps and even 96% of that time on their 10 favorite apps. This means that it’s extremely difficult to get users to even use your app.
This seems like something a marketing person trying to push an idea would say. There's an alternative explanation: users need just about 3 main things from their device, with extra few filling the cracks (like a bank app that's used once a week or so). If your metric to improve is "what percentage of the time is someone using your app", that sounds just wrong.
"Developers now had to use a native SDK to build an app for the iPhone."
Patently untrue. They were finally allowed to use native API, which they had noisily demanded. And they were still allowed to use the "sweet solution" of (progressive) web apps, an idea that took off like a lead balloon and whose announcement was met with cold silence.
And the alternative to native apps is not "web apps" (progressive or not), it's web sites. When engagement is not high enough to warrant installing a native app, it's not high enough for any app.
This isn't just theory either. For example, I worked on Wunderlist, and one of the major factors for its success was native apps on all major platforms, a point confirmed by the numbers and general feedback as well reiterated time and time again when talking to individual users.
This despite having a web app that absolutely rocked.
And of course there are numerous other examples, for example Facebook going back from a web app to a native one etc.
I don’t think PWA will gain the traction needed to dominate the market. Native development is still better for the most part. I also don’t believe Apple wants anything to do with PWA and the only reason they added support in 10.3 was due to the fact that they were purging their AppStore of what was effectively website apps. With Apple holding a significant share of the mobile market I can’t see the reasons why you would want to invest in a PWA when there is such a large user base with devices who don’t treat PWA as a first class citizen.
Nope. I will always choose a web experience over a native. It's just plain safer. Nothing to install on device. Less likely to have malware to track everything.
It's going to be a little tricky to define "safe" once everything goes online. Internet is getting more and more governed by a few different players. "Less likely to ... track everything" hmm.
in practice i'm pretty sure the web things i'm using are tracking me much more than any of the native apps i've ever used. I remember the outcry whenever someone would find out that $native app would send some weird packets over wireshark - and even then, it's been 10 years since windows started asking for permissions for software to open a socket so you can't really miss it if it tracks you.
Also native apps don't have ads (afaik, never saw one except windows 10's shell but then I use 99% libre software), and I can stay at version 1.5 of the native app if it works better for me while this is impossible with web apps.
> Also native apps don't have ads (afaik, never saw one except windows 10's shell but then I use 99% libre software), and I can stay at version 1.5 of the native app if it works better for me while this is impossible with web apps.
Not much of an Android user, I gather.
By the way, recent versions of Android allow apps to self update.
mobile apps outside of native Jolla ones make my blood boil faster that I can turn those wretched devices off, so, yes, I try to limit my interactions with those to a minimum.
No offense but your argument holds no water. Unless your dumb enough to root your phone then the App Store is fairly safe to use. Do you not install software on your personal computer?
> Here’s a radical idea: Why not just optimise the mobile experience of your website?
This is the most sensible bit of the article. In many smaller cases it's not really clear why the app needs to exist at all, and in some (Reddit, Instagram etc) the app is pushed so hard that it deliberately degrades the web experience.
Isn't it because app installs bypass browser privacy sandboxing? That and some marketing guy thinking that app users are "sticky" and browser visitors aren't.
"Before users can use your app you need to get them to download it first. So you will need them to:
- go to the App Store/Play Store
- search for your app
- click to install
- accept permissions
- wait for it to download
In each of these steps you can lose 20% of your potential users."
True.
Then again, when users have installed the app they need to:
1) Open it by a single tap
<Automatic face id authentication>
2) Enjoy
With a web app:
1) Open Browser
2) Type in the URL or...
2) Open settings/options menu of the browser
3) Select favorites
4) Scroll through the list until you find your web site
5) Open the website
6) Realize you are not authenticated
7) Tap login
8) enter username
9) WTF was the password
10) Close the browser
11) Open lastpass etc
<Automatic face id authentication>
12) Search for the website and open it in lastpass
13) Copy password
14) Close lastpass
15) Open browser again
16) Paste password
17) Tap login
18) Enjoy...?
Not to even mention high performance 1:1 user experience vs laggy and slowly loading websites, safety of app store, privacy protection by "Sign in with Apple" etc.
From developers' perspective:
Mobile apps:
- High performance
- 100% access to local SDKs, features, hardware (not exactly 100%, but only limited by the OS)
- Elegant, fast and safe languages with static typing such Swift and Kotlin
Web apps:
- Slow
- Limited access or no access
- JS
Of course if you are developing software for media outlet etc. (app for reading news) then it's probably not worth the effort to build native app vs mobile first website.
I'm not wild for PWAs but your suggested web app flow sounds like failings in the authentication setup of the PWA and of LastPass rather than the failings of PWAs in general.
If a native app can remain authenticated with whatever service it communicates with a PWA should be able to as well, that's an implementation issue rather than a PWA issue, no? Similarly if LastPass doesn't integrate correctly to the point where you're having to manually look up details rather than having details auto-filled across websites and apps (iOS and Android both support this), that sounds like an issue with LastPass.
With all that said, it's hard to deny that it's easier to keep a mobile app performant and flexible than it is a PWA. I'd also add to your list that native apps have familiar UIs by default, which is tricky to replicate in a PWA.
"If a native app can remain authenticated with whatever service it communicates with a PWA should be able to as well, that's an implementation issue rather than a PWA issue, no?"
Native apps don't usually remain authenticated, but they'll allow you to store your credentials on the device keychain or secure enclave and it can be accessed with FaceID/TouchID making re-authentication completely automatic.
"Similarly if LastPass doesn't integrate correctly to the point where you're having to manually look up details rather than having details auto-filled across websites and apps (iOS and Android both support this), that sounds like an issue with LastPass."
We can surely blame the services, apps, browsers for not doing things correctly, but as an user I just want things to be fast, efficient and simple. Right now only native apps provide that experience.
"(iOS and Android both support this)"
Can you tell me how? I use Firefox, Chrome and Brave on iOS and have never seen any kind of Lastpass integration on them.
Thanks for the correction, I admit I have limited knowledge of production ready native app development! As with the UI issue, a PWA developer could still use the JS crypto APIs to roll their own secure store for credentials, or store something similar to an API key issued on successful authentication? Handling this kind of data correctly has a lot of pitfalls, which is likely why most PWAs still use standard authentication processes.
There are APIs and specs [0] [1] [2] that have been floating about for at least the last couple of years which aim to solve credential and authentication management in a more formal way in the browser, but as with many of these features, they're slower moving than the native SDKs. I still don't believe that makes it impossible to achieve a similar flow in a PWA but I certainly concede it's much harder to get right (secure and convenient).
"Can you tell me how?"
As a disclaimer, I jumped ship to 1Password before I jumped ship to iOS, so I've never actually done this with LastPass. But this article[3] appears to offer a similar experience to what I have with 1Password:
- I go to an app or website
- A prompt above the keyboard offers to autofill with credentials
- I tap it and authenticate with 1Password (it normally pre-filters the list by app or website I'm using)
- When I make a selection it autofills everything it can
In 1Password, there is also the option to keep your OTP seed stored too, in which case it will copy the OTP to your clipboard for a short time (and slightly invalidate the purpose of 2FA...).
"High battery consumption and no way to control background services"
- Doesn't apply to iOS apps and background services are controllable and automatically shutdown unless there is specific purpose such as streaming music. Apps abusing these rules will be rejected and removed from app store.
"- 100% access to local user data"
- Completely false. No access whatsoever unless explicitly granted by the user.
"Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)"
True, but marginally used and personally I'll take fast and unsafe rather than slow and unsafe.
"Fast with WebGL 2.0, and proper use of hardware accelerated CSS"
"WebAssembly"
- Valid points. These really are positive developments in terms of web dev. AFAIK WebGL would only give benefits in games and then you would be limited by connection and the process resources of the browser app. WebAssembly is cool, yet 99.999% of cases are basic React apps that don't get any benefits from either of these.
"Limited access is actually a positive"
- Not being able to make the app that you want to make as an web app can be seen as positive I suppose. In native apps there is not direct access to almost anything, but once permissions are given, apps can fully utilize the OS/Hardware features.
Global market share is not relevant. Target group(s) of the industry the application will be developed for and market share of iOS users amongst them is.
In English, unless you are developing apps for poor developing countries, you have to consider iOS users and often the iOS is the lead platform.
Couple of years ago I was developing app for well known Fortune 500 consumer brand in China and while iOS market share was about 15%, amount of iOS users for our apps were about 33% (1/3). When it came to customers actually using money iOS marketshare was somewhere around 40-50%.
Do you develop apps targeted at China, India, etc? Once you ignore developing countries, the market share of iOS grows a lot higher. If you target North America for instance, you’re close to 50%
> - High battery consumption and no way to control background services
Are you drunk? Native apps are orders of magnitude more efficient than browser rendered pages.
Also, wtf are you talking about, on Android your application will be literally killed if you don't post a foreground notification and do something in background without user's notice.
> - 100% access to local user data
Hello SAF and scoped storage, the future is here.
> - Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)
The iPhone is available in almost all of the world. Whether they choose to buy one is a different story.
But as far as “availability”, how many people have high end Android phones with decent GPUs for “with WebGL 2.0, and proper use of hardware accelerated CSS”? Most Android phones sold are low end with crappy hardware.
The average selling price of an Android phone is $250. How many of those have decent GPUs or perform well enough to run web apps as well as native apps?
Ironically, iPhones do better on web benchmarks than almost any Android phone.
As someone who drank the PWA koolaid, I think this understates one significant problem: IOS. Apple, as the article points out is lagging behind. This is an understatement to say the least. More accurately, Apple has an enormous amount of money to lose if people stop using the App Store, so there are "anomalies" in how things work which in the end made it impractical to build an equivalent experience. I gave up and haven't worked on this for a while, but the problem I ran into were from PWA's running in different sandbox from Safari. Have a cookie or local storage? - they are different and can't communicate.
The bottom line is that if you need IOS support, then before you jump on this bandwagon, make sure you can solve your problems of opening URLS (linking) and authenticating users.
Apple is a huge weight against PWA, but it isn’t about money. Apple AppStore revenue is an afterthought when compared to the rest of their top line revenue.
It is about control and security. They would prefer to see every piece of code you run on their device than let you visit some random site.
I can think of 11.5 billion reasons why Apple would work to prevent people from developing PWA's and bypassing the App Store. That was reportedly their revenue from the App Store way back in 2017. More reasons now.
That is a very good point. On the other hand there are a couple of other factors that might be at play. There is the Apple Tax of $99 for a developers license as well as requiring a MAC in order to develop an App. Perhaps not a big deal.
There is also Apple's policy against taking in App purchases without paying Apple a percentage (is it 30%?). This is the reason you can't use your Amazon Prime Video App to buy a movie - Amazon does not want to pay. Apple cannot enforce this rule against PWA's.
I think Apple benefits from this in two ways: first it encourages the 30% payment, and in the cases where companies won't pay (netflix, amazon prime for example) it provides a barrier that makes their own offering more attractive.
The Mac in its entirety is less than 10% of Apple’s revenue. The number of people buying them just for iOS development is even smaller.
You only have to use Apple’s in app purchases for digital purchases. For instance you can buy physical goods in the Amazon app.
Most digital content providers are already forcing you to buy via the web. The only app that I can think of that still supports digital content that you buy in app like books, videos etc is Udemy.
I doubt anyone chose to buy AppleTV+ over Netflix because they had to go to a website.
PWAs have an impressive feature list, and the site he links to is a nice demo of this.
The main arguments to move this way (which are rational) are 1. Competition on app store (including installation funnel) and 2. 1 code base for all devices.
The kicker has always been responsiveness; perhaps this is a matter of technology (or implementation). People expect apps to be extremely responsive and it's important for the bigger players.
Overcoming competition and the installation funnel is more of a marketing/bizdev issue than development. Being able to navigate to a web page and be using "the thing" is also a better experience of installation for the end user.
But for the actual using of the app, we're in total agreement.
I think the arguments here (and in the article) are largely missing the truly valuable point.
For most businesses (not necessarily for Facebook, or even other mass-market consumer-facing companies), the decision of native vs. web is not purely about responsiveness at the "10ms vs. 50ms" level of granularity. The conversation is centered instead around ROI (return on investment), and thus development/maintenance costs are very important.
Thus, the steady march of progress in the PWA space is awesome, and will indeed lead to the decline of native mobile apps created in the corporate space -- especially for internal and B2B use cases (again, not necessarily for the Facebooks of the world).
And they control the web browser engines on iPhones. And keep those with fewer capabilities than native apps. See the HTML audio recording API for an example.
Apple have a massive financial incentive to ensure PWAs aren’t as good as native apps. If people start seeing PWAs as better or as good as native apps, say goodbye to the iPhone.
To be honest it doesn't seem like developers are jumping up and down for it so it's easy to understand why it's not a priority. It's open source so you're welcome to fix it I suppose.
Currently if you want a website that records audio, and you want an iphone user to use it, you have to make a native app, just what Apple would prefer.
I think for applications like LinkedIn you're really better off leaving it on the web as you can kill all of their tracking with blockers, this is not possible with the mobile app. So I prefer to not use LinkedIn or Google products outside of a browser. This is a big hole in the app ecosystem that Apple should plug.
Also it's easier to clean up the UI a bit with plug-ins if your really need to, I think there's a whole ecosystem of them for Facebook for example. So for that type of apps: no way I'm going to install them.
But there are so many websites that just take 1GB of RAM to render one tab of data, like JIRA. I guess one of the problems is that complex JavaScript applications are prone to leaking, unless it's built by a really good team like Visual Studio Code. But mostly more complex applications, applications that have advanced multimedia or performance requirements or simply applications that tie deeper into the native capabilities are better off as a native application.
>> It makes you wonder why certain websites even have an app
Good article, but the answer to the point above always seemed obviously about being better able to identify users and pull their data - this is why so many apps offer functions that go through your contact list and photos (they can pull the contacts to work out who you know and hash image / other files so other apps can be sure they're installing on the same phone)
I've written multiple PWAs and native apps for a variety of clients, and they're basically two different things at this point. As the author points out, iOS especially lags behind.
Right now, PWAs will not replace native apps in their current form. In particular:
- Companies want to have an "app" in the "store". The app store is a huge search engine, and if you don't have an app in the store, then you're missing out
- iOS limits the amount of offline storage you can have, and will just start deleting your data if you go over the limit, so you can't reliably store offline data
- There are a bunch of APIs (especially on iOS) that PWAs don't have access to (there are a number of sites that show that, including the ones the author linked to)
So: PWAs are ok for some things - but will in no way replace native anytime soon :/
I built PWA for https://talksub.com
Please check it out on mobile as well as desktop.
I spent about one or two months optimizing for mobile.
There are still a few critical features missing from PWA.
1. Mobile Notification - probably the most important feature missing from PWA
2. Navigation / History - How history and navigation works are fundamentally different between mobile and web. For example, mobile app keeps independent history for each tab.
3. Pull to refresh - Not as critical, but people are used to this behavior.
Other devices features and native apis are also unavailable.
For basic apps, PWA is pretty good though.
Well I think progressive apps have a long way to go. Now you are able to do things like photo editing and video editing in your smartphones. You can't have that with web apps only. Performance of browsers or webviews is very limited.
I'm a native Android developer who is almost always interested in the new and shiny tool and my bet is on Flutter instead of PWA. The issue with PWAs is that it's tied up to the mobile browser. Things will never get reasonably standardized, your PWA will have random strange issues that you can't fix and your users will have a sub par experience. As a developer, you just don't want that.
for things I use all the time and don't want to fuss with the disaster that is mobile browser tabs, native apps are vastly superior. I have even bundled up and sideloaded "apps" that are just a web view that is pinned to a specific page for some things just so I have a button I can press that always takes me to the same thing and has no potential for extraneous functionality
From a dev point of view I prefer web apps to native apps, because meddling around with the app-stores, xcode and android studio is a huge burden.
From a user point of view I prefer web apps, because I often just have a browser open and switchting through web apps and they also allow me to share links, videos and images even if the app creator didn't directly implement this.
There's stuff like Capacitor with which you can build decently native-feeling PWAs that can be bundled into appstore-ready trinkets if you so desire. I'm a huge fan of the insta-deploy feature PWAs offer tho and routinely lobby for them at my company.
PWAs can show notifications but Apple refuses to implement notifications for PWAs on their platform. You can use Chrome on macOS to get notifications working there but on iOS you're stuck with Apple's decisions. It wouldn't make sense to add notifications for them since PWAs would obviously cut into their profit margin so don't expect PWAs to work on iPhones or Safari in general.
I use my Home Assistant as a PWA and the notifications work well on all platforms I use. Firefox is behind on desktop though, they don't seem to see PWA support as a priority like Chrome does. On mobile it works fine.
Twitter is already a PWA (though they don't advertise it much) which you can install on any modern browser onto your phone. I've installed it in Firefox on my phone and I've never considered downloading their app since. Outlook.com also has some pretty good PWA support. Those are the ones I know off (aside from a few local websites/web apps only available in my language).
I don't know about other social media though, twitter is the closest thing to social media I follow.
Steve Jobs’ original iPhone announcement gets brought up a lot. You don’t release an entire development platform in a couple months as a course correction. They were working on a native SDK before the first iPhone launch. The talk about developing web apps as being the primary way to develop on mobile was a bit of face saving and Jobs style misdirection since the SDK was delayed.
Native apps will never go away, because mobile platform owners can’t wait years until their hardware features are accessible through standardized web interfaces.
That said I agree that too many mobile apps out there should have been made as a website. Also many digital experiences take just seconds or minutes of interaction to be meaningful, so the overhead of App Store reviews and publishing is total overkill. About 80% of apps I have on my phone are not used daily and just taking up space.
However web apps historically have been painfully negligent in persisting user data, and lost some trust among non technical users in my experience.