 Hi, I'm Andrei. Today we're going to answer some frequent questions about the new features and capabilities for installed PWAs that were reserved previously only to native apps. And to tell us more about what is new and help us with some hard questions we have a guest. Hi, PJ, tell us about your role at Google. Thanks so much, Andrei. I'm PJ. I'm a product manager on the Chrome web platform team. I work on progressive web apps, usually called PWAs. And basically, progressive web apps are modern applications built using web technologies that are making users happier. PWAs have a lot of capabilities, of which one is that they can be installed into a user's computer, just the same as any other application. Oh, cool. So that means we have exactly the right person in the room. For people in the audience who are not yet familiar with installable PWAs, can you tell us a bit more about what they are and where they are available? Being installable is really a standout feature for PWAs because it's giving web developers the ability to make applications that can be started from the start menu on Windows, from the application folder on Mac, the home screen on Android and iOS. And these can really look and feel like any other application on the device. So for applications that users are using repeatedly, being installed means that app is a little bit more top of mind for the user because that launching surface is immediately accessible to the user. They don't have to navigate anywhere in the browser to get back to the application. It also means that the application is showing up in the activity switcher as a separate app. And that makes install quite attractive to developers. But I wanna be clear that a PWA doesn't have to be installed to be a PWA. Being installable is just one property of a PWA. You asked this question about distribution. So let's talk for a moment about where PWAs are available. So first PWAs can be installed directly from the web browser on both desktop and Android. And on desktop, PWAs can also be listed in the Windows Store. On Android, you can find PWA-powered Android apps in the Play Store. This is a technology called a trusted web activity. You also see PWAs in the Samsung Store. You might have heard that PWAs are showing up in the Chrome OS Play Store and that's an early access feature I'm really excited about. So let's save a little time at the end of the session to talk more about that. Oh, I'm really looking forward to learning more about Chrome OS Play Store. But before that, can you tell us about the recent features that you think are the most exciting for developers? I really wish that we had time to go into everything that's shipping because there's a lot happening right now. But I'm gonna have to just pick a few favorites for today. So the features that I'm most excited about are some of the things that web developers could previously only do using a hybrid technology like an Electron app or a Cordova app. And to begin here, let me just mention that the ability to install PWAs on desktop is still really new. So for those of you in the audience who have been paying close attention, I might have seen the announcement at IO last year, this might seem like old news, but I think for a lot of the web development community, this is still a very new feature and people are still getting used to the superpower that install can happen everywhere. You can now write one app and have it be installable on desktop, on tablet, on smartphones, and users can discover that app on your website in search results, in play, in the Windows Store, in the Samsung Store. And this is giving web developers a really unprecedented reach for distribution of their applications. So I'm just super excited that this is now possible to have install across all of these different screens and through all of these different channels. The other features that I'm most excited about are all the capabilities that were previously only possible with Cordova or Electron. So for example, registering a file type handler for an app, offering an immersive mode, so creating better web games through an immersive mode and adding context menus for shortcuts and more. So the file type handler would allow a user to start a web-based image editor by double-clicking on an image in their OS file explorer. That's exciting. Exactly that. So like with file type handling, you could register a file extension or MIME type. So let's say that you've written a new type of image editor and you can edit JPEG and PING files, you could register a file type extension for those file types and then those file types will automatically open in your editor if the user double clicks on those. A word of warning, file type handling, isn't quite here yet. We expect it to go into origin trial in Chrome 85 in August and to be available generally sometime in the fall or winter. Looking forward for this one to go stable. Tell me more about the immersive mode. What does that mean? Immersive mode is a term that's just been borrowed from native. It's a full-screen mode and basically it removes all of the operating system decorations. So no status bar, no navigation bar. And this is great for games or other media, basically when you wanna be able to address every single pixel on the screen. So I could start a video player full-screen from the icon at the home screen. Nice. And what about app shortcuts? Sure, app shortcuts are a way to provide quick access to important functions in the app directly from the app icon. So for example, on Android, you might be familiar with a long press on the app icon on the launch screen or on the home screen. So if you were to long press on a home screen icon for say a mail application, you might see compose functionality directly in the menu that appears when you long press on the mail client. App shortcuts also work on desktop operating systems and that support will be arriving in Chrome 85. Interesting, so that's like deep linking to part of my PWA directly from the icon that's on the home screen. Exactly. Switching gears a little bit, we launched Trusted Web Activity last year's IO and since then we have many feature requests and questions from developers and I wanted to go through some of those with you today. First, developers have pointed out that the way permissions work in the browser and in native is different and that makes their users a little bit confused. As an example, native apps get the notification permission by default while web apps need the users to accept the permission first. How are we planning to solve those inconsistencies? So this is start by just sharing my perspective on the philosophy here of I don't think that users should need to think about what technology was used to build the application that they're using. Users should really just have a job, users just have a job to get done and we want to help developers help users as easily as possible. So wherever it makes sense, I think an installed web application should use the operating systems, typical UI for things like managing permissions, launching and switching between applications just to match the user's expectations for how things should behave on the device that they're using. So we've introduced this concept of notification delegation into installed PWAs and that means that when a PWAs installed, it will delegate the notification permission into the native setting area on Android. So another difference between an app installed from Play and a web app, for example, is that an app installed from Play automatically receives notification permission. So we want that experience to be the same for Android applications that were built using a PWA and that's why we've delegated the web notification permission to the notification settings panel in Android and these apps can be configured to auto enroll users and notifications so that they just look and feel and behave exactly like any other Android app and the user doesn't even need to know that this application was built using web technology. In the future, we're going to be adding location to the settings panel too. Of course, there won't be any auto enrollment for location because users are not auto enrolled in location, for location permission on in Android native apps either. So we're just going to match what the behavior is between for a native application, for apps that are installed from say the Play Store or from any other distribution channel where the user may or may not be aware that this application is a web application. We're going to continue as well to delegate more permissions and match OS preferences over the next few releases. Got it. So this will make the experience more seamless to users regardless of the technology that the developer used to build the app. Another frequent request. Developers sometimes feel that when they make an Android app using PWA and tracer web activity, they should have a communication channel between the native application and the web app. This would allow them to use native platform capabilities where an equivalent on the web doesn't exist already. Is this something that is being considered? I'm really glad you asked this question because this is exactly the kind of product question that I really love. And I'd like to hear from our audience on this one. So today you can pass parameters into a tracer web activity when you launch it and you can use intents to leave the tracer web activity and pass some information into another activity inside of your app. And we're considering adding support for a message bus. For example, we could extend post message to enable a bus with this functionality. However, I don't have use cases from developers on exactly what they need here. Most capabilities are already in the web platform or are planned as part of the Fugu effort to add web capabilities to the web platform. So if the web platform has missing capabilities, I'd really rather add that capability to the web than create a message bus to native because if a capability is part of the web platform then it's gonna work everywhere and developers only need to have one code base which is simpler and that code base will work in multiple browsers, whether the app is installed or not installed, et cetera. So I'd like to turn this just to do a question for our audience. What do you need to do in native code that you can't do today in the web platform and are there things we could do to improve the web platform so you wouldn't need to do that in native or perhaps it's something that could only be done in native and you really need that message bus. I'd really like to hear from you about this. Cool, I'm also looking forward to hear from folks on Twitter or if you are watching this live on the live chat. Many developers have a native application and prompting users to install a PWA in the browser when they already have the native app installed can lead some confusion. Is there a way to prevent the prompts from showing when the native app is already installed? So that's a great question. It's also probably one of the top concerns that I hear from teams that are implementing a progressive web app. It's called channel conflict and it arises where you're not sure which experience is gonna be best for the user. So I think the most important thing for developers to know is that you do have full control over the promotion of PWA install. So you don't need to worry about the browser promoting your PWA if you don't want it to. There are ways you can prevent the browser from promoting the installation of your PWA if, for example, you have a native app. So let's talk about how that works. First, in the web app manifest, there's a couple of fields you should know about. One is called the related applications field and this is where you can list native apps for Android and iOS. And then there's another Boolean field called prefer related apps. And if this is set to true, the browser is not gonna promote the install of your PWA. Secondly, there's an event that fires when a PWA passes the installability check in the browser. And when this happens, developers can call a prevent default method and that's gonna block any promotion of the PWA install in browser UI. Finally, there's a new JavaScript API just landed earlier this year called get installed related apps. And this is gonna let developers inspect if the user has native apps installed on the device that are associated with the origin that the user is currently on. And just to be clear, this isn't gonna let you see any app that the user happens to have installed on the device. The app has to be associated with the origin that the user is on. This API does allow for a lot of programmatic flexibility for developers. So it means you have full control. Which experience do you wanna promote to the user? You could use, for example, user behavior. You could provide the user with preferences in your HTML. It's really up to you how you wanna use this control but it does give you, as the developer, a lot of control over what you promote to the user and when it happens. So this means I can use this API to check if my data application is installed and make decisions like showing that home screen prompt or not. What if my native app is using trusted web activity? Will this API is to return? So yes, absolutely. This does mean that you can use the API to check if your native app is installed. A trusted web activity is really just an Android app. So it will show up just like any other Android app and this API will return it. It will also return if the app is a, it has been installed from the web browser. So a PWA installed from the web browser will also get returned if I get installed related apps. Cool. On the developer experience side, we've been working on tools like bubble wrap to help developers view their project using trusted web activity. But many developers, as you wonder, if it wouldn't be easier if they could just copy paste in your role into the Play Store. That's a great question. So the reason why we've been focusing our efforts on making this easier for developers on bubble wrap is that we could create a much more powerful, much more flexible system for developer, for building Android apps using a command line utility like bubble wrap than what we could do in a web interface. So app stores are really a different ecosystem and they have different requirements and policies. And we believe that developers should have powerful tools that they need to rethink the experience of their applications for this environment. And we also want to avoid giving developers a perception that they could just drop a website into the store without thinking about that experience. So there are all kinds of design decisions that should go into building an Android app. Whether or not it's a PWA powering that app. For example, what's the splash screen gonna look like? When are you gonna hide it? When are you gonna show content? Do you need notifications? There wouldn't be this kind of flexibility for configuring these options with a web interface. That being said, we want it to be as easy as possible. So we've worked to streamline it to the maximum extent that we can with bubble wrap and make it a powerful but flexible and easy to use developer tool. What about place or policies? Do Android apps that use PWAs inside a tricetable activity still need to comply to those policies? I think you said the magic word there, which is Android app. It doesn't matter how your Android app is built, whether it's built using PWAs and web technology or whether it's built using Java or Kotlin. Play policies apply to all Android apps distributed in the Play Store. And therefore, they also apply to Android apps built using progressive web apps. Gotcha, so same store policies apply. What about applications designed for children? Can developers use web technology in those apps? If the target audience for your application is children, you need to comply with the Play Family Policy requirements. And these requirements are intended to help keep miners safe from inappropriate content. Unfortunately, that's really difficult for the review teams to evaluate with web apps where the content can change. And not only can the first-party content change, but it's really easy to include third-party content inside of a web application, which can be unintentionally inappropriate. Let's imagine that you were using an advertising network or something else where you're loading content in from a third-party site. You might not be able to verify yourself for sure whether or not that content is always going to be appropriate. So for the time being, it's not possible to build Android apps using trustable web activity that comply with Play Family Policy. We are working on ways to make this possible in the future. Got it. So it seems PWAs are crossing over ecosystems and developers need to adjust some of their expectations from that. Developers using trustable web activities are also expected to fulfill quality criteria. Is that why that criteria exists? Yeah, nobody wants an app store that's going to be cluttered with low-quality apps. And we also want developers to succeed with their apps in the Play Store. Keep in mind something that's really different about distributing through the Play Store than it is to just sort of build a PWA on your own site is that these apps have user ratings and reviews. And we want to make sure that developers are set up for success to get good ratings and reviews for their apps. So at a minimum, users expect apps that they install from the Play Store to look and feel app-like, to be fast, to work offline. And that's why we have quality criteria for PWAs in the app store. And this is exactly what progressive web app criteria has been intended to do from the very beginning. So first I want to share that there are certain types of events that can happen to a web application that are effectively a crash. And these are things like a 404 happening. These are things like failing an offline check when the user goes offline and returning to Chrome Dino. This is effectively a crash. Failing the digital asset links verification, which is something you need to do with a trusted web activity to verify that you are the owner of the content and the owner of the application in the app store. So if any of these things happen, starting in Chrome 86 in October, we are going to be mapping those crashes into Android vitals crash events. And you will see Android apps begin to crash if users are running into 404s in your application, et cetera. So that's just something that developers should be aware of and we're making another announcement with more details about this. The second thing is on the performance side. Right now, don't have a date to announce with respect to enforcement of performance, but developers should be aware that the criteria is a full batch PWA and a light has performance score of 80 or better. And you can use webpagetest.org slash easy or PageSpeed Insights against your start URL as the fastest way to check whether or not you're meeting this criteria because having the app launch quickly is an essential part of having a great application experience for your users. We will be providing a lot of notice as to when enforcement will begin. It will be in 2021, it won't be in 2020 for the performance and full batch PWA scores. So expect to hear more about this later in the year. So last one. Twitter has recently launched their PWA on the Chrome West Play Store, which was quite exciting. Can you tell us more about how they did it and when this is becoming generally available? I'm really excited about this. Right now, this is an early access program and it requires manual intervention from our team members. So it's not something that we can extend to everyone in the community, but we're working on getting it to general availability and when that rolls out, it'll be possible for everyone to just do this themselves. I'll give you a hint, it uses trusted web activity. So if you're building a great trusted web activity, it'll be really easy to make your progressive web app available in the Chrome West Play Store in the future. And I hope we can share more about this in the second half of the year. So wow, trusted web activities are coming to Chrome West, nice. Well, I think we covered a lot. I wish we had more time to discuss. I do too. So for those of you who are watching, please do reach out to us on Twitter if you wanna give feedback. And if you're watching this live, please join us on the live chat. We'll see you there and thanks so much for watching. Yes, thanks for watching.