“Why would someone add this banner to their website?!” asks Ada Rose Edwards:

Ada Rose 🏳️‍🌈✊🏾🌍 on Twitter

Why would someone add this banner to their website?! Embrace the web it is good. Tumblr web is great.

That question spawned a ~40 tweet conversation that some folks asked to see written up here.

Before we get to that, and by way of disclaimer, we don’t have any insight into the specific thinking of the Tumblr team. For all we know they’ve done all the experiments and found the native app a better investment. It’s possible! Regardless, the past few years of working with teams that are at various points on a journey towards Progressive Web Apps has uncovered some patterns and it seems as likely as not that Tumblr is on a similar journey (whether or not they know it).

So why do sites add banners like these? The short answer is growth. The desired form of growth might be increased loyalty, engagement, or use. Sometimes it’s user-base growth, although that instinct has waned among savvy product managers now that the App Store gold rush has definitively ended. This sort of desired deeper engagement gets phrased in many ways: “a better experience”, “faster”, “keeps you up to date” (code for push notifications), etc.

Engagement and recall are valuable commodities in an attention economy. The platform wars that have followed are a result. Product owners and managers often view their websites (if they have them) as the “top of the funnel”; a way to build awareness of the final product or provide a try-before-you-buy version of the “real” experience.

This makes sense, historically speaking. Until Progressive Web Apps arrived, it wasn’t possible to engage users who wanted more of a service in all the ways that native apps could. The lack of push notifications and a presence on the homescreen stunted engagement. Lack of meaningful offline behavior meant it was natural for services and users to choose the native app route once they decided a service was worthwhile.

The trajectory of many businesses adapting to mobile looked like this:

1. Pretend their desktop website is fine because pinch/zoom
2. Invest in “responsive” without slimming down JS, ad, image, or third-party content — or worse, adopt services that “adapt” existing sites using blocking script tags.
3. When that (inevitably) doesn’t work, experiment with native apps
4. Early numbers from native apps look good, particularly regarding engagement vs. bad mobile web experience
5. ALL IN ON NATIVE!!!!
6. Discover the distribution wall: it’s blindingly expensive to drive native app installs if you aren’t #1 in your market
7. Investigate modern mobile web options

We tend to work with teams who are at steps 6 or 7; any earlier than that and the conventional wisdom makes it nearly impossible to get traction. The conventional wisdom is strong for a few reasons:

• “Market leaders have native apps and it’s working for them, so why not us?”
• Early engagement numbers from native apps are strong
• Structural challenges to learning that native apps aren’t working
• Android blindness

Ignoring the false equivalence between not-Facebook (everyone, basically) and Facebook (who can afford to develop infinite versions of a service to reach a marginally larger audiences and leverage existing installed base to drive cheap installs), services that experiment with native apps do tend to see increased engagement vs. “responsive web” sites. This follows from the historical feature gap but also from a more subtle effect: users who are willing to sit through a native app download, install, and ongoing update tax are likely to already be heavily engaged with a service.

Unless product managers are unusually scrupulous in segmenting and tracking which users adopt native apps, the prompts and overlays (like the one Ada Rose Edwards flagged) can simply be zero-sum transfers of engaged users from one version of a service to another. Even rarer are true A/B comparisons: funding both PWA and native app development and comparing engagement between them.

Teams we’ve worked with have reported similar engagement between those who install PWAs and those who install native apps, but the friction of PWA installation is much lower. Our internal metrics at Google show that for similar volume of prompting for PWA banners and native app banners — the closest thing to an apples-to-apples comparison we can find — PWA banners convert 5–6x more often. More than half of users who chose to install a native app from these banners fail to complete installing the app whereas PWA installation is near-instant.

Sadly, few sites are willing to go on the record about native vs. PWA engagement. If you’d discovered a more effective way to engage with users at lower cost would you be telling your competitors about it? There are also organisational pressures not to embarrass colleagues who may have pitched and developed native apps.

This leads us to structural challenges, which are perhaps the least talked about effect. Organisations that have legacy web sites frequently developed native apps in separate teams, out of separate budgets, often with separate goals. It isn’t uncommon for native app development to have been outsourced and funded out of speculative funds, e.g. marketing or R&D, with the reasonable understanding that it takes time to grow anything. Unfortunately, this siloing often leads to long learning cycles. Native app teams may learn how to grow their user base, but businesses too often are blind to the overall picture. Is growing your native app actually growing the business? It takes a real dedication to honest business metrics to even begin to tease this out and look at long term value vs. short-term metric growth. As with website bounce rates, many who visit will not stay, and unlike websites, and native apps are vastly more expensive to distribute. Some businesses are so far in denial about this that when you ask them if they pay for native app distribution, they’ll (unironically) say things like “no, we don’t pay for app installs, but we do provide discounts and offers that are only available in the app.”

