What exactly is a Progressive Web App?

What’s in a name?

It’s fair to say that Progressive Web Apps (PWA) have suffered an identity crisis of sorts over the years. The fact that as a community, we have struggled to concisely define what a PWA is has led to much confusion and left these applications and their benefits misunderstood and at times misrepresented.

So, after speaking with the team at Hatchd, I’m stepping in to try and provide some clarity on the matter.

In doing my research, I came across this article by Microsoft that not only highlights the importance of a standard definition, but also provides one.

While I agree with the principles behind this assertion, I think PWAs are best summed up by in the comment below which comes directly from the Hatchd slack channel.

PWAs - an origin story.

The term ‘Progressive Web App’ was coined by designer Frances Berriman and Google Chrome engineer Alex Russell in 2015. But their origin dates back to well before that time.

When Steve Jobs launched the iPhone, he intended that developers would build apps for the phone using existing technologies. He planned that apps could be used directly through the Safari browser. Essentially Jobs believed that iPhones would run PWAs from day one.

At the most basic level, a PWA is a website that is optimised to make the most of the device it is shown on. These applications can be opened directly from a browser and do not require any interaction with an app store.

Unfortunately, at the time the maturity of the underlying languages that power web applications were not sufficient to support this ambition and as a result, the mobile app and app store were conceived and built.

Here’s a quote from Steve’s 2007 Macworld address:

“The full Safari engine is inside of the iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.”

— Steve Jobs

The nitty gritty.

It’s important to note that PWAs are not a new framework or a new technology. What they represent is a new way of looking at and working with available technologies.

From an end user point of view, providing the user experience (UX) is sound, using a PWA should mirror the experience of a native application (there are some minor limitations which will be addressed later).

Below I have listed some of the advantages and limitations of using PWAs.

Advantages of PWAs.

1. They are fast. As the data is cached, there is no load time for the app to fire up. Cached data means there is no need to access the network before opening. The app can open and then reach out to the network to update only what’s changed, not the entire application. Which dovetails nicely into point two.
2. They work offline. Again because PWAs don’t need to access the network to function, they can work without a network connection.
3. They run a single code base. Unlike many native web apps, PWAs run a single code base making them easier to build and maintain.
4. Device agnostic. Web Apps are developed using cross-platform languages that have been designed to be responsive to changes in screen types and device types. Mobile apps often require expensive testing and potential updates to accommodate new hardware.
5. Always up to date. Dedicated applications (for example, the web browser you’re using to read this blog post) require updates to be applied by users and we all know people shy away from doing them. Web Apps check for and apply updates on launch.
6. Better server-side processing. When there is an internet connection, PWAs can be more adept and take advantage of seamless server-side processing (for example, using the Amazon Rekognition engine for image recognition). Desktop and mobile applications naturally do the same, but they more often than not use local computing resources for processing—using the internet for processing involves additional work, where most PWAs are designed to use the internet first and local resources when there is no internet connection.

Limitations of PWAs.

It’s important to mention here that this space is quickly evolving, and these limitations are being overcome at a rapid rate, but at the time of writing these limitations were present.

1. Access to advanced hardware features. While most PWAs grant access to almost all device features there are a few that remain solely in the native app realm. An example of this is access to the phone from a locked screen widget.
2. Security. The fact that PWAs are not downloaded from a trusted marketplace makes it easier for copycat products to exist. As PWAs are essentially websites, a phony (but legitimate looking) copycat could result in downloads. This is already being addressed by some vendors—notably, Google—who are hosting PWAs for desktop computers. They require the hosted applications to be security checked and vetted.
3. Using device hardware to its fullest potential is limited on some older platforms. Native desktop and mobile applications can use special libraries to improve performance of an app. PWAs do not have access to some of these libraries. This is only a relevant factor where high fidelity 3D games or similar capabilities are required. This, however, will be addressed as internet speeds improve, allowing for instance, for graphics rendering to be performed in the cloud or on the local network. An excellent example of this is the game streaming services that have been or are being launched by Sony, Microsoft and Google.

PWAs masquerading in a window.

Today, there are large numbers of applications delivered as “packaged” web applications. The packaging is required as PWAs on desktop operating systems are only now starting to gain ground. Google has a ton of information on getting started with your first PWA.

Web-based applications that are delivered as desktop applications today sit in a wrapper application hich simply stated is a web browser engine. They’re essentially a single window web browser with a dedicated application (written using HTML, CSS and Javascript) loaded in its application bundle rather than exposing an address field. Examples of this include the Desktop Twitter client, Slack (which millions of people use every day), email programs (including Gmail) in various “packaged” iterations, GitHub Desktop, Spotify, and Atom.

These applications are the precursor to PWAs being universally supported as first-class applications on Desktop—likely sooner rather than later this year.

An excellent example of a PWA that works the same on desktop or mobile is Guitar Tuner. This application shows off the real-time processing abilities of a PWA, along with showing off device compatibility by using the microphone.

The future of PWAs.

PWAs are a certainty for the survival of services like Spotify and other music streaming services who don’t want to pay the App store fees for processing in-app transactions. The same goes for book and video purchasing platforms.

As Apple, Google and others continue to invest in their desktop and mobile operating systems, and companies like Microsoft choose platforms like Chromium to drive their desktop browser ambitions, the future of PWAs is bright.

Some smart TVs are already running PWAs in some form. For instance, Panasonic TVs running the Firefox operating system are running applications like Netflix, Youtube and tv channel applications that are all written using web technologies. This makes them easy to adapt to new models, and also makes it possible for developers to develop once and deploy everywhere.

What’s needed to make PWAs mainstream?

The required change is two-fold - A change in developer mindsets, accompanied by how their applications are architected.

For example, it’s entirely possible to create a fully-fledged image editing application with the same experience as some of the bigger applications like Photoshop by designing the application with a distributed model in mind. Local filters can be added simply and easily, and more complex image manipulation can be managed on a server which makes it feel like it’s happening locally in the PWA or browser. When the application is offline, more complex processing is either dimmed out, or is slower.

Another change that is already underway is maturity in the shared frameworks like Vue and React. As they mature, more capability for PWAs will be unlocked.

Are we in agreement?

This has been a surface level introduction (from a marketer) to the concept of using web applications as desktop, mobile or tablet applications. It’s my opinion that the future for PWAs is a particularly bright one but I’d love to hear your insights on the topic.

Stay tuned for more from the Hatchd technology team during 2019.