I recently built a word game as a side project. I wanted to create an app that I could install on as many devices as possible (iOS, Android, desktop, etc.) with only a single code base. Therefore, I decided to use a progressive web app (PWA) as the basis for my game. 

In this post, I will share my experience with the PWA design process requirements, and introduce the pros and cons of PWAs. The goal of my post is to explore whether PWAs are a viable alternative to native apps. I hope you are able to use this information to inform your own opinions regarding PWA use for your future projects.   

An Introduction to Progressive Web Apps

At their core, PWAs are just normal websites; when you interact with a PWA, you do so through the web with a url. However, like a link on an evolutionary chain, PWAs are a special type of website that has progressed to be able to take on native app functionality. This means that they contain elements of both standard websites and native apps. 

PWAs are becoming more popular as larger companies begin to use them for their consumer apps. A few notable companies that utilize PWAs include Twitter, Spotify, Pinterest, and Starbucks, just to name a few. 

PWAs vs. Responsive Design

PWAs are frequently compared to responsive web design (making web pages render successfully at various screen sizes). While these two processes may present similar outcomes from the user standpoint, building a PWA is more than just making sure an app works on different screen sizes. 

PWA design also provides the following benefits:

PWAs Can Be Installed on Your Device: When opened in a browser, a PWA website prompts you to install it as an app on your device (on desktop, the browser itself can even prompt you with a “(+)” icon on the right side of the URL bar). Once a PWA is installed, it will appear as an icon on your home screen, just like any other app. 

Once downloaded on your device, the PWA is still technically a website. However, when you open the app, the icon will still have the name and logo of the app (versus the name of the web browser), and will closely resemble a native app. The PWA developer can also hide the url bar and web toolbar to give the PWA the feel of a native app and maximize screen space.

PWAs Can Proxy Network Request: PWAs have service workers that can proxy network requests for the app. For example, if the app needs  a photo from the web, the request is sent from the PWA to the service worker, which then receives the photo from the web and delivers it to the PWA.

While this may seem like an extra step, it actually allows the app to aggressively cache itself . Browsers typically cache just the page you’re currently visiting, but a PWA can instruct the browser to pre-cache the pages and assets of the entire app  (a process similar to installing a native app on your device). This allows the PWA to load more quickly and do all non-interactive activities completely offline.  

PWAs Can Support Push Notifications (Sort of): Most devices send application updates via push notifications. PWAs are able to support push notifications  because the service worker remains active even when the app is closed. 

Unfortunately, PWA push notifications are  not supported by iOS devices. This disconnect between iOS and PWAs is a compelling argument  that PWAs are not a viable alternative to native apps. However, there are ways to work around this obstacle, such as sending notifications via text or email. 

Requirements for PWAs

Once you decide to build your app as a PWA, you then have to understand what elements are required to make it successful:

Secure Connection (https): A PWA must be sent over a secure connection. Luckily, it is fairly simple to create a website with a secure connection, so this is typically not an obstacle for most developers.

Manifest File: A manifest file is a W3C standardized file that allows you to define some metadata about your PWA. For example, here is the manifest file for Wordit: 

When you launch the app, the splash screen that appears is controlled by the manifest file. For example, on Wordit’s manifest file, the first item defines the background color of the splash screen. The manifest file can also change the icon for the app, depict the url when you start the app, and alter other startup sequence design characteristics. The manifest file is beneficial because it is a standard file that allows you to control the PWA even once it is installed. 

Service Worker: As mentioned earlier, one of the defining characteristics of a PWA is the service worker. When you visit a PWA, the service worker goes through several phases:

1. Installed Phase: First, your service worker goes through an install phase, where it downloads itself to your device, initiates, and installs itself.
2. Waiting Phase: Once it is installed, the service worker remains in the waiting phase until you access your app.
3. Activated Phase: The first time you access the app, the service worker is activated, giving it control of the PWA. Each service worker is versioned by the browser, so you receive service worker version 1 when you initially access the PWA. However, when the developer releases an updated service worker, your app can detect the update and automatically install the newest version of the app to your device (although it’s typically better to prompt the user to install). The new service worker will sit in the waiting phase until the app is restarted and it can switch places with the activated service worker. 

When you’re developing a PWA, keep in mind that clicking the browser’s refresh button will not immediately show you the latest changes to your code (unlike with a traditional website). Clicking refresh will download and install your new code, but keep the new service worker in the waiting phase. To see your code changes during development, you must either completely restart your app (closing all tabs where your app is running), or use your browser’s development tools to enable new service workers to activate immediately.

The code for a service worker is divided into two logical areas: the registration code and the operational code. This is the registration code for the Wordit service worker:

The registration code registers the service worker and listens for events related to service worker updates. It is also responsible for organizing service worker switches to ensure that all tabs of the PWA have the latest version of the app. 

The operational code for the service worker is typically shorter than the registration code:

However, the operational code’s length does not undercut its importance. The operational code is responsible for telling the service worker to pre-cache the site and download it to your device. It also notifies the service worker when there are updated files that need to be pre-cached and installed. 

Final Thoughts

As you browse the web, you will notice that more and more websites are displaying the telltale “(+)” of PWAs. While there are certainly benefits to PWAs, and I found the experience of building my own PWA very rewarding, I think I view PWAs as one part of a multi-pronged approach to app development, and I look forward to building native apps in the future.