Web app installs: Why, when, how

Penny McLachlan at Code '21
Sign up for Conffab Pro to watch this and hundreds of other videos for 19.95 a month

Hi, everyone.

Thanks for watching.

The session today is on web app installs-the why the when and the how.

If you haven't been completely deafened by the buzz of apps over the past decade, I would love a pair of your noise-canceling headphones.

The word app is now a standard lexicon for all users, both technical, and non-technical almost everywhere in the world.

For the multi-touch generation, apps are basically synonymous with a digital experience.

But what fundamentally our apps, it might seem obvious, but is it really?

What is the distinction between a website and an app?

This won't be a shock, but there isn't really an authority for what an app really is.

All we can do is try and list out some of the common properties.

So here's a few properties of a website.

You might notice that these are all pretty desirable properties in the right circumstances.

And there are also some of these properties that are true some of the time, but not all the time.

And these are marked in gray.

So for example, the web can run on pretty much any device quick to open and use.

Hopefully if you're designing your website well.

It can open from the browser.

Or of course it can run as a standalone window.

It might work offline if you've done some extra work to make it do that, or it might not in most cases still not, unfortunately.

We hope more website support offline soon.

And, it may not be specifically optimized for the layout of the device.

So it will, might have break points, but they're fairly generic.

It's not saying, you know, this is the screen is laid out in this exact aspect ratio.

And finally, a website is linkable.

Let's compare that to an app.

Usually these are ecosystem specific.

Of course you can use cross-platform frameworks.

Typically apps are downloaded and installed.

Although instant apps are a thing.

Apps can be opened from launchers and files.

It feels like it runs independently.

It doesn't need like some server somewhere to work.

Typically has its own window, works offline and it often has powerful capabilities, the system access.

And it may or may not be linkable.

Let me touch back on that offline common [unclear] for a moment because like many apps just have a very simple offline, you know, this app needs connectivity in order to work and that's fine.

That counts as offline.

So there's one more thing I want to add here.

Which is how our user feels about these two different types of experiences.

I believe that users tend to feel that they are just visitors on a website and we reinforce this perception with the words we use.

On a website, you are a visitor, but on the other hand, you "get" an app.

Getting implies that it belongs to you.

Now, I think we all understand that data in an app can also live in the cloud.

Just like data in a website can live in the cloud.

And data in the website could also be local and data in an app can also be local.

But the words we choose has implications for how users think about these things.

And I really do think that users think about a website as something that they use and an app is something that they own or possess.

Let's talk for a moment about web apps.

Some of you might be old enough to remember this little beta app called Gmail.

So why are we taking this trip down memory lane?

Well, because it illustrates a point really nicely.

When Gmail came out, there were lots of other email clients.

In fact, pretty much everyone who had a computer had an client already installed on it.

This was the internet's first real killer app.

In fact, not only were there lots of other email apps out there, but most of them had honestly more and better features than the first release of Gmail.

So why was it that Gmail and other web-based email clients that came out at the time able to get so much market share.

And the answer is that because it was universally linkable, shareable.

It was nearly instant to load.

It was safe and relatively private.

That means that even if you had a shared computer inthe household for example, everyone could have their own private email account.

Email's come a pretty long way since then.

But 20 years ago it had what it took to win market share from extremely popular and common email clients.

So how does that apply to progressive web apps and how we think about this app versus web stackup?

A Progressive Web App is an installable web application.

It uses modern APIs and as an installed application, it can appear on the device's launching services, including the activity switcher, content sharing surfaces, et cetera.

And it can also work offline.

It can run services in the background and it can access device hardware such as Bluetooth or the file system.

So what my team and I are trying to accomplish is to increase the power of web apps, pushing into capabilities that were previously reserved for native apps.

Coming back to the Gmail example.

There's this question of, can we ever achieve parity?

And I get asked this a lot and the answer is probably not.

There is a law of diminishing returns to consider.

We get into more and more esoteric functionality that gets more and more expensive to manage and maintain, but here's the thing: does parity really matter?

