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.
> 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.
> 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.
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.
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.
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.
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.
[+] [-] flipgimble|6 years ago|reply
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.
[+] [-] rado|6 years ago|reply
[+] [-] techaddict009|6 years ago|reply
[+] [-] viraptor|6 years ago|reply
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.
[+] [-] mpweiher|6 years ago|reply
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.
https://www.macstories.net/stories/before-the-app-store-the-...
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.
[+] [-] akmarinov|6 years ago|reply
[+] [-] lovetocode|6 years ago|reply
[+] [-] skyzyx|6 years ago|reply
[+] [-] dalore|6 years ago|reply
Native is not just plain better.
[+] [-] bambax|6 years ago|reply
[+] [-] pjc50|6 years ago|reply
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.
[+] [-] ForHackernews|6 years ago|reply
[+] [-] illuminati1911|6 years ago|reply
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.
[+] [-] shrew|6 years ago|reply
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.
[+] [-] mattacular|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
- High battery consumption and no way to control background services
- 100% access to local user data
- Fast and unsafe languages such as C and C++ (yes they also come in the SDK tooling)
Web apps:
- Fast with WebGL 2.0, and proper use of hardware accelerated CSS
- Limited access is actually a positive
- WebAssembly
[+] [-] talkingtab|6 years ago|reply
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.
[+] [-] MobileVet|6 years ago|reply
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.
[+] [-] scarface74|6 years ago|reply
[+] [-] ajdegol|6 years ago|reply
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.
[+] [-] threeseed|6 years ago|reply
It just screams PhoneGap/Cordova 2.0 which equally had the same story.
[+] [-] redhale|6 years ago|reply
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).
[+] [-] akmarinov|6 years ago|reply
No way is Apple giving up their 30%, if they can help it.
[+] [-] tarkin2|6 years ago|reply
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.
[+] [-] dep_b|6 years ago|reply
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.
[+] [-] techaddict009|6 years ago|reply
Today even Messenger moved back to Native code from React.
[+] [-] cthulberg|6 years ago|reply
Nope.
https://twitter.com/dan_abramov/status/1234801507805138945
[+] [-] nmstoker|6 years ago|reply
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)
[+] [-] MobileVet|6 years ago|reply
Yes, most apps could be easily dropped with increased focus on web responsiveness. No, it won’t happen wholesale for a variety of reasons.
Most interesting for me to consider is what does an ‘app’ look like when the target is a contact lens or a hearing aid.
Platforms will continue to evolve and native will continue to be preferred imho.
[+] [-] chrisa|6 years ago|reply
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 :/
[+] [-] pjmlp|6 years ago|reply
[+] [-] joonhocho|6 years ago|reply
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.
[+] [-] ghoshbishakh|6 years ago|reply