Skip to main content

3 Reasons Why Progressive Web Apps (PWAs) Won’t Replace Native Apps

Many people believe Progressive Web Apps (PWAs) are the future of the mobile web, but in my opinion, PWAs are not a replacement for native mobile apps.

Here are three reasons why:

1. Native mobile apps provide a smoother & faster experience 

Mobile websites, progressive or otherwise are slower and not as smooth. 90% of the time spent is spent using apps vs the browser.

The single most significant contributing factor to a smooth experience on mobile is the speed of the network and latency of the data downloaded and uploaded.

When you visit websites on desktop or mobile, there is a lot of third-party code/data that gets downloaded to your device, which more often than not has zero impact on the user experience.

This includes:


  • CSS (Cascading Style Sheets)
  • JavaScript
  • Ad network code
  • Facebook tracking code
  • Google tracking code

The median number of requests a mobile website makes is a shocking 69.

On the other hand, native apps only get the data that is required, and this should be no more than five requests for a page load.

Progressive Web Apps do try to bridge this gap, but web technologies continue to constrain them.

2. Apple has no incentive to improve PWA support 

Apple’s App Store generated $54.2 billion in revenue in 2019. Google’s Android has the market share in terms of users (74.3%), but in terms of revenue, Apple makes almost double.

Progressive Web Apps represent a threat to this revenue stream for both Apple and Google, and so Apple has no incentive in improving the underlying technology that runs on iOS. Google, Microsoft and other browser vendors are entirely dependent on Apple to add support to the underlying browser technology.

Google and Microsoft are supporting Progressive Web Apps and have formed a partnership for fairly obvious reasons. Google’s primary revenue stream still comes from web search, and Microsoft needs apps for their App Store (yes they have one) as the Windows ecosystem is unattractive for developers, ask those developers that got burnt developing for the Windows Phone platform.

I certainly wouldn’t be betting on a Google or Microsoft developer ecosystem giving both companies track record of discontinuing projects. Who remembers Microsoft Silverlight or Google Web Toolkit?


3. Native mobile app users buy more items, more often & spend more per transaction

"Retail app users buy 33% more frequently, they buy 34% more items, and they spend 37% more than non-app user customers over 18 months after app launch."
According to Texas A&M University that just published new research in the INFORMS journal Marketing Science

The numbers speak for themselves. Users find the ease of native apps better and as a result transact more on them.

Native mobile apps must be a central part of your digital strategy
When it comes to mobile, native apps provide the best user experience for your users, and as a result, this leads to higher conversion rates, engagement and sales. Progressive Web Apps are still in their infancy, and it will be interesting to see how technology progresses.

A mobile-optimized website is not good enough and your users will soon get tired of the clunky checkouts and logging in every 10 minutes.

You could potentially see PWAs as a replacement for your mobile website, but it is not a replacement for a native app, and the argument for having a website in 2020 that does more than direct users to your app is getting weaker every day as time spent on smartphones only increases.

A bet on PWAs is a bet against the Apple ecosystem that consistently outperforms Google.

For now, if you’re serious about mobile, then native apps are still the best choice to keep your customers happy. 

Comments

Post a Comment

Popular posts from this blog

Freeing Disk Space on C:\ Windows Server 2008

I just spent the last little while trying to clear space on our servers in order to install .NET 4.5. Decided to post so my future self can find the information when I next have to do this. I performed all the usual tasks: Deleting any files/folders from C:\windows\temp and C:\Users\%UserName%\AppData\Local\TempDelete all EventViewer logs Save to another Disk if you want to keep themRemove any unused programs, e.g. FirefoxRemove anything in C:\inetpub\logsRemove any file/folders C:\Windows\System32\LogFilesRemove any file/folders from C:\Users\%UserName%\DownloadsRemove any file/folders able to be removed from C:\Users\%UserName%\DesktopRemove any file/folders able to be removed from C:\Users\%UserName%\My DocumentsStop Windows Update service and remove all files/folders from C:\Windows\SoftwareDistributionDeleting an Event Logs Run COMPCLN.exe Move the Virtual Memory file to another disk However this wasn’t enough & I found the most space was cleared by using the Disk Cleanup to…

CPF Contribution Rates for new Singapore Permanent Residents (SPR’s)

Recently my wife and I applied and got approved for Singapore Permanent Residency. After completing the formalities the most significant immediate change is the contribution to CPF which is Singapore’s mandatory social security savings scheme requiring contributions from employers and employees. CPF contributions start from the date you obtain SPR status, which is the date of the entry permit.   Being a relentless budgeter I needed to know exactly how much I and my employer would have to contribute so that I could adjust my budget accordingly as the employee contributions get deducted from the monthly salary. After doing some research I discovered that there is a “graduated” approach to CPF contributions for new SPR’s where the contributions gradually increase in the first and second year and then upon reaching the third year are at the full amount. Note: There is an option for employers to contribute the full amount for year 1 and year 2 and the employee can use the graduated rate, b…

Populating Duplicate Fields with DocuSign's REST API

If you're using DocuSign's REST API for integrating e-Signing into your application then it's possible you'll come up against the issue of duplicate fields not populating. This is when you have the same field with the same label e.g. Company Name in multiple places on the Document but you only want to send a single label, value instance to the API and have it populate in all places where the field is.

When you pass the label and value like so:

{ label: "company_name", value: "Blogger.com" }
If you have the field company_name more than once in the document then only the first field will be populated.

After a lot of digging into the DocuSign documentation I discovered the solution is to append "\\*" to the label name:

{ label: "\\*company_name", value: "Blogger.com" }
Why this isn't the default behaviour is beyond me but the solution works as expected.


DocuSign Rest API Documentation