G-mail didn't need to be exactly the same as those desktop based email clients in order to compete.

It was able to compete just fine with its own merits.

It just needed enough capabilities such as webXHR in order to be able to do dynamic loading.

And like once it had those capabilities, it was able to do a job that was competitive, even though the benefits of using it implied trade-offs.

I'll be the first to admit it's been a bit of a strange journey getting us here, Apple bet big on web apps with the launch of the iPhone.

I mean, there were no native apps on early iPhone models.

Now a native App preference might be strategic for them.

There are undoubtedly cases where a native app is the right choice, but is this really the case for all, or even most apps?

Does a parking app or a finance app really benefit from being native?

I think what we want to do is get to a world where you can get the best of everything.

And that's really what PWAs are here to give us.

We want to bridge these gaps into a seamless experience that can work in a browser tab and an ephemeral linkable universal way, and then it can be installed and it can take advantage of operating system UI affordances, like sharing the activity switcher and launching surfaces such as the home screener or the start menu.

So let's talk about one incredibly powerful capability of web apps that works almost everywhere.

Yes.

I know it's a little early for Christmas, but I do love this animation.

The fact is you really can install a web app now on all of your devices.

Go ahead and give it a try.

If you'd like: YouTube and Reddit are both installable.

For example, on Windows, Mac, and Linux devices.

Web Install offers users access to web apps from familiar discovery launch surfaces on the device.

And of course these apps can be standalone.

So they're totally separate from the browser.

They use the native task switcher and, you know, this may be more familiar to some users or more suitable than tabs for some types of activities.

Web Install integrates Web apps with device services that expect an installed app.

Here's the important thing to remember when you're asking your users to install your PWA.

With an installed app, you are telling your users that this is an experience that was meant for their device.

And that does mean that you need to live up to those expectations.

So you want to follow design patterns that are going to give not just an installable app, but an installable app with a UX that's going to look and feel like it belongs on the device the user is running it in.

Your basic requirements for supporting the installable web are to have both a web manifest and a service worker.

These are actually in the year 2021 are pretty well-documented now.

These are the same requirements to be classified as a PWA.

I'm going to be covering mostly the manifest.

For the service workers, the requirement for install is that you do load offline.

And if the user opens your app while disconnected, they need to be able to see something.

You're going to find some amazing content and code labs from Google and around the web on this topic.

The manifest is a simple JSON file, which informs you how your site acts when it's installed.

You need one per app and it needs to be linked from every page of your site.

So the user can tap "install: pretty much anywhere.

Pretty much all modern browsers have some level of support for the manifest.

Here's how you include a manifest on every page.

In case the user hits install there.

The actual manifest is pretty boring, but here's a complete manifest.

It's small and extnsible.

I'm not going to cover every field today.

There's lots of information out there on the web if you want more details on any particular field type.

But let me just touch on a couple of the most important ones.

So first there's the start URL.

This is where your users begin their journey.

When they launch your app on their own OS.

And you can use this query string parameter to capture session launches in your analytics.

A second, this screenshot section is what is going to give you your users a better install experience.

This is already available on mobile, and it's going to be coming soon on desktop.

So here's a, an example of the upgraded install UI.

And so if you have the screenshots in your manifest, then, for example, on Android, you're going to get install UI that looks more like this, as opposed to an info bar and a confirmation dialogue that didn't give the user a good idea of how your app was going to look and feel before.

Finally, let's talk for a moment about how window, windowing is going to work via the display mode JSON field.

So there's a few different options here.

For games, you might prefer a full screen display mode.

This is the example there with Santa.

And for anything app-like you're probably going to want to use standalone which doesn't completely fill the screen from headset.

This is more a standard app-like UI on, especially on a mobile device, websites in any mode can be installed and still run in the browser.

So you can use display mode browser, and there's a few other options like minimal UI, but you can read more about those online.

So now that you know how to make apps installable, I'm going to show you how and when to promote a web app install.

