Say yes to the progressive web
Ten years ago, when smartphones were the new thing, the message went out that you needed to have a stand-alone app to run on the phone. Mobile development was a new kind of programming with unique challenges, but there were good reasons to do it at the time, such as top performance and promotion and software updates managed through the app store. However, to get access to all the features of the mobile device, you needed to write native code.
Today, mobile development still has unique challenges and expenses. However, the good reasons to invest in it have been frittering away. An alternative model, the progressive web, looks like a better choice when you consider all the factors.
To the user, a progressive web app (PWA) looks and behaves like a native app. It doesn’t look like the software is running in a web browser; it works when the device is offline; and users launch it from an app icon just like a “real” app. But behind the scenes, the app is not running as a native program on the device but as a full-screen website in the browser.
There are many significant advantages to choosing the progressive web model over the native app model, including:
- Updating the application involves changing files on the servers under your control. Apple and Google don’t need to be involved at all. Changes go out to all users at once (assuming the users are online).
- The programming model is standards-based, not controlled by one vendor.
That last bullet point is technically accurate, and yet it raises an important issue and the main problem with adopting progressive web apps today: The driving force behind PWAs is Google.
Google is, by far, the most aggressive in adopting new browser standards behind PWAs in Chrome. Other vendors, such as Mozilla, Microsoft, and, in particular, Apple, have been much less aggressive, though the April 2018 Microsoft update brings with it EdgeHTML 17, the fifth major version of the Microsoft Edge rendering engine. This release claims new developer capabilities for websites and web apps, including the foundation for full-featured PWAs on Windows.
Apple, it should be noted, has a clear business interest in keeping apps native: Such apps must be distributed through its app store, where the company takes a large percentage of the app sale price, proceeds from in-app purchases, and advertising revenue. With PWAs, there is no need for a store to distribute apps, and since the software is just webpages, the advertising is done through the conventional web advertising networks (which are dominated by Google).
However slowly, Apple is adopting many of the key standards behind PWAs. If there is one most important standard for PWAs, it is service workers. Service workers, which are web code triggered by an event, run in the background of the webpage, basically like threads. Numerous other standards have extended service workers, such as Web Background Synchronization, which allows service workers to work, or to at least stay alive, even when faced with common challenges such as a user shifting away from the browser or the network becoming unavailable.
A certain sense of inevitability
Apple added support for service workers in iOS 11.3 and macOS High Sierra 10.13.4, although so far, only for the Safari web browser and applications that use the Safari control for browsing. Version 17 of Microsoft’s Edge browser, currently in pre-release and scheduled to be released very soon, will support them. At that point, all major browsers will support service workers and their rate of adoption should increase.
The advantages of PWAs are important for enterprises, not just for app startups. The ability to have one code base serving to desktops, phones, and tablets of any brand is a major plus for development savings and software quality. And when you need to make changes, you can do so just by updating the web server. This tracks well with the mobile-first approach that many websites are already taking.
So, if these PWAs are so great, where are they? Most existing PWAs are just demo-level programs. Wikipedia has a list of some. Ginger is a WebGL morphing demo that gets the point across of how far the web has come since, well, Wikipedia. Note that, just as the PWA rules require, Ginger lets you add an app icon for itself to the home screen and runs without any browser, just like a native app.
Google’s major push for PWAs came at the 2016 Google I/O conference. Most of its materials on the subject still relate to that event. The company's PWA checklist is a good guide to what (Google argues) defines such an app. Its baseline requirements are:
- Site is served over HTTPS.
- Pages are responsive on tablets and mobile devices. (Google has specific time requirements for this.)
- All app URLs load while offline.
- Metadata is provided for add to home screen.
- First load is fast even on 3G.
- The site works cross-browser.
- Page transitions don't feel like they block on the network (really a variant on the responsiveness requirement).
- Each page has a URL (i.e., single-page apps beware).
That’s just the baseline. Among other things, an “exemplary” PWA:
- Dims the screen when a permission request is showing.
- Appropriately informs the user when they're offline.
- Loads very fast, even on 3G.
- In general, doesn’t annoy the user with excessive prompts and notifications.
If Apple is really resisting PWAs, it’s no longer a full-throated resistance. PWAs are not the talk of the tech town yet, but there is a certain inevitability to them. It makes sense. The day will come when you won’t have to go to the app store to get real, professional software for mobile devices. You might still want to, and Apple and Google will want you to, but it won’t be necessary. PWAs are yet another way technology will bootstrap innovation.
Progressive web apps: Lessons for leaders
- The advantage of PWAs is simplified development that applies across platforms.
- They rely on new standards that build on existing standards and technologies.
- PWAs are a logical extension of existing trends.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.