Everybody “knows” that native apps work, after all, and some persist well after they hit the wall in terms of cost/benefit to native app distribution. It’s easy to get promoted by pointing to big numbers, and it is possible to grow your install base. Expensive, perhaps ruinously, but possible. Businesses can go years without learning the true cost/benefit of native app strategies — sometimes learning only in a darwinian sense.

Those that can learn on shorter time scales face a final hurdle: Android blindness.

Nearly all product owners, decision makers, and influencers (board members, VCs, etc.) in wealthy western countries carry iOS devices. Most have never seriously used an Android device. Because Apple hasn’t implemented PWA technologies in Safari and functionally prevents others from doing so, the expectations of iOS users regarding the web are set low.

The future is here, the rich just don’t have access to it. Those with the fastest hardware on the best networks simply cannot envision what a more capable web could do for their products because they’ve never experienced it. It’s unsurprising, then, that PWAs are getting built and succeeding in geographies where developers and decisions makers carry the same phones as the majority of users in almost every country on the planet. For more, see Bruce Lawson’s series on the World Wide Web, Not Wealthy Western Web.

Some businesses make it to steps 6 and 7 on the timeline above and are receptive to (or seek out) better strategies for getting users access to their services. The set of folks doing this and collecting truly comparable data is small. The set willing to share the data is even smaller. But let’s say your team wants to try, how do you actually conduct a real comparison?

It may take time and effort. To get a real comparison point, you need experience equivalence. A site that’s drowning in JavaScript won’t attract or retain users:

To really get comparable data, you’ll need to build a high-quality PWA using mobile-first tools like Polymer App Toolbox, Preact, Vue.js, Skatejs, or Svelte. If you’re a developer, your favorite tool probably isn’t in that list. There’s a reason: the constraints of mobile are much, much harder than we have collectively come to terms with. Most JavaScript libraries are suffering the lingering effects of desktop-era assumptions and have not made the radical shifts necessary to deliver great experiences on mobile. Folks using these tools must go to extraordinary lengths to make them perform in this environment.

So let’s say you’ve built a modern PWA that works brilliantly offline, gets a great Lighthouse score, loads the first time in less than 5s on webpagetest.org/easy on the Emerging Markets profile and less than 3s for repeat views. Let’s also assume you’ve implemented web push. Congrats! You’re setup to run a real-world A/B test with your native Android app. From this starting point you can actually compare the engagement of users who opt in to adding to the homescreen or agree to receive push notifications. You’ll also be able to compare the costs of acquiring and retaining these users.

What can you expect? As mentioned earlier, few firms have been willing to share their data on this. Those that have report astonishing comps: Selio reported a 10X lower cost to acquire an activated user (someone that has sent a message or made an offer) via their PWA than their Android app. Housing.com reported it was 50x cheaper to get a user experiencing their service when clicking an ad for the PWA vs. a native app. The “progressive” in PWAs matters: you don’t have any up-front hurdle to using your app with the web; a single link is enough.

Are these outliers? We don’t yet know for certain, but we do know that users are much more likely to accept a PWA request to “Add to Homescreen” than they are to install native apps.

None of this may be relevant to your site or business. Some sites don’t want or need users to return. Some apps aren’t possible on the web today due to technical limitations (though we’re chewing through that list quickly). Some markets have unusually high iOS penetration (e.g., Japan), making PWA ROI a smaller opportunity. Or perhaps you work for Facebook and already have high app penetration which you can use to drive low-cost installs of sibling apps. Or perhaps the early data is all a fluke!

But there’s reason to believe it’s not. PWAs are improving business outcomes for Flipkart, AliExpress, Konga, Suumo, Alibaba, Housing.com, and, yes, even Facebook. Last month’s launch of Twitter Lite is another vote of confidence that these experiences can compete on their own terms. It’s an exciting time to be working on the web platform, and like our colleagues on native app teams before us, PWA teams are springing up as side-projects and insurgencies inside organisations that are primed for change. The largest brands that have launched PWAs have done so with surprisingly small and scrappy teams. Not only is it not impossible to build them, it’s frequently cheaper than the alternative. Wego built their truly excellent PWA in 3 months with Polymer App Toolbox and one Android engineer who had never built for the web before.

