How can we help?

Design? Check. Strategy? Check. Bulletproof code? Check! People who can manage it in an agile and efficient manner? Check. Someone to help you create your next big product? Of course.

Denver

- 1201 18th St. Suite 250, Denver, CO 80202

Grand Rapids

- 125 Ottawa Ave NW Suite 270, Grand Rapids, MI 49503
BLOG:Progressive Web Applications -  The End of Apps, the Future of the Web?

Progressive Web Applications - The End of Apps, the Future of the Web?

App discovery, it’s a major issue with the current app marketplace on iOS and Android devices. Developers are faced with a continued decline in app installs and most users don’t install any apps in a given month. With an ever larger number of apps competing for the attention of users, anything you can do to reduce “friction” in installing new applications and getting users to interact with your content is a welcome opportunity. We’ve always had the ability to build mobile web applications that were easy to access via a simple URL. No app store approval process to get in the way. No requirement for users to find your application via app store search and risk them discovering the applications of your competitors while searching for yours. Instead just have the user visit your site and they’re all set.

Users who frequently access mobile content most often do so with an app, not with mobile browser-based solutions. As great as it is to link easily to content on the web and reduce install friction, the advantage is lost if the experience, once the user arrives, is poor. A major complaint with most mobile web experiences is around performance. Increases in web page size, presently averaging 2.4MB, are well publicized. Users have come to expect a rapid loading experience in native mobile apps; that is at least once the app is installed. But those mobile apps are getting bigger in size over time as well - often exceeding 20MB in size. Those ever larger install sizes for native applications create a point of friction as well. Especially as entry level 16GB iPhones or Android devices with as little as 8GB of storage remain popular. This poses an opportunity for progressive web apps, as they can provide an experience for those users reluctant to install your full native mobile application but want something more than the browser-based offerings of the past. Statistics show the mobile web continues to grow at a pace beyond app installs, particularly for applications users may not engage with on a daily basis. Take a look at your own phone - how many retailer specific mobile applications do you have currently installed? If you’re interested in knowing if a given item is in stock at a retailer, you’re far more likely to use a mobile web solution versus cluttering your phone with yet another app you might not use again for several weeks.

App Nirvana?

Progressive Web Applications (PWAs) aim to address some of the shortcomings of traditional mobile web applications. Progressive apps add functionality to mimic some of the capabilities of native applications based on the capabilities of the underlying browser and operating system. One way to speed load time for an application is to store more of it on the device so it’s ready to go the next time the user visits the app. With a PWA, the user has to sit through an initial load of the application, but that initial load time is likely smaller in size than that of a full native app. Speeding up that initial load can be done by using an App Shell architectural approach. That gets the basic foundation of your app up on the screen as soon as possible, likely before all the data loads. Cutting down the wait time keeps the user from getting frustrated while waiting for at least something to appear. The following diagram from Google shows how the “shell” of the application appears first and is then filled with content as soon as it’s available.

Screen Shot 2016-08-11 at 10.47.27 AM

The App Shell is a great way to speed that initial load, but we’re trying to get recurring visits to our content and make the repeat visitor experience mirror the type of performance a user might see on a traditional installed mobile app. The best way to do that is to keep your application on the device in storage, ready to be loaded at a moment’s notice as soon as the user returns. The loading and caching of content for future use is accomplished through the use of a service worker, which controls the way a web page loads so that it can be stored for use offline and rapidly present the application when the user visits again. Serving content locally like this makes the mobile web app behave like a regular installable app - it always works, even if the network connection is spotty or entirely unavailable. The service worker can cache not only the application code, but the data the app displays as well. Holding at least some of that data locally allows for offline operation which is another area in which mobile web applications have historically been very weak. What’s more, unlike a regular native app, the service worker can download app updates and app content in the background, so the next time the user runs your app, they’ll be running the latest version of your code. No need to worry about users who forget or just ignore traditional mobile app updates.

In the past, web applications didn’t seem much like mobile applications themselves; they were confined to the browser. Every experience you create via a mobile web application is surrounded by the browser UI. That makes them look more like web pages - not really like apps. Nor was it easy for the user to launch your web application from the app launcher / switchboard just like any other mobile app. Repeat visitors wanting an app-like experience expect to access your content the way they would any other mobile application. With Progressive Web Applications, this is done through a web application manifest. The manifest describes how your web application should be presented (with or without browser window controls), the device orientations supported (portrait / landscape / both), icon / launcher text for your app, etc. In the case of Google Chrome on Android, it automatically prompts the user to install the app (add it to the app launcher) as long as they visit your application twice with at least 5 minutes between visits. What’s more, you can defer app install requests and prompt the user to perform an install after they perform some activity or conversion on your site. The animation below shows the app install process of a PWA:

add-to-home-screen

One of the most successful ways to get users to repeatedly engage with your content is through push notifications. These can appear even if the app is otherwise not running and can encourage your users to re-engage with your application. Historically, push notifications were not available to traditional mobile web applications. Even apps that had fairly simple user interface requirements but needed push notification support were forced to package the experience into a mobile application and submit it for approval through the normal app store approval channels. Progressive Web Applications provide an alternative solution for this through the use of push notification support in service workers. My earlier IoT blog post on building a clothes dryer notification service showed how to implement push notifications on the web. Google provides a summary of this approach and offers tutorials on the subject.

PWA Case Studies:

Google has been showcasing several web properties that have been successful in building PWAs. One of my favorite examples is the Washington Post site. It shows how a service worker can be used to load an application and the article content in the background for an app-like experience. The resulting experience is quite fast and rivals the performance of reading the news on a typical native application, that is if you are running it on a browser that fully supports PWA features. There lies one problem with the site in that it’s not really a progressive solution, as it only works in mobile browsers that fully support PWA features. It won’t even work in a desktop browser like Google Chrome. A true progressive solution should gracefully degrade to support the capabilities of the user’s browser - not just display a banner encouraging them to look elsewhere:

Screen Shot 2016-08-11 at 1.23.53 PM

The application built as a guide to Google I/O 2016 also showcases PWA features including offline operation and service workers. One surprising statistic is that browsing sessions were 1.5 times longer for the mobile web solution versus the native Android application. In reviewing other case studies, companies found a significant lift in conversion rates, page views, and time spent in a session when incorporating PWA strategies into their mobile presence.

The challenges of PWAs:

As powerful as the techniques behind PWAs are, some issues remain. A big part of this is the elephant in the room: iOS support. While Chrome on Android supports the features needed, they are currently missing from mobile Safari on iOS with an unclear timeframe on when they might be implemented. Mobile Safari currently lacks service worker, web app manifest, and web push notifications support. On the other hand, Microsoft is working on adding service worker, web app manifest and push notifications to the Microsoft Edge browser on Windows 10. Microsoft is also planning to treat PWAs as installable applications via the Windows Store which can further aid in discoverability. With PWA support extended to Chrome on multiple platforms (macOS, Windows, Linux, Android, ChromeOS), and Microsoft planning to offer support as well, Apple may have little choice but to support these features to ensure iOS remains a competitive web experience. Apple has shown its willingness to enhance mobile Safari to support new web features in the past and given the impact that features like service worker caching can have on performance, I fully expect it to eventually land on iOS. In the meantime, developers should remember to include these features as a progressive enhancement but not shut out users whose mobile platform has not yet added support for them.

At the moment, even with PWA support, these are still very much web applications. They inherit the limitations of browser-based solutions including a UI that often does not perform as quickly as a pure native application and has limited access to some native functionality. Remember, this is still a browser-based solution - there are no plugins to call native code like in a Cordova or PhoneGap application. As a result, PWAs aren’t really a replacement for traditional mobile apps - at least not for some types of applications. Instead, existing websites should consider incorporating PWA techniques to increase mobile engagement especially for users who are reluctant to install a complete application to access your content. The Washington Post PWA solution shows that for typical applications that involve mostly content consumption, a PWA may be entirely sufficient. As web traffic continues to migrate from the desktop to mobile devices, you should plan to progressively leverage features in your web solutions that make the experience for mobile users the best it can possibly be, recognizing that not everyone wants to install a traditional app.