It’s Time to Build a Progressive Web App. Here’s How
What does it take to qualify as an app in 2022? The answer isn’t the same as in 2002, or even 2012. For example, there used to be a distinction between “websites“ and “web apps.” No more.
Nowadays people refer to websites and web apps interchangeably — and it’s safe to say that the distinction does not matter anymore. In fact, the vast majority of websites today would qualify as web apps.
By contrast, when we take the word “web” out of the equation and only hear the word “app” alone, we tend to think of platform-specific applications found in app stores or software for desktops downloaded from the internet.
For the most part all those apps are incredibly well made, and they can be deeply integrated in their appropriate operating system. Indeed, when given a choice, users will opt for the app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.
What Is a PWA?
Think of PWAs as websites that leverage modern browser features such as HTML, JavaScript and Cascading Style Sheets (CSS) to deliver beautiful, fast, rich and reliable applications, either directly on the web or by being downloaded through app stores.
The word “progressive” in PWA is indicative of the spectrum of functionality that users will experience. Not everyone has the latest device, of course, nor is everyone running the latest browser engine. A PWA offers adaptive functionality based on the user’s current configuration.
Cross-platform compatibility is another benefit of a PWA. Building an app, no matter which kind, is costly. However, there is a special price associated with distributing native apps for different platforms, mostly because programmers must code in multiple languages, use different libraries and support many technologies.
Indeed, interoperability is an area where the web has always been superior: A web page runs on any browser requesting it, and the web page is always up to date. With a PWA, we are getting closer to the rich capabilities that we expect from platform-specific apps while keeping the speed and the distribution advantages that the web offers.
Think about Design
The differences between a website and a PWA are key.
Websites are always opened through a browser tab, whereas PWAs can be optionally installed on a device. This has a major impact on the way developers think about the design of their application because even if the content of the app is the same, its container is completely different.
On a website, the container is the browser, and it comes with all the regular navigation patterns such as the URL bar, and previous and next buttons. On a standalone PWA, those components are replaced by a full-screen window, which provides a much more immersive experience, but to the detriment of the browser’s native user interface. PWA developers need to implement their own navigation patterns inside the app.
The image below shows two examples of the browser and PWA experience. The browser, on the left, has a standard URL bar, send-to, bookmarks and new-window tools at the bottom. The PWA, on the left, doesn’t have those, and therefore the application can use more of the screen.
Consider icons. Because a PWA is accessible from outside a browser, developers must pay more attention to icon design. When an icon only exists inside an app, design is more intuitive because it sits alongside other app components. However, when an icon appears standalone outside of the browser it must follow stricter rules if it wants to blend with the rest of the operating system design philosophy.
For instance, a PWA icon can be found in an iOS or Android device home screen, or within the Dock on macOS, or the Windows Start menu, or the ChromeOS and Linux app menu. Those locations are best used when icons were designed specifically for them. A PWA can accommodate all icon formats by providing a dedicated array of icons, identified by the format of each icon.
Installing the Application
One of the most appealing aspects of PWAs is the technology that allows you to install a web app onto a device. Not surprisingly, one of the biggest challenges PWAs face is installation, because there isn’t a unified experience that would allow an iPhone user, an Android user and a Windows user to install a web app the same way. These challenges are also opportunities. Developers willing to invest in the PWA user experience design process can craft a fully personalized installation experience that fits every operating system and browser combination.
To offer a proper PWA process, a few criteria must be met:
- App is served through HTTPS.
- App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
- App has a registered service worker with a fetch event handler. (More on this later too.)
Assuming those criteria are met, an app should be eligible for installation. The steps for taking a web app into a device differ depending on the operating system and the browser.
On desktop devices, Google Chrome and Microsoft Edge currently provide the best PWA installation experience. An install badge will show in the URL bar of supported browsers. Clicking on the badge will trigger a simple popup asking the user to confirm if the web app should be installed. After the user confirms, the web app is then installed and appears in the desktop start menu or dock. (Note that I develop PWAs in a platform called Oracle APEX, so you’ll see “APEX app” in many of my examples. More on APEX’s PWA support here.)
On iOS and iPadOS, native automatic installation is not possible as of this writing. Moreover, only Safari can move a web app to the home screen. Other browsers found in the App Store, such as Google Chrome and Firefox, do not have the same operating system permission, making Safari the only option to install a PWA. This limitation is unfortunate, but can be circumvented with proper device detection and clear in-app instructions.
Speaking of instructions, the steps to install a web app on iOS are:
- Tap Share icon
- Tap Add to Home Screen
- Tap Add
Then the icon appears on the home screen and the app can be opened in standalone mode.
On Android devices, the installation process resembles the desktop experience, which is to say that users can find an actual Install App button in the browser, which triggers an automatic installation process that takes the web app to the home screen. The terminology around installing or adding to home screen differs between browsers on Android; even so, Android qualifies as the most consistent platform to install a PWA.
From a design perspective, it can be a good idea to have an additional in-app Install App button that will trigger the native installation process.
Web App Manifest
If the PWA architecture had a brain, then the web app manifest would be the artistic right hemisphere. The web app manifest is a JavaScript Object Notation (JSON) file that contains the metadata about an application to inform the operating system about how it should look and how it should behave. Here is some of the information in the web app manifest.
- name: This is the complete name of the app as it will appear in devices’ home screens, launchers and menus.
- description: This is descriptive data shown during installation that explains what this app does.
- start_url: This is the URL that is opened when the app is run by the user. In most cases this would be the home page of the application.
- display: This configures the PWA to run in one of four screen modes: standalone, full screen, minimal, browser.
- orientation: Preferred orientation for the app. For instance, a game might prefer landscape mode, but a chat program might do better in portrait.
- theme_color: This is the color of the container around the app, specifically for the task bar when using the PWA in full-screen mode.
- background_color: This is the background color when the app is opening.
- dir: Determines if the app should be viewed as left to right (default) or right to left.
- lang: The language of the web app manifest values.
- icons: A set of icons in different formats representing the app.
- shortcuts: An array of URL shortcuts that can be seen when doing a long press on app icon.
- screenshots: A set of screenshots that will be displayed as a slideshow during installation.
Using the Web App Manifest
Adding a web app manifest to a web app is simple. The developer simply adds a link in the head element of the page:
When the browser picks up the web app manifest, the browser will recognize the properties and will configure the runtime user interface.
Deep Integration with Devices
There is much more to PWAs besides the ability to install a web app. For a complete integration in the operating systems, an app must be able to operate silently in the background even when the device is idle, for example, to receive notifications, synchronize data or manage payment requests. PWA technology allows such event handling even when the user is not browsing the website or actively using the app.
Service Workers
If we use the brain analogy again, the PWA architecture’s service worker is the logical left hemisphere. A service worker is a middleware JavaScript file that sits between the web app and the server, intercepting requests and deciding what to do with the response. The service worker has access to a rich caching mechanism that stores responses that can later be retrieved without reaching back to the server. Essentially a service worker is a proxy between the server and the client.
To ensure maximum security, a specific service worker only works with a single application and a single domain. The service worker must be registered by an application and can be removed anytime. Users can monitor service workers by going to the browser developer tools.
Powerful Caching for the Web
The web does not have a good reputation when it comes to data accessibility for offline devices. However, one of the selling points of PWA technology is its ability to cache resources with complete control, allowing them to store files and data locally and turning a web app into something that can be used offline.
Given the service worker caching capabilities, it’s important to understand what should be cached in the first place:
- Pages HTML
- JavaScript
- CSS
- Images
- App data (JSON or other)
- Fonts
It’s unlikely that an application requires all those files on the first load, which is why PWAs can choose to load a bulk cache when the application is first installed and then cache subsequent resources only when they change on the server, or when they are requested by the user.
Some useful caching events are:
- On PWA installation
- User navigates to another page
- User is idle (pre-load potential new data)
- User requests a resource that is not cached already
Imagine an e-commerce shopping application that displays a list of products, each with a particular image. Upon the first page load, the service worker will intercept the request from the client to the server to download a product image. Because the image does not exist in the cache yet, the service worker will fetch the image from the server and store the image in a local cache. Once on the local device, the image is sent to the client for display.
The next time this page loads, the service worker will first look into the application image cache, and it will find that the requested image already exists. Instead of passing the request to the server, the service worker will instead return the image directly from the cache, therefore avoiding a round trip to the server.
This example was using the cache first approach, and it is one of many service worker strategies that can be used to serve a web application. Other strategies include:
- Network first
- Stale while revalidate
- Network only
- Cache only
There are two goals when it comes to caching resources on the web. The first is to speed up response time, generally making a faster app. The more resources are cached, the less we can stress the server and the effect is immediate. The second goal is the ability to run offline. If app developers keep taking advantage of those caches more and more, they eventually reach a point where most of the application logic is available locally and network connectivity becomes optional. Having an offline app is not necessary for all business use cases, but it’s certainly better than having the app complain that the application can’t connect to the server.
Push Notifications
The Chrome User Experience Report finds that users generally find push notifications useful and even more so on mobile devices. Well-designed push notifications can increase user engagement to a web app because it incentivizes them to quickly return to a specific area of an application. Push notifications allow users to read messages at a glance, track order statuses or remind them to complete a form they forgot to fill. Because a push notification stays on screen for a few seconds and can be dismissed easily, they are not as obstructive as an email, and it’s been proven to be an effective communication method.
With PWA, a web app can request permission to send push notifications to users.
Unlike platform-specific apps, which are given implicit push notification access, PWAs must be granted permission to provide those notifications. Once accepted, PWAs can proceed with sending push notifications to their users.
Low-Code PWAs
All features in this article can be coded by hand, given a basic understanding of HTML and JavaScript and a thorough knowledge of the service worker functionality. In many cases, adding PWA support to an existing application is simply adding another layer of application logic on existing code.
There is an alternative that is even simpler: Creating a custom PWA using a low-code platform. In this approach, developers can offset the burden of coding mundane tasks like creating a web app manifest and a service worker, and instead focus on crafting the business logic of their applications. In other words, developers can create a PWA without actually coding the PWA, by simply enabling or disabling options from a user-friendly application builder.
One low-code platform that generates PWAs is Oracle APEX. It’s one of the most mature and popular low-code platforms available. You can create a free account today.
What Is Next for PWAs
PWAs are becoming a legitimate alternative to platform-specific apps, but they’re not entirely there yet. One reason: Users have developed a habit of searching through app stores to get the apps they want, and PWAs don’t work that way. Instead, users need to install a website, and that’s a new process.
It’s only a matter of time until users become familiar and comfortable with installing PWAs, but in the meantime, developers have this extra challenge of creating an intuitive PWA installation user experience.
Also, and perhaps more confusingly, not all browsers and platforms are created equal when it comes to PWA support. Today, Google Chrome and Microsoft Edge lead the way with the simplest and most complete PWA experience. Apple’s Safari also does a decent job at supporting the core PWA features, but only time will tell if Apple will invest in a more competitive web apps market.