 Good morning, and welcome also to our live streaming audience. It may not be very early where you are, so thank you. My name is Paul. I'm a product manager on Chrome. And I'm Dominic, a software engineer on Chrome. We're here from Sydney, Australia today. Are there any Australians in the room? Oh. Terrible. Why aren't we all here in person? Well, before we get started, let's do a bit of a show of hands. How many of you here have heard of progressive web apps? Oh, almost everyone. Fantastic. And how many of you have actually built a progressive web app? Oh, fantastic. Getting to half, I think. Great. So for those of you familiar with progressive web apps already, we're going to show you some of the things we're really excited about, both what's happening now, but also what's coming down the pipe in the roadmap. If you're new and you're thinking, what's all this fuss, we'll try to explain. We talk a lot about how the web is universal. And that can mean a lot of things. But what we mean today is that anyone can publish and anyone can access content on the web. You don't need to be well-known or wealthy. And it doesn't matter what devices your end users are using. And this was true in the beginning when websites were basic, static, and images and text. But what's really interesting is that it's remained true today, even as we have expanded the capabilities of the web to do things like rich media streaming, interactive graphics, and really full web apps. You can still, more or less, create it once, and your users can consume it anywhere on any device they happen to have. This is really important as devices have really proliferated and exploded. So as a developer today, you don't really have to think about the number of places and devices and all the different details that happen when your website goes out and people consume it. Anybody can really access it. You've got hundreds of vendors, hundreds of form factors, all sorts of different geographies and industry niche. It just works. But there's one area where this really isn't true today, and that's applications. If you're building an application, you still have to think about which platform it's going to be used on, and you have to develop it once for every major platform. So one of our big questions here was, why should this universality only work for websites? Why can't we bring this functionality to applications so that as a developer, you can make your application once and have it run on all these different devices? So what all the fuss is about is, we'll talk today about how that's really starting to happen, and we're really excited about that. But before we can really talk about applications, we need to look at what that word means. And we get this question a lot. People come up to us like, great, progressive web apps, so what's an app? And everybody has their own angle on it. So just to sort of put a stake in the ground, we'll tell you what we look at as an application. So we take a step back and look at the web. The web does a lot of application like things. Gmail and Maps brought rich web apps more than 10 years ago and 15 years ago. And ever since then, the valley and unicorns around the world have really leveraged this to build their businesses. Rich web applications, Amazon.com, Facebook, all these things. So today it's a huge part of the tech industry, but they still don't feel like an application. They don't feel like a Photoshop or a word. So why is that? If we put apps up next to what we said on the web, they stand apart in a number of ways. You can launch them from an icon on your desktop. You can launch them when you double-click the right kind of file. When you launch them, they open in their own window and that window has a consistent UI that really makes it feel like one person designed it. They can start up offline. Sometimes they don't do much after they start up, but they can always start up. And they can take advantage of all of the cool tech in the latest devices, fingerprint readers and new accelerometers and all that stuff. So when we look at applications, these are the kinds of characteristics that we think matter. And our goal is to bring those capabilities to the web directly using PWAs. We want to break the web out of the browser so that it can deliver this app-like behavior. We're not really alone in trying to crack this problem. If you look at technology architectures like Electron, like Cordova, like React Native, this is a common kind of desire. How can I use this web technology to build native apps? PWAs take this idea just one step further and actually build this directly on the web. We want to bring users the best of both worlds and we want to make it so that you spend less of your time futzing with different platforms and more of your time and effort on making your users happy. So how's that working out so far? Dom is gonna bring us up to speed. Thanks, Paul. Let me take you back a few years to the start of our journey with PWAs on Android in 2015. In a mobile-first world, the mobile web was in a particularly bad way and users had clearly shown that apps were their preferred medium on an increasingly preferred device. Three key properties really stood out about apps on mobile. Firstly, they often had a far superior UI that was built with the device and touch interaction model in mind. Next, on devices where typing was difficult, having a home screen launcher icon for instant easy access was of paramount importance. And finally, deep system integration, having the app show up in places like share sheets, app lists, and settings was necessary to make an app feel, well, like an app. Those last two in particular are two of those superpowers that we just highlighted. So we lent on progressive web apps as a vehicle to level the playing field for the mobile web. We focused on encouraging developers like yourselves to build touchable mobile-first responsive experiences to address the UI gap. We went to work fixing the system integration, ensuring that installed PWAs interacted seamlessly with Android and other apps. We worked on lots of the little details, making sure that the app launched properly from push notifications or from web links from other apps. Since then, our core goal has been to use PWAs to allow you to build an experience that's indistinguishable from native. We've definitely got a lot of areas to improve on, but our work has really paid off in adoption, user engagement, and developer success. Fast forward to today, all major mobile browsers support PWA installation, even iOS. Now, we'll focus mostly on desktop for the rest of this talk, but if you want to hear more about the latest on PWAs on Android, you should check out the talk at 12.30 on stage eight, taking Chrome full screen with trusted web activities. Back to the history. While mobile is now a dominant consumption platform, desktop remains the dominant creative platform. We knew that transforming that success on mobile to success on desktop would require significant additional investment. Well, we made that investment and we're excited to announce that as of March this year, we now support installing progressive web apps and running them as standalone app experiences on all Chrome platforms. Chrome OS was the first desktop platform to get support in early 2018. We took the time to reimagine the UX for desktop, settling on a themed title bar, a three-dot menu to access useful browser functionality, and the title bar serves as a security surface for us where we can disclose things like permission usage and anchor prompts for features like Autofill and Translate. We followed Chrome OS with Windows and Linux support in late 2018. For both of those, we retained the title bar design with the window controls matching the style of the host OS with Linux showing the app icon in the title bar. And Mac support was shipped in March this year with the familiar left-aligned traffic light window controls and centered app title. Now it's possible to do things like this. Here, you see SketchUp Web, a 3D modeling tool running as an installed PWA and looking native on all three desktop platforms, one code base. We're really excited about the possibilities that this opens up for all of you. The web is no longer confined to the browser but open as an app platform where you can make native experiences available right once, run anywhere. Let's make this a bit more real. I'm gonna walk through an introduction to the key ingredients of progressive web apps. For many of you who've built them before, this is going to be familiar. And for those of you who are new to PWAs, it'll hopefully give you a great starting place to build on. But if you take nothing else away from this talk, just take this. PWAs are just websites with a few additional pieces. Being websites, they should work perfectly well in the browser, any browser. And being the web, these additional pieces also work in the browser. Users should never have to install a PWA in order to use its capabilities. But taken together, these additional pieces are the progressive in progressive web apps. The ability to be installed, to function while offline and to access the APIs and operating system integrations that create a compelling app experience. Even better, these pieces, all the code that I'm about to show you, works on mobile and desktop. The look and feel is tailored to the platform, but it's the exact same code, cross-platform and cross-browser. And that's really the power of the web, why we do what we do. We might take a little longer on the web platform to deliver capabilities and integrations, but when we do it, it's done universally. So let's start with the first puzzle piece, the web app manifest. This is a JSON file linked from your page's header element. It provides application metadata that's used for a variety of purposes. Note that we usually expect the manifest to be retrievable without needing to attach credentials to the request. If that's not the case for you, you'll want to add the cross-origin attribute to your manifest declaration. And that will cause the browser to make a credentialed request for the manifest that attaches things like cookies. Here's an example manifest that our team built for squoosh.app. It's an image compression PWA that lets you access all of the advanced options offered by native image compressors, but right in the browser, meaning that you can use it anywhere. By the way, if you drop by the web sandbox, you can see Squoosh in action and hear about how it was built, or just visit squoosh.app if you're following along on the live stream. Let me highlight a couple of the key fields in here. The name, start URL, and icons members are used to create the launcher shortcut for the app. And the display member tells the browser how the app should be open when it's run. By specifying standalone, this requests an app window that's independent of the browser. There are a few other display modes available, but standalone is the one you'll likely want for your PWA. To make it a bit more real, here's the launcher icon in the applications folder and in the dock on a Mac after I've installed squoosh.app. And then when I use one of those to launch it, it's going to open that start URL in its own app window. This theme color member provides the color for the app title bar when it's launched on both mobile and desktop. That's this orange bar at the top of the window here, and that's going to give your app a distinctive on-brand experience. But don't worry, if you omit the theme color, the browser is going to choose a neutral color that fits into the OS theme for you. And finally, the scope determines the extent of the app. This is important for accurate link capturing behavior, where the browser can intercept navigations that fall within the scope of your app, and then redirect those links to open in your app window. I'll talk a little bit more about link capturing and what we're doing there later in the presentation. Now, we're continually adding new members into the web app manifest to help define new functionality. But what's really exciting is that as of 2018, last year, all major mobile browsers now respect the web app manifest for their add-to-home screen functionality. And we're seeing an increasing number of desktop browsers doing the same as well. Here, I've got a screenshot of Duo, our video calling PWA, running in a standalone app window on Chrome OS. You can see they've used a neutral theme color, and the app icon appears as the running app in the Chrome OS shelf. Now, let's move on to Service Worker. This is the secret source for offline, a lightweight network proxy that intercepts network requests and provides cache resources should those network requests fail. This is the technology that truly allows websites to break out of that online sandbox and work seamlessly offline. Technology that lets your websites always be apps and not turn back into a web browser tab when the network is down. The advent of Service Worker represents a fundamental shift in how you should think about architecting your websites and your web apps offline first rather than online first. We've seen time and time again that building your app from the ground up with offline in mind works way better than trying to retrofit offline functionality after the fact. And just like the Web App Manifest, all major browsers now ship full support for the Service Worker API. There is no reason for modern web apps to not be built offline first, just like native apps using Service Workers. Let's dive into what that looks like. I'm going to walk through how you can use Service Worker to provide a simple offline fallback page in place of Chrome's offline page. This is an easy way to keep showing users your themed app UI when the network isn't available. First, we wait for the page load event to register a Service Worker. And that's to make sure we don't block the page load. Once registration is complete, the commands in the serviceworker.js file are going to be run. You can specify an optional scope for the Service Worker that denotes the extent over which the Service Worker has control. The navigations that it's going to be intercepted. This should definitely match the scope in the corresponding Web App Manifest file to ensure that the Service Worker controls all of the URLs in your app. So let's move on to the serviceworker.js file. In here, we wait for the install event to fire. And note that this doesn't have anything to do with installing your PWA. We're going to get to that in a moment. This just means that the Service Worker is ready to go. At this point, we can create an offline cache using the cache API. You'll notice that I've versioned the cache name so we can easily invalidate it should the content become out of date. So once we have a cache open, we just pass it a list of the URLs we want cached. And then the cache will go and fetch those and store them ready for use later. The cache itself maps keys of requests to values of responses. In this example, only need to cache the one page because the entirety of that page, assets, styles, contents, and scripts, they're all contained in that one HTML file in line. And no other network requests will be made whilst loading. So now we've got that page cached. We need to ensure that we retrieve and serve that page when the network is down. And we do that with a fetch event listener, which will be fired for every network request made by your site. This allows the Service Worker to intercept all those network requests and substitute them if necessary. Now, I've admitted a couple of details in this example that you'll want to look at, like cation validation and navigation preload to ensure good performance. So when that fetch event fires, we're going to use a network-first strategy in this example. We're going to respond to the fetch event by calling the fetch method. And that sends the request to the network. Should that network request fail, we'll catch the error, open up our cache, and serve the offline page that we stashed earlier, ensuring that the user is presented with AppThemeUI at all times. Now, this is an incredibly simple example of offline support. It is the bare minimum that you can do. We're not even bothering to cache specific resources, just a single page to display when the network is not available. You can and you should do a lot more. And many of our partners have done so, creating cache-first loading strategies where important content is always available and important user journeys are always accessible, no matter the network status, buffering new navigations for syncing with the server later on. Now, ServiceWorker is an extremely low-level API. You probably want to avoid writing all of this caching yourself if you can avoid it. And of course, being the web, there are plenty of libraries to help you out. One that we really like is Workbox, which wraps the ServiceWorker API and protects you from some of the dark corners and sharp edges. And it also means you can avoid having to write your caching file by file and instead use catchall routing paths. Here's an example of how powerful and flexible Workbox can be. I'm using the routing library to specify that CSS files should be cached with a stale while revalidate strategy. That means that when we load a CSS file, we race the network and the cache. And whichever one gets back first, we send that response straight on through. The first time, the network's going to win because the cache is empty. But then, that request will be transparently and immediately saved in the cache. And from that point on, it'll be available offline. You can find out more about Workbox at workboxjs.org. It really makes developing powerful offline-capable web apps easy. And Paul's going to show us one in action. So we've actually started to use these PWAs to ship some of our core apps in Chrome OS. And we use some of the goodies that Dom mentioned. This application uses Workbox and WebAssembly. So I recorded a video of Canvas. This is our drawing app to show you how it can work completely offline. So this drawing was done by a colleague of mine using this app. When I was planning the talk, I asked around to see if we had any cool illustrations that we could use. I was expecting something living up to my highest standards, like a box or a circle. But this is what I got. So this is what we're going to go with. So in this video, first I turn off the Wi-Fi. And you can see that once I turn that off, there will be no more network connectivity. And then the artist uses the stylus on a Chrome OS tablet to sign his name. And the key thing here is he didn't know anything about the offline status. He doesn't care whether it's connected or not. He just uses the app the same way regardless. And the service worker syncs it up next time the device connects. Thanks, Paul. So once you've got a web app manifest and an offline-enabled experience powered by service workers, you can add your own UI to prompt users to install your PWA, turning it from a website into an installed app. We strongly recommend taking advantage of this. On desktop, app discovery still overwhelmingly runs through search and download links. Replacing those download links with a PWA installation prompt allows for a smooth, seamless installation experience and transition into an app window for your users. That means you're not relying on users finding the browser's own installation prompts. Installation is a powerful operation since it gives your site a permanent presence in the user's launcher. So when your site loads in the browser, Chrome runs some checks to determine if you're eligible to prompt for installation. Now, your site needs to be a PWA. So have a manifest, have a service worker with offline functionality. And you'll also need to have seen some user engagement since installation prompting shouldn't just happen the first time a user visits your site. When your site passes those checks, which could be run dynamically through the lifecycle of the current page load, the before-install prompt event will be fired into your top-level frame. You'll need to add a listener for this event on your window object. First up, that event handler needs to stash the event away somewhere that's accessible later, since you'll need to call the prompt method on the event to actually trigger installation. Putting the method on the event ensures that the user can't get an installation prompt unless the browser has verified that the site is eligible. Before install prompt firing is your queue that you can enable UI in your app to ask the user to install. For this simple example, I'm just activating a disabled installation button when the event fires. But more broadly, an installation prompt usually works best if you have some UI to tell the user what's going to happen if they choose to install. And we've got a demo of what a good example of that looks like coming up in just a moment. Finally, we wire up a click listener on that now activated install button that calls the prompt method on the stashed event. This is what triggers the browser to show the installation prompt. Without that click, which signifies user intent, the prompt method is going to reject and not show an installation prompt. The event also has a user choice promise member that will resolve with the user's response to the prompt, whether they accepted installation or not. Another useful event to listen to is the app install event, which will be fired if the app installation is triggered and successful from any source. Now, that includes before install prompt, but also mechanisms that the browser might offer, such as the three-dot menu prompt. So you can see this come together in a few mainstream apps. I'm using Spotify on my Chromebook here. And you can see that there's an install app link on the left-hand navigation. When I click it, you see the familiar confirmation dialogue. And then, boom, it's installed in my launcher and in its own window. So this is, as you can see, thank you, Spotify. You can see this is how you can actually integrate these before install prompt events that Dom is talking about to encourage your users to install at the right time. Now, one thing that was really visible in that earlier video but you'd have to really be looking for it to see is this little plus in the OmniBox. So this is a feature coming in early August with Chrome 76 that we are super excited about. This means Chrome will actually promote your PWA in its most prominent UI space in the OmniBox. This uses the same trigger as the before install prompt event, but you don't need to do any coding to get it. It's just intended to be subtle and clear. This website is also an app that you can install. So let's see how that works. In this video, I'm installing the PWA of Duo, which you saw earlier. You can see how it works with just a couple of clicks and really no download time. I have an app in its own window and I can use it to make a call. So now that you've seen the technology in action, let's look at how it can impact your users and your business. Hulu is a popular streaming platform here in the US. You can watch TV and movies at home on your big screen or on the go on your phone or laptop. If you were a Hulu user with a Windows machine, you could use their native app, but their native app had poor user reviews and poor usage and Hulu started thinking about how to fix it. They already had a world-class web experience. What did they decide to do? You guessed it, they built a PWA. So here you can see the Hulu PWA installed in Chrome OS on tablet mode. It looked good, so they launched it. Within three months, 96%, nearly all of their legacy app users had switched to using this instead. So far so good. Even better, compared with the website, Hulu saw that users who installed the PWA were coming back to it more. And they were watching more videos. A whole lot more, in fact. It's still early in our experience here with PWA's, but this does fit the pattern that we're seeing. Because it's in the launcher, it's easier to remember and more natural to return to this experience. It's also an immersive full-screen experience. So if you're engaged in the activity, you're more likely to keep doing it. So if you have dedicated repeat users on your website, this same pattern might hold for you. Thanks, Paul. Just some amazing numbers there for Hulu. So it's really impressive what the app-like web can do today. Cross-platform, cross-browser, from one code base. Now, I was talking to some folks around IO this week, and some of them were really surprised to learn that the web could already do a lot of these things. Access camera and microphone APIs use USB and Bluetooth devices or run cross-compiled performance critical code in WebAssembly. We've come such a long way in the last decade. But we're not stopping here. We know we've got a lot of work to do to continue to expand the capabilities of the web and further improve our OS integration. I'm super excited to share some of our upcoming roadmap, all of which is being developed out in the open in close collaboration with partners, developers, and other browsers. We are hard at work on a native file system API that will let the web, mediated by user consent, directly read and write to files on the user's disk. Not a virtual file system, but the real file system. And we know that this access is one of the biggest remaining holes in our integration story. It's particularly vital for porting existing creative applications to the web and for enabling web-native creative applications like SketchUp, which we showed earlier, to become even more useful. Alongside this, we're working on new web app manifest declarations and APIs that will let PWAs associate themselves with files and mime types. That means that when you double-click a file, it can open in an installed PWA. This will further empower creative applications that have shipped on the web. We're also working on new APIs for PWA launch management. Right now, we do some basic link capturing on Android, where URLs within the scope of your PWA will open in your app. Now, that works well there because there's only ever one instance of the app on Android, and changing state in response to a link is expected behavior. But on desktop, that doesn't quite make as much sense. You might want different behavior based on the content of that link. We're creating a new launch event that will be fired into a PWA's service worker upon an incoming navigation, allowing you fine-grained control to open new windows, focus existing windows, or post-message the incoming data into an existing window. But that's not nearly all. I've picked out several more of our top priority APIs that are currently under development in Chrome. Of course, the dates up on the slide are tentative and subject to slipping if we need more time to get things exactly right. But with luck, we're planning for all of these APIs to ship in Chrome this year. First, to origin trials for your feedback before making it to stable a few versions later. Those three APIs that I mentioned, native file system, PWA file handling, and launch event should all make it to you by the end of the year. It's incredibly exciting how many new capabilities we're bringing, and we really want to hear from you to make sure that your needs are being met, or how we can do more to meet those. Importantly, with all of this new API work, we don't want to break the web and lose the existing advantages of our platform, our universality, our security, and our privacy guarantees. We're working carefully to close the functionality gaps in the right way, collaborating with other browser vendors, and working out in the open to solicit and act upon feedback from partners and developers. We're working incredibly closely with security and privacy teams to make sure we don't lose those guarantees. We've worked so hard to build into the web platform to keep users in control and aware of what is happening. Our capabilities work is really pushing the boundaries of the web, adding much, much more native functionality. But we're focused on doing this in the right way, in a way that doesn't create fragmentation or prevent other browsers from following us. PWAs marry the web with native experiences. We want to let you show off the best of the web platform and build products that delight users no matter where they are in the world or what device they use. Empowering the open web empowers you, granting the widest reach from a single code base. So how can you get started? You can make web apps, you can make them offline first, turn them into PWAs, leverage installation and system integrations and take advantage of the best of the web and native worlds. Hopefully we've shown you just how compelling progressive web apps are as an universal app platform and how much more compelling they're going to get over the next year. So thank you for coming to the talk. Thank you.