“Progressive Web Application” is a popular new terminology that encompasses an up and coming standard for web applications. This standard gives web apps the ability to be installed to a device and to function like a normal, lightweight device application. Devices can be mobile phones, tablets, or even more recently desktops. The app can be programmed to function even without a data connection. This is a pretty powerful leap forward for web development and brings a number of benefits:
This can all be achieved without having to deal with compilation for different platforms, deployment to different app stores, developer licensing and fees, and the hassle of separate code bases and frameworks for building the app. All together this can significantly lower the barrier to entry for extending a web platform for offline usage.
Typical web apps are designed to serve a user interface and manage data retrieval and interactions with a user.
A progressive web app does those tasks, too. It also defines how the app should look and feel once installed, and it registers a background worker to manage background application events.
The web application manifest configures icons, name/title text, colors/themes, and startup behavior of the app.
The service worker is a JavaScript implementation that can manage app installation and caching, serve resources from cache or network, and respond to background events.
The APIs are designed to work “progressively.” This means the code should be structured to check if a feature exists before attempting to use it. For example, check for a service worker API and, if available, set one up. Once the web app manifest and service worker are properly implemented your app can be installed to a supported device and used offline. In Android/Chrome’s case you will even get a prompt indicating that you can install the application to your phone or tablet. I won’t cover implementation details here, but there are lots of resources on the web. Google provides a great starting point on a manifest here and a basic service worker here.
Remember, I said this is an “up and coming” standard. While Google has been stabilizing the technologies on Android and Chrome for a few years, it is still very new in the Apple/Safari space. This means PWAs might not quite have the same “feel” of a native application on an iPhone or iPad just yet. From my point of view, these are the major differences as of September 2018:
Android (Chrome) |
IOS (Safari) |
|---|---|
Clear separation of resources and logic:
|
Much of the web app manifest is supported, but some icons and features must be specified through </link> tags in the head of the HTML markup. The service worker API is fully implemented. |
| App install banners provide a user-friendly prompt that the application can be installed to the user’s device. | No concept of install banners. Users must install the application by visiting the site and using the Share/Add to Home Screen button. |
| Chrome apps can use up to 6% of the device storage space for persistent/offline storage like cache, IndexedDB, cookies, and local storage. | Safari has a hard limit of 50MB of persistent storage. This could be a big barrier to developing a robust offline app with lots of content or storage of user input. |
| PWAs are pretty well integrated into the Android OS. Android will even generate what they call a WebAPK to install the app like a native Android application. This means the OS can manage the PWA like a normal app, and it will appear under the app list where the user can manage permissions and storage, force close, or uninstall the app. That said, the app still runs in Chrome, but the developer has the option to change the display setting through the web app manifest which can make the app appear full screen, as a native/standalone application, or as a normal browser page. | Safari supports standalone and browser display, but isn’t as tightly integrated. One often noted issue is that application state is not maintained when switching between apps or minimizing the PWA. It is suggested to maintain your own state with local storage, but that will eat into the 50MB storage limit. |
| Push notifications. A PWA can register for push notifications from a server and wake up/display notifications whether it is open or not. | No current support for push notifications. |
Other browsers are playing catch up as well, but there is pretty decent support in Edge, FireFox, Opera, and Samsung, which means that PWAs will eventually have wide support on mobile and desktop devices.
Progressive web apps are even making inroads in to app stores. Appscope is exclusively dedicated to providing an app store for PWAs. Microsoft has updated Windows 10 with support for PWAs and has even added some to the Microsoft Store.
What does this all mean? Should you ignore the standard for now and come back when it has full support? Maybe, maybe not. The cost to add this functionality to an existing or new web application is pretty low when compared to an entire native or hybrid app implementation. Even if all of the APIs aren’t available on a device, a PWA can still improve application functionality by selectively pulling down resources to cache. If your PWA requirements are minimal—simple enough to be supported on all platforms—or you’re only targeting Android, it’s an easy win. Adding the functionality now will also ensure future support as each platform implements more of the standards and functions.
In my next article I’ll cover the implementation details of adding progressive web application functionality to a website, as well as sample implementations of some important APIs.
If you're looking to hire technical staff or are interested in custom software tailored to your business' needs, please contact us or explore our services to learn more. You can also sign up to receive our technical and business articles straight to your inbox.
