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. 

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\Temp Delete all EventViewer logs Save to another Disk if you want to keep them Remove any unused programs, e.g. Firefox Remove anything in C:\inetpub\logs Remove any file/folders C:\Windows\System32\LogFiles Remove any file/folders from C:\Users\%UserName%\Downloads Remove any file/folders able to be removed from C:\Users\%UserName%\Desktop Remove any file/folders able to be removed from C:\Users\%UserName%\My Documents Stop Windows Update service and remove all files/folders from C:\Windows\SoftwareDistribution Deleting 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

Consuming the SSRS ReportExecutionService from a .NET Client

  I’ve just finished writing a nice wrapper which internally calls the SSRS ReportExecutionService to generate reports. Whilst it was fairly simple to implement there has been some major changes between 2005 and 2008 and the majority of online and documentation is based on the 2005 implementation. The most important change is that the Report Server and Report Manager are no longer hosted in IIS which will be a welcomed change to Sys Admins but makes the security model and hosting model vastly different. So far I’ve yet to figure out how to allow Anonymous Access, if anyone knows how to do this leave a comment and it will be most appreciated. Getting Started To get started you’ll want to add a service reference to http://localhost/ReportServer_SQL2008/ReportExecution2005.asmx where ReportServer_SQL2008 is the name you configure in the Reporting Services Configuration Manager. The Web Application files are located in C:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\R