Thanks to great tools like Polymer App Toolbox and improving documentation, teams today are only being held back by a lack of willpower. Luckily, the case is getting easier to make every day as more and more examples pour in. Seriously, check out these stats!

It’s our hope that as we show business and decision makers how much better the web is for their bottom lines, we can improve the experience of computing for everyone.

Why Are App Install Banners Still A Thing? was originally published in Dev Channel on Medium, where people are continuing the conversation by highlighting and responding to this story.

He’s also right that what browsers give users and developers by implementing support for Progressive Apps (like Chrome and Opera have and which Mozilla is considering) is access to this differentiated UI treatment. It sure does sound flimsy! I mean, once a browser has support for Manifests and Service Workers, it’s just a bit of UI that lets you hide things like the default URL bar…what’s important about that? Everything, turns out.

UI treatment was the carrot that enabled SSL adoption and UI treatment is what will eventually sunset unencrypted network connections. These indicators are shown (or not) when developers do the right thing by users, and the browser is the guarantor of the user’s interests.

To users, the tech isn’t the product, the experience is. Andrew’s post captures this, but at the risk of being quarrelsome, seems to skip from initial window treatment (which we agree is important to “appyness”) to dismissing long-term experience differentiators like offline behavior and connection security which matter in the breach, not the norm. He’s also simply confused about search ranking changes: Google, to the best of my knowledge, doesn’t treat Progressive Apps any differently. Mobile-friendly, secure, fast sites? Sure. But those are attributes of any web experience (recall that all Progressive Apps begin life as regular pages). There’s no separate ranking boost (or demotion) for building a Progressive App.

Which leads us to the bit of Andrew’s post where he’s simply confused. I won’t dwell on those aspects because I feel it’s simply the result of misunderstanding, which knowing Andrew, will soon be corrected. Briefly, though: Andrew misunderstands the role of signals in search ranking, manifests, and Service Worker scopes. They are each potentially complicated topics. I probably owe more words on each, but TL;DR: the control over window focus that Andrew wants is coming via new Service Worker APIs. His concerns (when not unfounded) are going to be addressed (at least in Chrome).

Every browser is likely to implement their own version of Progressive Apps. It’s a general pattern (like “AJAX”), not a specific implementation. Chrome has set the hurdles to getting appy UI treatment at one particular point (TLS, Service Worker for offline, Manifest); others can do differently, but it is unlikely to make sense to do so.

In the same way that it’s a bad idea to provide a green lock icon for a fundamentally insecure site, it’s a bad experience for end users to offer an appy install flow for something that’s likely, in the user’s view, to “fail” as an app when disconnected, on MITM’d WiFi, or when the app doesn’t provide a high-quality icon. You’d hope never to find content with those negatives featured in an app store so browsers have incentives to ensure that users only upgrade sites that will prove equivalently useful when launched as apps.

By focusing on some corner cases (e.g. manifests that signal a desire to open in a tab), it’s possible to cast the ambiguities built into evolving a stable platform in pretty much any light you want. The “progressive” bit in Progressive Apps admits many evolutionary intermediate points. Andrew’s right that Progressive Apps are about incentives, but what the term calls out is a pattern that helps users discover things that embody (on average) a particular package of features that deliver long-term value. Not everything will make the cut, and that’s OK. The old web isn’t going away, but that doesn’t mean we need to pretend it has cleared these experience hurdles. Drawing the distinction is good for users, and that’s all that matters.

Vendor prefixes are a very sore topic, and one where I’ve disagreed with the overwhelming consensus. In the heat of the ‘11–12 debate (a.k.a. “prefixpocalypse”) I tried to outline a rough hierarchy of the web platform’s concerns:

1. Meeting developer & user experience needs with new features
2. Eventual interoperability for successful features
3. Minimizing harm to the ecosystem from experiments-gone-wrong

The debate and subsequent (conflicting) prohibitions & advice centered on the third point: minimizing pollution.

Recall that in 2012, Google, Apple, Blackberry, and a host of other vendors were all shipping browsers based on a single CSS engine (WebKit) without changing the `-webkit-*` prefixes to be vendor-specific. Instead, a large proportion of the web’s users experienced premature compatibility for experimental features. Developers could get the benefits of broad feature support without a corresponding standard. This backed non-WebKit-based browsers into a terrible choice: “camp” on the other vendor’s prefixed behavior to render content for their users or suffer a loss of users and developer loyalty.