Please just promote web app install when it makes sense.

So I'm going to show you some examples of that, but the focus should be on the user.

How are you helping the user get their job done?

If asking the user to install at this particular moment, isn't helping them get their job done, then you shouldn't be doing it.

So where should you promote app install?

First, the header can be a good place, but you should be careful here.

Especially on a phone.

These are super precious pixels.

So you want to use information architecture, techniques and AB testing to determine whether it really makes sense to have a permanent install button here.

It's going to depend on your use case.

Like you probably have other information here, like your logo, a hamburger menu, maybe other shortcut items, like for example, a shopping cart shortcut on an e-commerce site.

These are all really important use cases for the user, and they might be more important than installing your, your, your app.

So consider carefully before using this space, but it is an option.

Here's an example of adding an install promotion through the hamburger menu.

The really great thing about using the menu for promoting your web app is users browsing your menu.

That means they're looking for something.

You don't want to block any important information, by promoting this, like, for example, the very top of your hamburger, you might want to put it a little bit further down.

So the users, you know, again, use information architecture, techniques, AB testing, to understand what your user is most likely looking for.

But the menu is a great place to put it because it's a menu it's there to fulfill the user's needs and it's there to fulfill needs that they need a little bit less frequently than things that are are up in the header.

Here's an example of promoting install on a landing page.

And I mean, landing pages are basically all about marketing your site.

So just go crazy here, keep in mind that the usual best practices for a landing page to tell the user about your content or your product or your service.

And if the user doesn't understand what your site does or why they would want to install it, they're probably not going to.

So just make sure that you get that up front.

Now a lot of sites have feeds whether that's news or photos or recipes, and that feed pattern can be a great option for promoting PWA install.

You can just essentially insert feed cards that are like, you know, they look and feel like most of the other cards in the feed.

Next up, they promote the installer of your app.

It's great for news apps can be good for e-commerce sites for things like the product listing page and anywhere, there's a lot of vertical scrolling and information chunking.

You probably don't want to show this promotion too often, and you might want to include a dismiss option so that the user can get rid of the card if they are never going to want to install your app.

And so you don't keep annoying them.

Keep in mind that every app use case is a little bit different and there will always be key moments of engagement in the journey, when you know, the user is interested in your offer and understands it effectively.

That's a great moment to see if they want to connect with you again soon.

So the usual rules apply here.

Focus on the benefit to the user.

Use the context of those key moments.

Like in this example where we can let the user know that they can install instantly and then play the game again, by tapping off the launching surface of their screen.

Here's some basic principles for promoting PWA install.

Start with a good rule of thumb, please.

Don't be annoying.

Your users came to your site to get something done.

Don't interrupt their flow and make it harder for them to get that task done by asking them to install.

Just keep in mind.

It's really easy for them to leave.

So if you're annoying them with stuff, they're just going to ax it.

They're going to go somewhere else to your competitor's site, for example, and get their job done there.

The user's not benefiting, you shouldn't be promoting the install to them.

Finally do use context in advanced-help the user understand what they're really going to get from installing their app.

Like, what are they going to get out of that install?

What additional services or functionality are you offering?

Or like, why would they want to come back and visit your site more frequently because they've put it on their home screen?

Now, after you've got a user who's installed your app, you're gonna want to understand what's different about the behavior of installed users versus users who are viewing your site in a tab.

So don't forget the analytics.

There's really three important events in the install prompt flow.

First is an event called `beforeinstallprompt`.

And this happens when the site is qualified for install.

Second, when the prompt actually gets triggered.

So you can just listen, for example, for a click event on an install button on your site.

And then finally, when the install complete successfully, you will receive an `appinstalled` event and you can listen for this too, and you can tag it in your analytics, no matter which analytics package you're using, you can set this information as a custom event or you know, add the state as a custom variable.

You may be wondering, well, what about iOS?

And the great news is that iOS Safari has really good support for the essential PWA ingredients, like a service worker and a manifest.

And it's had these ingredients for quite some time now it's.

