Donald Bickel
September 08, 2017

Progressive Web Apps: A Viable Native App Alternative

Donald Bickel

Progressive Web Apps (PWAs) trace their origin back to the strategy of progressive enhancement (which pre-saged modern responsive web design) and are in many ways a reaction to native apps having trumped web technologies for many modern applications. Progressive Web Apps (PWAs) were originally proposed by Google in 2015 with the following description:

Progressive Web Apps are user experiences that have the reach of the web, and are:

  • Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
  • Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
  • Engaging - Feel like a natural app on the device, with an immersive user experience.

This new level of quality allows Progressive Web Apps to earn a place on the user's home screen.

Let’s Put Some More Meat on the Bone

So we see from the very start, Google’s intent is for PWAs to compete with native web apps while using standard web technologies (HTML, CSS and JavaScript) in a non-curated (i.e. no app store) distribution model. A few more specifics, though, provide better criteria to define Progressive Web Apps:

  • Trustworthy
    Delivered via HTTPS to protect data from interception, snooping and tampering
  • Installable
    Can be installed on devices without relying on an app store
  • Progressive
    Should work for every user, regardless of browser or device
  • Sometimes-Connected
    Able to work offline, online or in poor connectivity scenarios
  • Evergreen
    Always up-to-date based on new app publishes
  • Re-Engageable
    Engage with applications through push notifications on any device/operating system
  • Linkable
    Can be shared via URLs and “deep linking”

As you can see, without the significant evolution in HTML5, CSS3, JavaScript and browsers over the past 5 years there is no way that web applications could meet the requirements to be considered PWAs.

How Do Progressive Web Apps Differ from Traditional Web Apps?

At its core, a Progress Web App operates like a traditional web application: they are accessed using URLs in a browser (and thus indexable by search engines). PWAs can be implemented with any standards-compliant framework (React, Angular, etc.) and can be designed to look and feel like either websites or native apps. With this level of flexibility, PWAs can be integrated into existing websites/apps or built from whole cloth and operate standalone.

Why A PWA In Place of a Native App?

For many organizations, the need to jump to alternative technologies, technical staff and distribution mechanisms makes a native application an entirely isolated and redundant effort to the rest of their development efforts. PWAs provide companies the option to bypass bespoke native apps and stick with their mature web-centered technologies, frameworks and staff to provide a high-touch experience for their users. Also, giving the option to skip an app store download yet still have apps that “just work” will be appealing to many organizations and end users.

Pros and Cons

It’s not all wine and roses for PWAs – yet. Below I try to summarize some of the major advantages and disadvantages of progressive web apps in their current incarnation.


  • No Assembly Required: users can consume PWAs directly in their browser
  • Instant Gratification: PWAs load instantly without platform-specific packaging
  • Instant Updates: PWAs are updated upon each request
  • Eliminates App Stores: Users need not access an app store to pick up a PWA
  • Responsive: PWAs use responsive web design techniques to work on desktop, tablets and phones


  • Apple Not Yet on Board: Safari does not support PWAs; Mac and default iOS browser users get no love
  • Single Sign-on Not Supported: PWAs cannot make use of Facebook and Google for identification
  • Lack of Full Hardware Support: PWAs do not support all native hardware components

Let’s Get Under the Hood

All Progressive Web App architecture consist of two main components: service workers and an application shell. Service workers are new-ish web technology that act like a proxy that a user’s browser runs in the background (separate from any web page). Effectively, service workers sit between the user’s browser and the application server and respond to requests made by the user’s browser. In this way service workers nullify the need for continuous server connection as it caches information the application depends on. Service workers also exist to deliver extra features not traditionally possible via browsers including:

  • Push Notifications
  • Synchronization
  • Pre-Fetching Data

The other half of the equation, the application shell, is the least possible HTML, CSS and JavaScript required to power the user interface. When cached offline the application shell can ensure instant, reliably good performance to users and reduces network traffic to only the content/data necessary for the user’s job at hand.

Developing PWAs

Developing PWAs takes a bit of a different approach than developing desktop-oriented web applications but is largely similar to the frameworks and methods they have been using to develop websites and applications for the past two decades. Getting started with a PWA project involves delving deeper into Google’s code lab. The Google code lab offers a step-by-step tutorial to create an app using the “app shell” method. Google lays out some basic requirements for getting started:

  • A recent version of Chrome
  • Chrome DevTools
  • Web Server for Chrome
  • The sample code
  • A text editor
  • Basic knowledge of HTML, CSS, JavaScript and Chrome DevTools

Those looking to move further into PWA development should definitely brush up on their JavaScript skills and associated toolchain because the service worker model is effectively a JavaScript Worker. Google does provide several boilerplates to jumpstart the “getting started” process; compared to learning Android AND Swift/Objective-C it is a walk in the park.

In Closing

At Mercury, while we acknowledge the value and importance of curated native app stores, the ability to distribute applications on par with native apps (and take advantage of device capabilities) and can be distributed across the open web is very appealing. PWAs do hold the possibility of being an ideal combination of native application responsiveness and richness with the open and democratized nature of the open web. We can’t wait for PWAs to overcome some of their current limitations and be fully viable alternatives to native apps – without the app store gatekeepers.

Native mobile application development requires new skills and time, luxuries many businesses lack. As a result, technologies like PWA are bound to grow. The first wave of enterprises that have deployed PWAs have seen significant increases in conversions through their web properties; that should be a strong indicator of where PWAs are going.

Are native apps going away? Not by a longshot. Will some organizations turn to PWAs to provide rich, sometimes-connected application experiences? I think very much so. Will I recommend PWAs to our clients in the right circumstances? Definitely.

Want to learn more about some sample PWAs? Take a look:


  1. RadEditor - HTML WYSIWYG Editor. MS Word-like content editing experience thanks to a rich set of formatting tools, dropdowns, dialogs, system modules and built-in spell-check.
    RadEditor's components - toolbar, content area, modes and modules
    Toolbar's wrapper 
    Content area wrapper
    RadEditor's bottom area: Design, Html and Preview modes, Statistics module and resize handle.
    It contains RadEditor's Modes/views (HTML, Design and Preview), Statistics and Resizer
    Editor Mode buttonsStatistics moduleEditor resizer
    RadEditor's Modules - special tools used to provide extra information such as Tag Inspector, Real Time HTML Viewer, Tag Properties and other.

Subscribe to Our Blog

Get the latest blog posts sent right to your inbox so you never miss an informative post from Mercury.


Get Your Share On!



Archived Posts

Go here to find all blog post published before the new year.