This illustrates what happens when experiments inadvertently become critical infrastructure. It has happened before. Over, and over, and over again.

Prefixes were supposed to allow experimentation while discouraging misuse, but in practice they don’t. Prefixes “look” ugly and the thought was that ugliness — combined with an aversion to proprietary gunk by web developers — would cause sites to cease using them once standards are in place and browsers implement. But that’s not what happens.

Useful features that live a long time in the “experimental” phase tend to get “burned in”, particularly if the browsers supporting them are widely used. Breaking existing content is the third rail for browsers; all of their product instincts and incentives keep them from doing it, even if the breakage comes from retracting proprietary features. This means that many prefixed properties continue to work long after standard versions are added. Likewise, sites and pages that work with prefixes are all-too-easy for web developers to write and abandon. It’s unsettling to remove a prefix when you might break a user with an old browser. Maintenance of both sites and browsers rarely subtracts, but the theory of prefixes hinges on subtraction.

Everyone who uses prefixes, both browser engineers and web developers, start down the path thinking they’ll stop at some point. But for predictable reasons, that isn’t what happens. Good intentions are not an effective prophylactic. Not for web developers or browser makers (to say nothing of amorous teens).

This situation is the natural consequence for platform/developer time-scales that are out of sync. Browsers move more slowly than sites (at the micro scale), but sites must contend with huge browser diversity and are therefore much more conservative about removing “working” code than browser engineers expected.

Now What?

Years after Prefixpocalypse everyone who works on a browser understands that prefixes haven’t succeeded in minimizing harm, yet vendors proudly announce new prefixed features and developers blithely (ab)use them. Clearly, a need for new features trumps interoperability and pollution concerns. This is natural and, perhaps even healthy. A static web, one which doesn’t do more to make lives better is one that doesn’t deserve to thrive and grow. In technology as in life there is no stasis, only various speeds of growth or decay.

Browsers could stop prefix ecosystem pollution from happening by simply vowing not to add features. This neatly analyses the problem (some experiments don’t work out, and some get out of hand) and proposes a solution (no experimentation), but as H.L. Mencken famously wrote:

…there is always a well-known solution to every human problem — neat, plausible, and wrong.

We have already run a natural experiment in this area. At the low point after the first browser war, Microsoft (temporarily) shrink from the challenge of building the web into a platform. Meanwhile IE 6’s momentum assured its place as the boat-anchor-browser. Between 2002 and 2006, the web (roughly) didn’t add any new features. Was that better? Not hardly. I’m glad to be done with 9-table-cell image hacks to accomplish rounded corners. Not all change is progress, but without change there is no progress.

Or, put better by W3C Memes:

We do need new features, and we’d like good versions of them — fewer document.alls, WebSQLs and AppCaches, thanks.

We know from experience developing software of all kinds that more iteration yields better results. Experimentation, chances to learn, and opportunities to try alternatives are what separate good ideas from great products. Members of the Google Gears team report they considered building something like Service Workers. Instead they built an AppCache style system which didn’t work in all the ways AppCache didn’t work (which they couldn’t have known at the time). It shouldn’t have taken 6+ years to course-correct. We need to be able to experiment and iterate. Now that we understand the problems with prefixes, we need another mechanism.

Experiments That Stay Experiments

Prefixpocalypse happened because experiments escaped the lab. Wide-scale use of experimental properties isn’t healthy. Because prefixed properties were available to any site (not matter how large), it was straightforward for the killer combination of broad browser support and major site usage to ensure that compatibility would work against ever ending the experiment. The key to doing better, then, is to limit the size of the experimental population.

The way prefixes were run was like making a new drug available over the counter as soon as a promising early trial was conducted, skipping animal, human, and large-scale clinical trials. Of course that would be ludicrous; “first do no harm” requires starting with a small population, showing efficacy, gathering data about side-effects, and iterating.

In the web platform, the missing ingredient has been the ability to limit the experimental population. Experiments can run for fixed duration without fear of breaking the web if we can be sure that they never imperiled the whole web in the first place. Short duration and small, committed test populations allow for more iteration which should, in the end, lead to better features. The web developer feedback needs to be the most important voice in the standards process, and we’ll never get there until there’s more ability for web developers to participate in feature evolution. Experimental outcomes are ammo for the standards development process; in the best-case they can provide good evidence that a feature is both needed and well-designed.

Putting evidence at the core of web feature and standards development is a 180° change from the current M.O., but one we sorely need.

So how do we get there?

Some mechanisms I’ve thought through and rejected (with reasons):