It's easier than ever to install PWAs on Safari.

And the other home screen option, which installs the app on Safari is a first level menu option.

So what you want to do is show up a promotional pattern for iOS.

Hey, here's an example of one we use for the Santa tracker.

And as you can see, when the Santa tracker install pops up, it just helps teach the user how to use Safari to perform the install.

Now, a lot of organizations do have native apps and they worry about accidentally promoting web install to users who already have that app.

You're going to want to promote your PWA to users of the website, but just the ones that don't already have the native app installed.

Keep in mind that there's all kinds of reasons that a user may not have, or want your native app, but might still want your web app.

So storage is one example since you know, storage is one of the number one reasons that users remove apps from their device and many apps use 10 to 50 megabytes of space.

Most web apps are comparatively tiny, just a few hundred kilobytes.

And like any of the dynamic storage, like the cache gets purged automatically by the browser in response to storage pressure.

So we may want to let users know that the option of the web app exists.

To avoid promoting your PWA install to native app users you want to use get installed related apps, and that API will let you see in JavaScript if the user has your native app installed.

Most PWA installs today are happening from the mini info bar or from the richer install UI.

This was the mini info bar is really not intended to completely replace your own browser promotion.

So you're going to want to you know, you may want to hide it completely and only trigger install from a promotion that you're running inside of your site.

If this is the case, what you want to do is you want to listen to the `beforeinstallprompt` event, and then you want to call `preventDefault` on that.

So that you will prevent either the richer install UI or the mini info bar from appearing on the screen unsolicited.

So that will basically stop Chrome from promoting the installability of your site to the user.

So here's the details really quickly.

We're adding an event listener for `beforeinstallprompt`.

And then all we do is we call `preventDefault` on that event.

And we might want to show an install button at the same time.

So we give a little example of doing that.

So in this case, you can see, we set `the installButton.hidden` to false, and Bob's your uncle.

Finally, you might want to capture a reference to the install event so that you can use it to prompt the user for an install later.

Here's an example of how to use that save reference.

So let's imagine you want to wait until the user has completed a critical part of their journey before prompting them about installing your app.

When you're ready, you can just call the `prompt` method on the saved event reference.

That's the talk for now, just a reminder of what we hope to accomplish here.

I want developers to have the capabilities they need to build amazing web apps.

And I want those users to be able to choose whether to experience that in the browser or in a standalone installed app window, whichever is better suited for their needs.

And the web is in this extremely unique position of being able to do that.

Installability is essential in enabling this.

And I hope this talk gave you all the basics that you would need in order to make your app installable, to promote it and to measure your success.

Thanks so much for listening.

You can reach me on Twitter.

If you have any follow-up questions.

Web App Installs: Why, when, how
Penny McLachlan
Product Manager, Google Chrome
@b1tr0t

Photo of Penny

Image of a tablet screen loaded with many app options

Table of common website properties. Positive attributes are colored in blue and less positive attributes colored in grey

Common attributes of a website

  • Can run on any device
  • Quick to open and use
  • Open from the browser
  • Always runs in the browser
  • Always runs in a tab
  • Probably won’t work offline
  • Not optimized for the device
  • Linkable

Side by side tables comparing website and app attributes with positive attributes colored in blue and less positive attributes colored in grey

Common attributes of a website

  • Can run on any device
  • Quick to open and use
  • Open from the browser
  • Always runs in the browser
  • Always runs in a tab
  • Probably won’t work offline
  • Not optimized for the device
  • Linkable

Common attributes of an app

  • Usually ecosystem-specific
  • Download & Install
  • Open from the launcher/files
  • [Feels like it] runs on its own
  • Has its own window
  • Usually works fine offline
  • Powerful capabilities / system access
  • Not linkable

Repeat image of the comparative table from the prior slide with an additional line at the bottom of each table denoting how a user might feel about the two experiences. On a website, they may feel "I use this", whereas on an app, they may feel "I own this."

