loading...

Install This PWA To Continue

samthor profile image Sam Thorogood ・3 min read

Blog-A-Day in June (19 Part Series)

1) Rebuild only when necessary in Node 2) Civilization is a game you never lose 3 ... 17 3) Arrow functions break JavaScript parsers 4) Detecting Select All on the Web 5) Declaring JS Variables in 2019 6) Sam's dotfiles highlights 7) Automate Reading Form Results with 🤖 Chrome 8) Beyond appendChild: Better convenience methods for HTML 9) AMA, Sam 10-yr Googler in Web DevRel 10) Disable a HTML form while in-flight using fieldset 11) PWAs that download like apps 🗜️ 12) Matching elements with selectors in JS 13) Install This PWA To Continue 14) Google Assistant now supports "Open/Close" devices 15) Modern Web Components 16) What To Expect When You're Expecting To Drop IE11 🗑️ 17) Divert Vertical Scroll To The Side ↔️ 18) Graceful Shutdown Is A Lie 19) Progress Indicator With Fetch

On mobile devices running iOS 11.3+ and modern Chrome- so, basically everyone in the western world- you can have a PWA added to your phone's home screen. This is a great and admirable goal, but getting there can be challenging. 🤔

Santa Tracker as a PWA

What if ...

What if you insist your users do this action before they receive you app? This would never make sense for content sites: wikis, news articles, etc al, and honestly is likely an anti-pattern in many cases; but it could make sense for cases such as:

  • games
  • 'app-like' experiences
  • tools which you as a user are locked-in to (say, an expense reporting application for your company).

The last case is particularly interesting. By asking your users to "install" the app via the web, you may actually absolve some FUD along the lines of "oh, it MUST be an app".

Must Install

Implementation Theory

There's a few ways to detect an installed PWA. On iOS, it's simple: we can look for the navigator.standalone property: it's truthy when a page is launched from the homescreen.

On Android, we have a couple of options. The first, and simplest, is to configure the URL that your site loads when it's installed. If you're building a PWA, you'll have a Web App Manifest- commonly named manifest.json or manifest.webmanifest. When a user is prompted to install your PWA, the URL that goes to the homescreen is actually set by the start_url field:

{
  "name": "You Must Install!",
  "short_name": "Installed!",
  "display": "standalone",
  "start_url": "/?homescreen=1",  // set a query we can detect
  ...
}

The second option is that if your site is display: standalone- which removes the URL bar, giving your PWA an app-like experience- you can check for this via CSS.

Implementation In Practice

Our final JS method looks like this:

function isInstalled() {
  if (navigator.standalone) {
    return true;  // iOS
  }
  if (window.matchMedia('(display-mode: standalone)').matches) {
    return true;  // Android with "display": "standalone" in Manifest
  }
  if (new URL(window.location).searchParams.has('homescreen')) {
    return true;  // fallback to check for "?homescreen=1"
  }
  return false;
}

Now, you could use this method to control site loading and actually insist that a user installs before continuing.

Practical Concerns

On both major platforms, we can't really force an install prompt, or know that we can reliably trigger its flow through a button or user interaction.

On iOS, it's (as of 2019) not technically possible at all.

On Android, an engagement metric is used to prompt a user to install, and your site can also use onbeforeinstallprompt to better control that prompt.

This metric is incredibly useful. As web users, we know that the endless "allow notification" prompts are incredibly frustrating. Adding "install" prompts, without any engagement control, would just be adding fuel to that fire. 🔥

What this boils down to is that on both platforms, this whole proposal would force you to display a message saying "click around on your platform's UI to 'Install' before use". So our thought experiment, while interesting, might not be practical. 👎

Thanks

Thanks for coming on this journey with me! 💭

14 👋

Blog-A-Day in June (19 Part Series)

1) Rebuild only when necessary in Node 2) Civilization is a game you never lose 3 ... 17 3) Arrow functions break JavaScript parsers 4) Detecting Select All on the Web 5) Declaring JS Variables in 2019 6) Sam's dotfiles highlights 7) Automate Reading Form Results with 🤖 Chrome 8) Beyond appendChild: Better convenience methods for HTML 9) AMA, Sam 10-yr Googler in Web DevRel 10) Disable a HTML form while in-flight using fieldset 11) PWAs that download like apps 🗜️ 12) Matching elements with selectors in JS 13) Install This PWA To Continue 14) Google Assistant now supports "Open/Close" devices 15) Modern Web Components 16) What To Expect When You're Expecting To Drop IE11 🗑️ 17) Divert Vertical Scroll To The Side ↔️ 18) Graceful Shutdown Is A Lie 19) Progress Indicator With Fetch

Posted on by:

samthor profile

Sam Thorogood

@samthor

Developer Relations for Web at Google.

Discussion

markdown guide
 

Forcing users to install a PWA for most sites would lead to me not using them, and I assume the same from most people.

I can see the benefit for internal company pages/applications and I feel that this is the best way to go about it. I am cautious with PWA's, I dont feel that most people will want to use them and being prompted at every site will lead to a stigma by the community before they reach their full potential.

 

being prompted at every site will lead to a stigma by the community before they reach their full potential.

Oh man, I think this is exactly what happened with web push notifications. It fits into this PWA concept, but I think web push notifications could be really cool and have some fun use cases!
However everyone throwing up notification prompts has totally annoyed lots of people I know into hating web push notifications

 

Yup, my opinion on this is that browsers aren't going far enough with the notion of "engagement metric". Add To Home Screen on Android only shows up after a couple of visits—notifications should have at least been done the same way.

I think that there's often a disconnect between user intent (when I want to use a site) and being cautious about permissions and features.

Email is my example for this: literally anyone can email you (regardless of whether you asked), and your provider (statistically Gmail) has to work out if that email is wanted or not. As a user, I don't have a way to say to Gmail—yes, I do want this email or to be on mailing list or whatever, especially if the email actually ended up in Spam and I didn't see it.

 

btw in Chrome Canary Desktop there's now an install-prompt for PWA. Works with Dev.to, too.

I see some sense in being able to spawn websites to my Desktop or Home-Screen for heavily used sites. Like a super-bookmark. This may also be a news-site, or a docset I'm currently using.

 

I think a better alternative would be to limit some features to PWA installed apps. So that you can, for instance, tell the user to install the app to take advantage of offline support (even if it could work even in the browser)