• “Just have users flip things in about:flags”
  This has several persistent downsides: first, it doesn’t limit the size of the experimental population. If every site encourages users to flip a particular flag, odds are enough users will do so to set usage above a red-line threshold.
• “Enable it by default on your Beta/Dev channel browser”
  Like the flag-flipping mechanism, it puts a burden on users which is perhaps the wrong place to put it. Experimentation of this sort is likely to get better feedback when developers can work with experimental features without the additional friction of asking users to use different browsers.

The Chrome Team has been thinking about this problem for the past several years, including conversations with other vendors, and those ideas have congealed into a few interlocking mechanisms that haven’t been rejected:

1. Developer registration & usage keys.
   A large part of the reason it’s difficult to change developer behavior about use of experimental features is that it’s hard to find them! Who would you call to talk about use of some prefixed CSS thing on facebook.com? I don’t know either. Having an open communication channel is critical to learning how features are working (or not) in the real world. To that end, new experimental features will be tied to specific origins using keys vended by a developer program; sites supply the keys to the browser through header/meta tags, enabling the features dynamically. Registration for the program will probably require giving a (valid) email address and agreeing to answer survey questions about experimental features. Because of auto-self-destruct (see below), there’s less worry that these experiments will be abused to provide proprietary features to “preferred” origins. Public dashboards of running experiments and users will ensure transparency to this effect.
2. Global usage caps.
   The Blink project generally uses a ~0.03% usage threshold to decide if it’s plausible to remove a feature. Experimenters might use our Use Counter infrastructure and RAPPOR to monitor use. Any feature that breaches this threshold can automatically close the experiment to new users and, if any individual user goes above ~0.01% (global) use, a config update can be pushed to throttle use on that site.
3. Feature auto-self-destruct.
   Experimental features should be backed by a process that’s trying to learn. To enable this, we’re going to ensure that each version of an experimental feature auto-self-destructs, tentatively set at 12–18 weeks per experiment. New iterations which are designed to test some theory can be launched once an experiment has finished (but must have some API or semantic difference, preferably breaking). Sites that want to opt into the next experiment and were part of a previous group will be asked survey questions in the key-update process (which is probably going to be a requirement for access to future experimental versions). Experiments can overlap to provide continuity for end-users who are willing to move to the next-best-guess and provide feedback.

We’re also going to work to ensure that the surfaced APIs are done in a responsible way, including feature-detection where possible. These properties add up to a solution that gives us confidence that we can create Ctrl-Z for web features without damaging users or sites.

In discussions with our friends in the community and at other browser vendors we’ve thought through alternative ways to throttle or shrink the experimental population: randomness in API names, limiting APIs to postMessage style calling, or shortening experiment lifetimes. As Chrome is going first, we’ll be iterating on the experimental framework to try to strike the right balance that allows enough use to learn from but not so much that we inadvertently commit to an API. We'll also be sharing what we learn.

My hope is that other browsers implement similar programs and, as a corollary, cease use of prefixes. If they do, I can imagine many future areas for collaboration on developing and running these experiments. That said, it’s desirable to for different browsers to be trying different designs; we learn more through diversity than premature monoculture.

Moving faster and building better features don’t have to be in tension; we can do better. It’s time to try.

Thanks to Owen Campbell-Moore, Joe Medley, Jeff Yasskin, Adrian Bateman, Jake Archibald, Ian Clelland, Michael Stillwell, Addy Osmani, and Chris Wilson, and Paul Irish for their invaluable feedback on drafts of this post.

Cross-posted from my personal blog.

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:

• Adobe AIR Applications
• Windows Store Apps
• Chrome Packaged Applications
• Firefox OS Packaged Applications
• Cordova/PhoneGap and Crosswalk Apps
• BlackBerry WebWorks Apps
• W3C Widgets (these enjoyed several implementations)
• WebOS Apps
• Chromium Embedded Framework
• Electron

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 require packaging and distributed through stores, implying that they must be downloaded entirely before being experienced.

Instead of clicking a link to access the content you’re looking for, these systems make stores the mediators for discovery of 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 Web Apps”. They existed before, but now they have a name.

What Progressive Web 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.

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.

When users engage with Progressive Web 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.

The app shortcut appears on the homescreen or launcher of the OS.

When launched, Progressive Web Apps can choose to be full-screen.

Progressive Web 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 Web Apps, although many frameworks and services are close enough to be usable for making Progressive Web 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 Web 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 Web 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.

Originally published at infrequently.org on June 15, 2015.