Common attributes of a website

  • Can run on any device
  • Quick to open and use
  • Open from the browser
  • Always runs in the browser
  • Always runs in a tab
  • Probably won’t work offline
  • Not optimized for the device
  • Linkable
  • "I use this"

Common attributes of an app

  • Usually ecosystem-specific
  • Download & Install
  • Open from the launcher/files
  • [Feels like it] runs on its own
  • Has its own window
  • Usually works fine offline
  • Powerful capabilities / system access
  • Not linkable
  • "I own this"

Screenshot of the beta version of the Gmail app

Introducing “Progressive Web Apps”

PWA

Large image of the Progressive Web Apps logo

PWAs offer App-like experiences with the reach of web

Diagram plotting the position of PWAs relative to native Apps. The x-axis is labelled REACH and the y-axis is labelled CAPABILITIES

A symbol representing native apps is positioned at the top left of the chart, indicating that Apps are high on capabilities but don't have the reach of the web. An symbol representing PWAs is positioned at the top right of the chart and highlighted with a large grey arrow, indicating that PWAs are effective on metrics of both reach and capability

Image of Steve Jobs holding an early iPhone model with a spartan screen interface of tiles

Table of the attributes of PWAs highlighting where PWAs bridge the gaps between native apps and web apps to offer the best of both platforms. The positive features of web apps that PWAs extend on are delineated in blue and accompanied by checkmarks and the negative functionalities of web apps that PWAs improve on are delineated in grey with crosses.

PWAs: bridging both to create a universal application platform

  • ✔ Can run on any device
  • ✔ Quick to open and use & Can be installed
  • ✔ Open from the browser & Open from the launcher/files
  • ✔ Linkable
  • ✕ Runs in a tab / Has its own window ✔
  • ✕ Must be online / Works offline ✔
  • ✕ Runs in the browser / Integrates with the OS ✔
  • ✕ Not optimized for the device / Powerful capabilities / system access ✔
  • ✔ “I use this” & “I own this” ✔

Holiday themed animation playing on the screen of a desktop device which then morphs into a laptop device and then a smartphone, all whilst the animation continues seamlessly. Underneath are a row of icons for Chrome, Android, Windows, MacOS, Linux, and iOS, indicating the breadth of capability that PWAs offer

What can web install do?

  • Integrate into native launch surfaces
  • Integrate into native task switcher
  • Integrate into native settings & permissions
  • Integrate into native features such as content sharing or clipboards

Requirements for installable web apps

  1. Web App Manifest
  2. Service Worker
    … that has a fetch handler!

Images of a gear icon and a paper icon representing a web app manifest and a service worker respectively. Below these are graphics of a finger pressing a smartphone screen, a smartphone screen with four outward facing arrows and a wireframe of text and images. This trio of images represents various elements related to the functionality of PWAs.

Web App Manifest

  • JSON file which informs how your site is installed
  • Typically need just one per application
  • Included via <link> in header
  • All modern browsers support them

Images of a paper icon representing a manifest.json file, a series of laughing-so-hard-I'm-crying emojis of various sizes, and layout icons of bidirectional North/South and East/West arrows and a www. Button representing a link to the json file 

<head>
  <title>Your Awesome App</title>
  <link rel="manifest" href="/manifest.json" />
</head>

{
  "name": "Tikky the Tik Tak Toe Game",
  "short_name": "Tikky",
  "start_url": "./?utm_source=web_app_manifest",
  "display": "standalone",
  "theme_color": "#00c6ed",
  "background_color": "#3ec4f0",
  "icons": [
    {
      "src": "/images/icon-256.png",
      "sizes": "256x256",
      "type": "image/png"
    }
  ],
  "screenshots": [
    {
      "src": "/images/tikky-hero-screenshot.png",
      "sizes": "586x1041",
      "type": "image/png"
    } 
  ]
}

