Have you ever asked yourself why all apps aren’t web apps? Well, this is actually already the case on desktops and most of the apps you use at home and/or at work. When it comes to productivity apps, Microsoft, Apple, and Google all have full-featured web apps that are just as capable as locally installed desktop applications. As long as you have good wired or wireless internet, you can do nearly all of your work in Chrome, Edge, or Safari. Apart from specific categories, such as graphics, video editing, software development, and high-end gaming, you can do nearly everything in a web browser.
Mobile, however, is a different story.
Whether you’re trying to tether a laptop or use a mobile device, using a native app is preferable to using a web app. Native desktop and mobile apps have access to device hardware (such as storage) and can work offline. When it comes to mobile, it doesn’t matter whether you use the mobile versions of Chrome (Android) or Safari (iOS)—they’re pale shadows of the desktop versions, and they aren’t worth the effort.
The good news is that things are starting to change, and a new generation of Progressive Web Apps (PWAs) are changing the status quo. They’re the missing piece that will allow any browser-based app to look, act, and respond like a native app. They work offline, are able to access native device hardware (e.g., camera, storage, network, etc.), and provide a user experience that’s indistinguishable from native applications.
At this point, Google and Microsoft are fully committed to supporting PWAs across their platforms and browsers. Apple hasn’t made an official commitment yet, but there’s evidence that both desktop and mobile Safari will offer partial or full PWA functionality in the near future.
In this post, we discuss how the mobile revolution and the rise of smartphones led to the creation of PWAs. We explain what PWAs are, describe their component parts, and provide instructions for how to build and test them.
The Rise and Fall of Web Apps
Until 2007, it seemed like the rise of web apps was unstoppable, but then the iPhone changed everything. Google quickly followed Apple’s example and launched Android. Both platforms came with a built-in browser that did a reasonable job of rendering web pages. Due to security and performance concerns, the browsers had limited access to a device’s hardware. Developers voted with their feet—they preferred writing mobile versions of their apps using each platform’s native SDK and distributing them via app stores.
During the rise of native apps on mobile devices, it appeared that web apps were becoming irrelevant at best, and obsolete at worst. Desktop browsers and web apps may have been overshadowed, but in this period, a number of new developments made the web browser the platform of choice for app development and delivery. Ironically, given that we think of Apple as the iPhone company, we forget that they were instrumental in creating the web standards that resulted in new and better web apps.
Following the launch of Safari on the Mac, Apple created the WebKit rendering engine. In 2008, Google adopted WebKit and started to implement the new web standards in their Chrome browser. Chrome enabled developers to deliver web apps that could access device hardware such as storage, camera, and location. Recently, Google has been adding these features to the latest versions of mobile Chrome on Android and Chrome OS. Alex Russell, a Google Chrome team member, coined the term Progressive Web App (PWA) to define these new developments.
What is a Progressive Web App?
On Google PWA homepage, a PWA is described as a web-based user experience that’s reliable, fast, and engaging. Highlighting these three qualities draws attention to the fact that many web apps are unreliable, slow, and not engaging, which has the potential to tar PWAs with the same brush.
When it comes to reliability, a web app is only as reliable as its network connection. A bad connection means that a web app will either load slowly or not load at all. So PWAs should load quickly and reliably even when network connectivity is uncertain. If network connection is lost during a session, you should be able to rely on the PWA to save data and any changes you made.
You could say that reliability and speed are two sides of the same coin. This is partly because they’re dependant on sending requests to and receiving responses from remote servers. It’s also because many front end frameworks that are used to create web applications perform less efficiently than similar native frameworks.
A PWA that’s reliable and fast will engage users and ensure that the PWA user experience feels as natural as using a native app. As far as the user is concerned, a PWA is no different from a native app, and it should provide a shortcut icon that allows launching from the home screen. PWAs are progressive because, no matter what limitations a browser has, they can be progressively enhanced to include any missing functionality.
In addition, PWAs must have the following characteristics:
Discoverable
What use is writing a great app if no one can find it? And once you’ve found it, how do you install it? There are many sites that provide curated lists of available apps (e.g., PWA Rocks). In the near future, PWAs will also be available from app stores.
To install a PWA, you must locate and download the relevant assets to your device. In order to find and install these assets, developers create an app manifest. The manifest is a JSON file that stores web application metadata and related information. This includes its name, links to assets (e.g., icons, images, video), the preferred URL to launch or open the web app, and configuration settings (orientation, full screen, etc.). The browser uses the information to provide support for device-native services and hardware.
Provide Offline Support
One of the biggest problems with using the mobile web is that it must be connected to the internet. In order to provide a completely app-like experience, a PWA must be available and work offline. PWAs provide offline support via service workers, which are scripts that a web browser runs separately from and in the background of a web page. The service worker sends requests and caches the responses. In other words, a service worker doesn’t just store application data in random access memory; instead, it persists this data to the device’s file system or the browser’s internal databases. In the event that the browser’s internet connection fails, it can continue to operate offline. Service workers can also provide support for push notifications and updates.
Secure
The HTTP protocol enables you to pass unencrypted data over an internet connection. Since the world is a dangerous place and PWAs will be used to handle sensitive personal and financial information, it’s better to be safe than sorry. PWAs ensure security by being served over HTTPS. While you technically can create a PWA and serve it via a non-secure HTTP, using HTTPS provides an extra layer of protection for sensitive user data.
Building and Testing Your First PWA
The first step for creating a PWA is writing a manifest file. Next, write a service worker for caching pages and handling offline data. The last step involves integrating the service worker into your application. This requires writing code that registers and downloads the service worker. For a detailed, step-by-step guide, see this tutorial from Google. If you want to convert an existing web app, see this guide from Chris Love. Another approach is to use an online service, such as the Manifold Online PWA Builder.
As with any web or mobile application, it’s not enough to just write the code—you also need to test it before it’s released for users. A PWA is a web app, so its elements can be tested using existing manual and automated testing techniques. Additional tests will be required to measure online and offline performance and presentation. For a comprehensive list of PWA features and functionality, you should test, see Google’s PWA checklist.
PWAs are also excellent for visual testing. For example, you can test your PWA using Applitools Eyes. Applitools Eyes allows you to define a visual baseline of your app. If a test run detects differences between the expected/baseline image and the actual image that’s detected in the test, the test is failed. Oftentimes, the difference doesn’t come from an issue or a defect but is instead caused by a newly introduced feature or cosmetic change.
Conclusion: The Best Is Yet to Come
Over the last ten years, we’ve witnessed an impressive evolution of the mobile web. In that time, we’ve progressed from primitive, barely usable mobile browsers running on features and pre-iPhone smartphones to today’s highly capable mobile browsers that run on phones and tablets.
PWAs are the next step in the evolution. They will blur the lines between mobile and native development. While developing and deploying mobile web apps may be easier, the issue of testing mobile apps becomes increasingly important. To ensure the best possible experience for your users, the case for using visual testing tools like Applitools Eyes has never been stronger.
To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.
