PWA Q&A
Over the past few months, I’ve been running a series of question and answer sessions regarding progressive web apps. Some are videos, others are threads on Twitter. Given how much content there is at this point, I thought I’d roll it up into a post so you can see it all at once.
You can view the contents here or go directly to YouTube or Twitter to see them in their original incarnations:
What is a Progressive Web App (PWA)?
A progressive web app (PWA) is a website that has been progressively enhanced in order to be able to do other cool things. It could, for instance, be installed. It could work better offline. It could provide a better, more app-like user experience; something that’s a little bit more engaging.
When you boil it down, a PWA is a website that
- runs under HTTPS, so it’s secure;
- uses a Web App Manifest to provide meta information about the website; and
- has a
ServiceWorker, which helps it to work better offline and allows you to do a lot of interesting stuff in terms of managing network requests.
If you’ve got those three things, you’ve got a PWA.
What is a Web App Manifest?
A Web App Manifest is a a JSON file—that stands for JavaScript Object Notation—that includes a bunch of meta information about your site. That information could be things like
- icons that you want to be used when your PWA is installed;
- the short name that you would want use on a home screen or in app lists;
- your site’s full name; and
- a description of what your site is or does.
The manifest file is referenced in the head of your HTML page via a link element. That makes it accessible by browsers or by any sort of build system that might want to make your PWA installable.
There are also several keys in the manifest that make it useful in an app store context. You can include categories when you want your app to be findable as a “productivity” app, for instance. There’s IARC rating to indicate the age range your app is safe for. There are also keys for screenshots and, as I mentioned, the description that you would want shown.
There are also keys for describing how the PWA should operate. You set up your start page—the location your PWA should open to whenever it is launched. There are keys for describing your theme color, orientation, and even how much browser chrome—the controls surrounding the browser viewport—you want around your app. You can make your app look like it’s running in a browser, with address bar and all of the back and forward buttons, refresh, and all that. There’s also
- “minimal UI” with fewer controls,
- standalone, which basically cedes all of the browser controls over to the developer, making it incumbent on them to actually manage back, forward, and such; and
- fullscreen, which is similar to standalone, but runs… ahem… fullscreen.
What is a Service Worker?
ServiceWorker is a web standard, first of all, that’s been adopted by every major modern browser. It’s is a type of Worker. You may have heard that term in JavaScript before; it’s an isolated piece of programming logic that’s running in a separate thread from the main browser UI thread.
A ServiceWorker is a specific kind of Worker that allows you to be your own proxy for all network requests. That means if I am loading up a web page and I’m requesting an image, the ServiceWorker can actually intercept that request and, for example, return an image that’s already stored in the cache. Or it could go to the network and store the response in the cache and return that response to the browser.
You can use service workers—yes, you can have more than one—to enable a ton of really interesting and beneficial user experiences, such as being able to provide an offline experience. You could provide a more performant experience by caching certain frequently-referenced CSS, JavaScript, and images so you can serve up a cached version instead of going out to the network to make requests. That speeds up page load and rendering considerably. Service workers can also be used to do things like push notifications and, in development, there are specs for being able to do synchronization both as one-time synchronization events and as background synchronization events, enabling you to keep your app up-to-date whenever it has a network connection, whether a user has your app open currently or not.
ServiceWorker is a pretty ambitious spec and I’m sure it will continue to evolve, becoming more and more useful. But, in a nutshell, it’s a proxy that you control in JavaScript that enables you to create a better experience for your users.
What frameworks work best for building a PWA?
This is actually a bit of a loaded question because you actually don’t need to use any framework to build a PWA. Some are certainly designed for creating more app-like experiences on the web, but a progressive web app can be built from any website. You could have a static website—like this one—with a few enhancements in JavaScript. You could have a full-blown single page app that’s built in React or something like that. Any website can be a PWA; use whatever your team is most comfortable with.
The main idea behind progressive web apps is that the app-like experience is a progressive enhancement of a core experience that is universally usable. The main question to ask when you’re looking at frameworks, libraries, or even content management systems is Am I getting a solid first render that’s coming from the server rather than having to rely on client-side JavaScript to render my page? That way you ensure that your pages are always going to be rendered and then, once you have that, you can go ahead and take over with whatever your front-end framework is (if you decide to use one).
Do I need to build a single page app (SPA) before I build a PWA?
No.
Seriously, though, a PWA can be whatever it is that you want to make it.
The first PWA that I built was actually the HTML version of the book that I wrote back in 2011, long before PWAs existed. It’s static HTML that I generated from the ePub version of that book. I put it on the web, added a service worker and a web app manifest and I had a PWA.
You don’t need to invest in building a single-page app and, in fact, there may be certain instances where you don’t want to build a single-page app because it just overcomplicates things. Plus, URLs are very helpful for users to be able to access certain bits of content, functionality, and the like. The URL scheme is something that we should care about and we should ensure that people can access and use them. Many SPA frameworks get rid of URLs entirely or render them useless.
You don’t need to have a single-page app, but if you do, please honor URLs. Make sure that you have a rational URL structure. Responding to URLs appropriately. Don’t redirect everyone to the home page when a URL that you recognize (or that you should recognize) is requested. Follow these guidelines and you’ll build a great web experience, regardless of whether people have it as an installed PWA, view it in their browser, or are on an older browser that doesn’t support ServiceWorker and other PWA features.
What makes for a good PWA?
PWAs start with a great web experience. Make sure that you’re building an experience that works on any browser. Make sure it’s performant. Avoid making assumptions about what a user’s browsing situation is.
We live in a bubble. Most of us have fairly high-end devices connected to high speed networks and an uninterrupted supply of power. That’s not the reality throughout the world. Being aware that there’s more than our experience helps us to build more inclusive websites that can reach more people living very different lives from us.
Similarly, it’s important to consider the accessibility of your project. Make sure that people who have disabilities (e.g., low or no vision, motor disabilities) can use your product. Be certain it works with alternate input methods like keyboard and voice too.
Make accessibility and inclusive design part of your process, build something that is a great user experience, that’s performant… that’s the foundational work you should be doing before you look at enhancing your site into a progressive web app.
Will PWAs replace apps?
PWAs will replace some types of apps.
Why? Well, when you’re building a platform-specific app, you usually need to build some sort of API or web service first. Then you build a different app for each platform you want to target. You might have an Android app, an iOS app, a desktop app for Windows, another for macOS, and so on. Chances are have a web version as well. If that’s the case, perhaps it makes sense for you to double down on your investment in the web version.
The web design and development community is substantially large with a ton of available talent and resources available at a relatively low cost. If you focus your energies there rather than dividing your money and effort across umpteen different platforms, you will likely achieve the same result with lower costs and quicker turnaround. This is especially true if you’re providing an identical experience on all of those platforms. If that’s the case, it definitely makes more sense to focus on building a great web experience that you can turn into a PWA to become installable on all of the platforms you were originally targeting with apps.
So that’s one side of it. The other is that there will always be apps that perform better as apps, but it will be on a case-by-case basis. If you need to be closer to the metal on the machine, a traditional app probably makes a lot of sense for you. If you need to have immediate access to certain device APIs that aren’t available via web standards, then a platform-specific app is going to make more sense to you.
PWA or app should be evaluated on a case-by-case basis. I don’t think PWAs are going to replace all apps, but I think they’re gonna replace quite a few.
Why is Microsoft interested in PWAs?
This is an interesting question because PWAs, in a lot of ways, are viewed as a mobile solution (or at least were initially proposed as a mobile solution). Microsoft isn’t really in that space much anymore, so why is Microsoft interested? The answer is that Microsoft has actually been very interested in the web for quite a long time. Back in Windows 7, Microsoft introduced Pinned Sites, which graduated a website from the browser to the taskbar. When Windows 8 came along, Microsoft enabled developers to build apps using web technologies. Then, when Windows 10 rolled out, Microsoft introduced Hosted Web Apps (HWAs), a precursor to PWAs in the Microsoft universe. HWAs allowed you to bundle a web app—something that existed at a URL—as an installable app.
The web is a great distribution mechanism. It’s also where a lot of the fantastic experiences are being built and Microsoft wants to be supportive of that. We want to improve discoverability for the awesome services people are building on the web within the Microsoft Store, within Bing search results, and that sort of thing. Ultimately, it’s about giving exposure to the great software that’s being written while also being able to provide those great experiences to Windows users.
Aren’t PWA’s for mobile devices?
PWAs did originate in the mobile space. They were originally launched for Android as an enhanced version of a Chrome link on your home screen. Samsung Internet, Firefox, and Opera also enabled installation of PWAs on Android, so yeah it was very much a mobile thing to begin with. But that’s not the case anymore.
On the desktop side of things, Microsoft has stepped up and declared PWAs first-class apps in Windows 10. Google has also been making a push to bring PWAs to desktops with installation via Chrome. Microsoft Edge will be rolling out a similar feature (which, if you think about it, is a lot like an enhanced Pinned Site). We’re starting to see PWAs show up more frequently on the desktop now. That’s where a lot of users still are, especially for certain verticals like financial and news. So why not take advantage of that?
We’ve traditionally thought about PWAs as being a mobile solution. That’s why responsive design—being able to have your design flex to different screen sizes—is such an important characteristic. Responsive design has its place on the desktop too because users are constantly resizing windows—pushing things off to the side, docking them in different ways—so they can use multiple apps at once. The things that we built to make the web look and work really well in a mobile context actually work quite well in desktop too.
Aren’t PWAs just a wrapped website?
Yes, in a way installed PWAs are a wrapped website, but PWAs are about providing a great experience that can work offline as well, which makes them a bit more like a traditional app. And that’s kinda the point. By taking advantage of ServiceWorker to provide an offline experience, synchronize and manage your data, and so on, the web is able to operate on the same plane as traditional apps.
Now, in most cases, a website being installed as a PWA does seem very much like a website, but on Windows a whole world of OS-level APIs opens up for the developer, enabling a website to do more. Sharing, for instance, is something that people frequently do; being able to share from one app to another is super-useful. Those APIs are starting to come to the web, but within Windows we have that stuff already.
In Windows, we have the WinRT APIs. These are JavaScript APIs that allow your app to connect deeper into the OS. So when you’re an installed PWA in Windows, you can actually start to light up different OS-level features—adding your PWA to the Share Charm, pushing events to the Timeline, seeing if a user is using Dark Mode, etc.—and react to that. There are also integrations with a user’s calendar, their contact list, fine-grained geolocation data for geofencing, and so on. There are lots of APIs available within Windows that PWAs can take advantage of to enhance their apps.
This is one area where the Twitter PWA has actually done a fantastic job of more deeply integrating with the operating system. They use the Share Charm for sharing to the Twitter app. They share from the Twitter app too. They’ve got Live Tiles… Jump Lists… Timeline… all sorts of integrations, with more on the way. It’s totally possible to build a website that acts much more like a traditional app with WinRT.
If the web’s so awesome, why put PWA’s in the Store?
The web is awesome and it’s a great distribution mechanism, but not everyone is used to looking for apps and experiences on the web. Being able to have your experience exist on the web, but also be discoverable via app stores can be the best of both worlds. And once you’re in a store, you also have the ability to promote your app alongside other apps as well, such as via the Start Menu on Windows or on listing pages in the stores themselves.
Who else is supporting PWAs?
PWAs have very broad support. Microsoft is, of course, supporting progressive web apps, but they’re also supported by Google, Apple, Mozilla, Samsung, Opera, and others. That means every major browser supports progressive web apps and, on certain platforms, some even give you the ability to install the app or add it to your home screen.
On Android devices you can install from Chrome, Firefox, Opera, and Samsung Internet. On iOS, you can install from Safari. On desktops you can install, of course, from the Microsoft Store and you’ll soon be able to install from Edge. You can also install PWAs from Chrome on both Windows and macOS.
How do I test my PWA on Windows?
Since a progressive web app is a website, you should be following a standard browser testing protocol, using your specific support matrix. If you’re trying to test specific functionality of your PWA through ServiceWorker, you’ll need to crack your browser’s dev tools. Microsoft Edge gives you the ability to inspect how your resources are being loaded within the ServiceWorker and you can check to make sure that everything’s happening the way that it should be.
If you have a PWA installed as a standalone app on Windows, you can use the Edge Dev Tools Preview to connect to that app. As a standalone app, a PWA is running separately from Edge, so you can’t launch dev tools like you’d normally expect to. The standalone Dev Tools app enables you to connect to any instance of Edge running within Windows. That means every Edge browser tab, of course, but it also means each browser extension and any running PWAs, which is pretty cool.
How do I add my PWA to the Microsoft Store?
The first step for adding your progressive web app to the Microsoft Store is to generate the AppX wrapper that hosts the PWA. A good tool for doing that is a free and open source tool called PWA Builder. You point that service at your progressive web app and it will generate an AppX wrapper for you.
The AppX is basically a container file (ZIP) that contains an AppX Manifest that points to your URL. There may be some tweaks that you’ll need to make in that manifest file (which is XML) if you want to enable geolocation, for instance, or light up some of the WinRT features to get deeper integrated into Windows, but the basic export out of PWA Builder will get you started.
You can test that export by side loading it onto your Windows Device. Then, when you’re happy with it, you can package that up and submit it to the Microsoft Store via the Dev Center. The Dev Center will walk you through the process of building out your app listing, enabling you to indicate who it should be targeted at and such. You can even target it to specific people or groups of people, enabling you to beta test your PWA. Then, once you’re ready you can flip it live and it’ll become available to anybody with Microsoft Store access.
Is Microsoft automatically adding some PWA’s to the Store?
Yes, Microsoft is actively crawling the web looking for progressive web apps. The Bing crawler is actively identifying PWAs by looking for a web app manifest. To us, that’s a clear signal that a site wants to be considered as an app. Now anyone who wants to be excluded from that crawl can block the Bing crawler from seeing the manifest in their robots.txt file.
If, however, you do want to be in the Microsoft Store, the process runs a little something like this:
- Bing finds a possible PWA;
- it runs some basic sanity checks for
- HTTPS,
- a quality Web App Manifest (not something auto-generated), and
- a service worker that does some basic offline stuff;
- someone checks to make sure the site abides by Microsoft Store policies.
The last bit is a way to weed out potential spam, malware, and phishing sites, but also adult content and subscription-based content (which, per current policy, need to use Store APIs for subscription management).
If your website meets all of these criteria, we will use the information you provide in the web app manifest to populate your PWA’s Store page. Down the road, if you’re interested in taking control of your app in the Microsoft Store, you can get a Developer account and we can transfer it to you.
Can I use web components when building PWAs?
Yes! (With caveats.)
If you take a look at the support tables on Can I Use, native support is pretty uneven across the browser scape. That said, there are polyfills that make web components cross-platform.
A lot of it comes down to how much JavaScript code you want to ship and whether the trade-off of code to end user benefit is worth it. For a fantastic discussion of these tradeoffs, JavaScript, developer convenience, and user experience, I highly recommend reading this piece from Alex Russell.
What’s the Return on Investment (ROI) for building a PWA?
Like many things, it depends. Every project is different and every project defines success differently. That said, companies that have embraced PWAs have seen pretty impressive successes. The kind folks at Cloud Four have an ongoing collection at PWA Stats.
If you’re looking for ideas around how your site could benefit from becoming a PWA, check out this piece in A List Apart: Yes, That Web Project Should Be a PWA.
What are some interesting uses of ServiceWorker you’ve seen?
One of the more interesting uses of ServiceWorker, in my opinion, was Dean Hume’s dynamic WebP image-swapping. Clever stuff!
He also has a pretty clever integration with the Network Information API that enables the Service Worker to decide whether to load images or swap in a blank SVG placeholder.
There’s also some clever ServiceWorker code that will re-play failed pings to Google Analytics. That gives you the ability to analyze offline usage of your site/app too.
What are some common misconceptions about PWAs?
Oh, so many…
- That you need to use [insert framework de jour here] to build a PWA. (You don’t.)
- That your site needs to be a Single Page App. (It doesn’t.)
- That your PWA needs to be an “app,” whatever that is. (Nope. Any site can be a PWA and most sites will benefit from becoming a PWA.)
What type of site or app is best suited for a PWA?
Any site can (and probably should) be a PWA. Yours included.
The way you choose to use PWA-related technologies is up to you. Not every site needs push notifications. (No, really, not every site needs push notifications.) Most sites can benefit from graceful offline handling. Every site can benefit from improved performance via caching.
If your question is more around whether it makes sense to go PWA or platform-specific, I’ve got some thoughts on that too.
Are there any Microsoft PWAs in the works?
I am aware of a number of Microsoft PWAs that are in the works. Teams was announced at Build this year. Office.com is on a path to becoming a PWA now too.
More soon
If you have a question about PWAs, hit me up on Twitter or via the contact form on this site.
Note: I no longer use “native” in this context, but it remains in quoted material.
{{ mention.author.name }}
Webmentions
Likes
Shares