{
  "name": "Tikky the Tik Tak Toe Game",
  "short_name": "Tikky",
  "start_url": "./?utm_source=web_app_manifest",
  "display": "standalone",
  "theme_color": "#00c6ed",
  "background_color": "#3ec4f0",
  "icons": [
    {
      "src": "/images/icon-256.png",
      "sizes": "256x256",
      "type": "image/png"
    }
  ],
  "screenshots": [
    {
      "src": "/images/tikky-hero-screenshot.png",
      "sizes": "586x1041",
      "type": "image/png"
    } 
  ]
}

{
  "name": "Tikky the Tik Tak Toe Game",
  "short_name": "Tikky",
  "start_url": "./?utm_source=web_app_manifest",
  "display": "standalone",
  "theme_color": "#00c6ed",
  "background_color": "#3ec4f0",
  "icons": [
    {
      "src": "/images/icon-256.png",
      "sizes": "256x256",
      "type": "image/png"
    }
  ],
  "screenshots": [
    {
      "src": "/images/tikky-hero-screenshot.png",
      "sizes": "586x1041",
      "type": "image/png"
    } 
  ]
}

Upgraded install UI

Make it beautiful!

If you have screenshots in your manifest, Chrome displays a new bottomsheet UI that shows your user what they’re going to get when they install your app.

This is already out on mobile, and it’s coming to desktop soon!

Screenshot of the Squoosh app landing page UI

{
  "name": "Tikky the Tik Tak Toe Game",
  "short_name": "Tikky",
  "start_url": "./?utm_source=web_app_manifest",
  "display": "standalone",
  "theme_color": "#00c6ed",
  "background_color": "#3ec4f0",
  "icons": [
    {
      "src": "/images/icon-256.png",
      "sizes": "256x256",
      "type": "image/png"
    }
  ],
  "screenshots": [
    {
      "src": "/images/tikky-hero-screenshot.png",
      "sizes": "586x1041",
      "type": "image/png"
    } 
  ]
}

Side by side images of smartphone screens, the first oriented to portrait and the second oriented to landscape. The portrait-oriented graphic has a label: Standalone (no URL bar) at the top of a wireframe interface denoting that there is no url bar. The landscape-oriented graphic has a label: Fullscreen (+orientation) over an animated image of Santa Claus waving from a sleigh

Install table stakes

Promote web install when it will help the user get their tasks done!

Header

PWA Install Promotion UX

  • Use these pixels carefully
  • Ensure it doesn’t take precedence over other critical functionality that could be in the header
  • Promote selectively to engaged users

Image of a smartphone screen interface with a wireframe demonstrating best practice UX for promoting installation of your app in the page header. A dark blue Install button appears on the top right of the header.

Hamburger menu

PWA Install Promotion UX

  • Menu users have signaled engagement with your web app
  • Don’t block important navigation options or clutter your menu with the promotion

Image of a screen interface showing a wireframe demonstration for best practice UX on adding an install promotion to a Hamburger menu. The Install CTA is located at the bottom of the screen and features a simple, clean design and UX centred promotional text reading: "Find what you need faster with our free app!", as well as a "Not now" option

Landing pages

PWA Install Promotion UX

These are explicitly about marketing your content, products & services, so this is the one place where it’s appropriate to be very prominent in the promotion UI.

  • All the usual guidance for a good landing page applies
  • Focus on benefits to the user

Image of a screen interface showing a wireframe demonstration for best practice UX on adding an install promotion to a landing page. The Install CTA is located at the bottom of the screen and features a simple, clean design and UX centred promotional text reading: "Access articles offline using our web app." as well as a "Not now" option

In feed patterns

PWA Install Promotion UX

These can go between any set of feed cards in social, news or eCommerce PWAs.

  • Limit the frequency, don’t be annoying
  • Include a dismiss option, remember and respect the user’s choice

Image of a screen interface showing a wireframe demonstration for best practice UX on adding an install promotion to a feed pattern. The Install CTA is located in the midst of the feed and features a simple, clean design and UX centred promotional text reading: "Keep reading, even when you're on the train!.", as well as a "Not now" option

Key journey moments

PWA Install Promotion UX

