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
Delivered via HTTPS to protect data from interception, snooping and tampering
Can be installed on devices without relying on an app store
Should work for every user, regardless of browser or device
Able to work offline, online or in poor connectivity scenarios
Always up-to-date based on new app publishes
Engage with applications through push notifications on any device/operating system
Can be shared via URLs and “deep linking”
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
- Pre-Fetching Data
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
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: