Progressive Web Apps: Escaping Tabs Without Losing Our Soul

It happens on the web from time to time that powerful technologies come to exist without the benefit of marketing departments or slick packaging. They linger and grow at the peripheries, becoming old-hat to a tiny group while remaining nearly invisible to everyone else. Until someone names them.

This may be the inevitable consequence of a standards-based process and unsynchronized browser releases. We couldn’t keep a new feature secret if we wanted to, but that doesn’t mean anyone will hear about it. XMLHTTPRequest was available broadly since IE 5 and in Gecko-based browsers from as early as 2000. “AJAX” happened 5 years later.

This eventual adding-up of new technologies changes how we build and deliver experiences. They succeed when bringing new capabilities while maintaining shared principles:

  • URLs and links as the core organizing system: if you can’t link to it, it isn’t part of the web
  • Markup and styling for accessibility, both to humans and search engines
  • UI Richness and system capabilities provided as additions to a functional core
  • Free to implement without permission or payment, which in practice means standards-based

Major evolutions of the web must be compatible with it culturally as well as technically.

Many platforms have attempted to make it possible to gain access to “exotic” capabilities while still allowing developers to build with the client-side technology of the web. In doing so they usually jettison one or more aspect of the shared value system. They aren’t bad — many are technically brilliant — but they aren’t of the web:

These are just the ones that spring to mind offhand. I’m sure there have been others; it’s a popular idea. They frequently give up linkability in return for “appiness”: to work offline, be on the home screen, access system APIs, and re-engage users they have required apps be packaged, distributed through stores, and downloaded entirely before being experienced.

Instead of clicking a link to access the content you’re looking for, these systems make stores the mediators of applications which in turn mediate and facilitate discovery for content. The hybridzation process generates applications which can no longer live in or with the assumptions of the web. How does one deploy to all of these stores all at once? Can one still keep a fast iteration pace? How does the need to package everything up-front change your assumptions and infrastructure? How does search indexing work? It’s a deep tradeoff that pits fast-iteration and linkability against offline and store discovery.

Escaping the Tab: Progressive, Not Hybrid

But there is now another way. An evolution has taken place in browsers.

Over dinner last night, Frances and I enumerated the attributes of this new class of applications:

  • Responsive: to fit any form factor
  • Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
  • App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
  • Fresh: Transparently always up-to-date thanks to the Service Worker update process
  • Safe: Served via TLS (a Service Worker requirement) to prevent snooping
  • Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
  • Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
  • Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
  • Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.

These apps aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins. They keep the web’s ask-when-you-need-it permission model and add in new capabilities like being top-level in your task switcher, on your home screen, and in your notification tray. Users don’t have to make a heavyweight choice up-front and don’t implicitly sign up for something dangerous just by clicking on a link. Sites that want to send you notifications or be on your home screen have to earn that right over time as you use them more and more. They progressively become “apps”.

Critically, these apps can deliver an even better user experience than traditional web apps. Because it’s also possible to build this performance in as progressive enhancement, the tangible improvements make it worth building this way regardless of “appy” intent.

Frances called them “Progressive Open Web Apps” and we both came around to just “Progressive Apps”. They existed before, but now they have a name.

What Progressive Apps Look Like

Taking last year’s Chrome Dev Summit site as an example, we can see the whole flow in action (ht: Paul Kinlan):

  1. The site begins life as a regular tab. It doesn’t have super-powers, but it is built using Progressive App features including TLS, Service Workers, Manifests, and Responsive Design.
  2. The second (or third or fourth) time one visits the site — roughly at the point where the browser it sure it’s something you use frequently — a prompt is shown by the browser (populated from the Manifest details)
  3. Users can decide to keep apps to the home screen or app launcher
  4. When launched from the home screen, these apps blend into their environment; they’re top-level, full-screen, and work offline. Of course, they worked offline after step 1, but now the implicit contract of “appyness” makes that clear.

Animation of the Progressive App installation of the offer and keep flow for Chrome Dev Summit.

Here’s the same flow on Flipboard today:

Progressive Apps are web apps, they begin life in a tab. Here we see flipboard.com in Chrome for Android with regular tab treatment
Progressive Apps are web apps, they begin life in a tab. Here we see flipboard.com in Chrome for Android with regular tab treatment.
When users engage with Progressive Apps enough, browsers offer prompts that ask users if they want to keep them. To avoid spaminess, this doesn't happen on the first load.
When users engage with Progressive Apps enough, browsers offer prompts that ask users if they want to keep them. To avoid spaminess, this doesn’t happen on the first load.
If the user accepts, the user's flow isn't interrupted.
If the user accepts, the user’s flow isn’t interrupted.
The app shortcut appears on the homescreen or launcher of the OS.
The app shortcut appears on the homescreen or launcher of the OS.
When launched, Progressive Apps can choose to be full-screen.
When launched, Progressive Apps can choose to be full-screen.
Progressive Apps are top-level activities in the OS's application switcher.
Progressive Apps are top-level activities in the OS’s application switcher.

The Future

Today’s web development tools and practices don’t yet naturally support Progressive Apps, although many frameworks and services are close enough to be usable for making Progressive Apps. In particular, client-side frameworks that have server-rendering as an option work well with the model of second-load client-side routing that Progressive Apps naturally adopt as a consequence of implementing robust offline experiences.

This is an area where thoughtful application design and construction will give early movers a major advantage. Full Progressive App support will distinguish engaging, immersive experiences on the web from the “legacy web”. Progressive App design offers us a way to build better experiences across devices and contexts within a single codebase but it’s going to require a deep shift in our understanding and tools.

Building immersive apps using web technology no longer requires giving up the web itself. Progressive Apps are our ticket out of the tab, if only we reach for it.

Thanks to Frances Berriman, Brian Kardell, Jake Archibald, Owen Cambpell-Moore, Jan Lehnardt, Mike Tsao, Yehuda Katz, Paul Irish, Matt McNulty, and John Allsopp for their review and suggestions on this post.

Cross-posted at Medium.

12 Comments

  1. Posted June 15, 2015 at 11:34 pm | Permalink

    +1 this is an excellent way forward. I like this much better than browsers asking me to install the native app on every visit.

    One thing I think we’ll need is a way for the app to ask the user for all the permissions it needs at once, similar to an app install.

    Mobile browsers also need to become a higher priority for the vendors, Apple especially. Each installed app needs dedicated resources and protection from the constant crashing that people experience currently. Oh and most importantly the browser needs to never refresh the page when coming back to the app, unless the user explicitly hits refresh. Today it’s like “hey just a quick little white flash to remind you this is just a website”. Perhaps this is another issue that service workers can help with. In which case the app should refresh every time it’s opened.

    p.s. there’s a typo in “code-based”.

  2. Posted June 16, 2015 at 1:51 am | Permalink

    Love this, and that Android experience of pinning and reopening looks great! We have the pinning side of it in Windows Phone, but it would be nice if the page then opened as a “top-level, full-screen” app. P.S. How did you make the GIF?

  3. Posted June 16, 2015 at 8:30 am | Permalink

    Seems similar to what Mozilla is doing with Firefox OS and web/apps there.

  4. Posted June 16, 2015 at 10:06 am | Permalink

    geddski: Fixed! Thank you.

    Stephen: that was all Paul Kinlan. Original post here.

    Rudolf: FF is working on the missing bits of their Progressive App story, e.g. Service Workers. What they chose to do about prompting or in some other way promoting these sites as being “appy” will be totally up to them. Can’t wait to see what they decide to do, but regardless, sites built in a Progressive way will deliver a great experience on FF regardless.

  5. Posted June 16, 2015 at 10:51 am | Permalink

    @Geddski said “One thing I think we’ll need is a way for the app to ask the user for all the permissions it needs at once, similar to an app install.”

    I’ve been thinking a lot about this (I’m on of the team working on this at Opera) and wondering about permissions.

    I’m no lover of Apple, but I find the iOS way of asking for permissions when they’re required rather than up-front to be generally better and, crucially, more Web-like, I can use some parts of an app and not the bits that require elevated permissions that way.

    Feels more ‘progressive enhancement” this way.

  6. Posted June 16, 2015 at 11:22 am | Permalink

    Nothing about the model I’m presenting here has any impact on permissions. Chrome’s implementation makes all permission runtime-requested.

    One of the things we’ve played with in the future is the ability to list some set of optional permissions in the manifest which might be present the user with UI at “keep” time. We haven’t done it yet, but it will always be a shortcut for the runtime requests, not a way to do non-optional permissions. Users can always revoke them; the web’s good that way.

  7. Posted June 16, 2015 at 11:56 am | Permalink

    Great article Alex! Minor error: the link on “Manifests” points to http://fberriman.com :)

  8. Posted June 16, 2015 at 1:21 pm | Permalink

    Thomas: thanks, and fixed!

  9. just a typo
    Posted June 19, 2015 at 4:00 am | Permalink

    just a typo: avocate, in your bio

  10. Posted June 25, 2015 at 11:41 am | Permalink

    Love this. I didn’t realize how much of this was in place. Not until I saw the screenshot with the caption of the the pinned app taking full screen I thought this was a futuristic vision of how should this work. But After trying this on Medium.com on Android, it’s actually pretty cool.

    I didn’t quite get the part where client-side technologies that are able to render on the server provide an advantage for this model? I would love to hear more about this and what frameworks/technologies you think is starting to address that?

  11. Posted June 25, 2015 at 11:48 am | Permalink

    @geddski @bruce this is also changing in Android M where permissions will be asked only when needed and not on install all at once. I think this is overall a good step, it might add a bit of friction the first time the permission triggers but it also removes a friction on first time use of the whole app and gives you a chance to explain why you need this permission better.

  12. Posted June 30, 2015 at 3:20 am | Permalink

    “I’m no lover of Apple, but I find the iOS way of asking for permissions when they’re required rather than up-front to be generally better and, crucially, more Web-like, I can use some parts of an app and not the bits that require elevated permissions that way.”

    100% agreed. I’m ok to give an “app” permission as and when I require it’s functionality.

    If anything, I’d prefer to determine when those permissions expire. Something like this:

    Grant permission for Facebook to:

    [x] access your camera
    [x] determine your location

    [ ] 1 Year [ ] 1 Month [ ] Today [x] This session

    [Cancel] [Grant now]

    Great article, by the way!