There are key moments of engagement in every user journey.

  • As always, focus on benefit to user & context of the install promotion
  • Make the promotion lower priority than key journey UI

Image of a screen interface showing a wireframe demonstration for best practice UX on adding an install promotion to a key journey moment, in this case the conclusion of a game on the Game Over screen. The Install CTA is located at the bottom of the screen and features a simple, clean design and UX centred promotional text reading: "Install instantly, play again anytime" as well as a "Not now" option

Principles for promoting PWA Install

  1. Don’t. Be. Annoying.
  2. If the user doesn’t benefit, don’t promote install.
  3. Use context to help the user understand the value of installing your app.

To learn more, search the web fundamentals site for ‘Promoting install’

Don’t forget the analytics

There are 3 important events in the install prompt flow

  1. beforeinstallprompt when the site is qualified for install
  2. When the prompt was triggered (for example 'click' event on an install button)
  3. appinstalled when the install was completed successfully

iOS prompt

iOS doesn't natively prompt your users to install—but has a great installed experience

Use a high engagement metric to show a matching "Install" UI, and informative popup, across platforms

Animated demo of an install promotion pattern as displayed in iOS. The demonstration shows the interface for the Santa Tracker app in Safari. A popup helper for the user is triggered after they select the 'Install" button from the app homepage

How to promote your PWA, but not to your native app users

getInstalledRelatedApps has your back!

Use this API to safely promote PWAs, even if you have a native app.

https://web.dev/get-installed-related-apps/ for details

Hide install promotion

Implementing your own web app install promotions?

Lose the automatic install promotion.

To do this, register a listener for the beforeinstallprompt event and call the preventDefault() method.

Image of the Squoosh app homepage showing the default install promotion that appears with the app

let capturedInstallEvent;

// Prevent the mini infobar from showing up!
window.addEventListener('beforeinstallprompt', (event) => {
  event.preventDefault();
  // Make your "Install" button visible
  installButton.hidden = false;
  capturedInstallEvent = event;
});

let capturedInstallEvent;

// Prevent the mini infobar from showing up!
window.addEventListener('beforeinstallprompt', (event) => {
  event.preventDefault();
  // Make your "Install" button visible
  installButton.hidden = false;
  capturedInstallEvent = event;
});

let capturedInstallEvent;

// Prevent the mini infobar from showing up!
window.addEventListener('beforeinstallprompt', (event) => {
  event.preventDefault();
  // Make your "Install" button visible
  installButton.hidden = false;
  capturedInstallEvent = event;
});

let capturedInstallEvent;

// Prevent the mini infobar from showing up!
window.addEventListener('beforeinstallprompt', (event) => {
  event.preventDefault();
  // Make your "Install" button visible
  installButton.hidden = false;
  capturedInstallEvent = event;
});

let capturedInstallEvent = ...;

// Later, use the captured install event to start install
installButton.addEventListener('click', (clickEvent) => {
  capturedInstallEvent.prompt();
  capturedInstallEvent.userChoice.then((choice) => {
    // "accepted" or "dismissed"
  });
});

Table of the attributes of PWAs highlighting where PWAs bridge the gaps between native apps and web apps to offer the best of both platforms. The positive features of web apps that PWAs extend on are delineated in blue and accompanied by checkmarks and the negative functionalities of web apps that PWAs improve on are delineated in grey with crosses.

PWAs: bridging both to create a universal application platform

  • ✔ Can run on any device
  • ✔ Quick to open and use & Can be installed
  • ✔ Open from the browser & Open from the launcher/files
  • ✔ Linkable
  • ✕ Runs in a tab / Has its own window ✔
  • ✕ Must be online / Works offline ✔
  • ✕ Runs in the browser / Integrates with the OS ✔
  • ✕ Not optimized for the device / Powerful capabilities / system access ✔
  • ✔ “I use this” & “I own this” ✔

Penny McLachlan
Product Manager, Google Chrome
@b1tr0t

Photo of Penny

Thank you!