February 6, 2018 9:00 am

Welcoming Progressive Web Apps to Microsoft Edge and Windows 10

By (Senior PM Lead, Microsoft Edge Developer Experience), , and

A little over a year ago, we outlined our vision to bring Progressive Web Apps (PWAs) to the more than half a billion devices running Windows 10. We believe PWAs are key to the web’s future, and couldn’t be more excited about their potential to enable more immersive web app experiences across all device form factors.

Today, we’re excited to take a major step from vision to reality, starting with some updates on previewing PWAs in Windows and our roadmap to bring PWAs to the Microsoft Store.

Beginning with EdgeHTML 17.17063, we have enabled Service Workers and push notifications by default in preview builds of Microsoft Edge—you can learn more about those features in Ali’s post, “Service Worker: Going beyond the page.” This completes the suite of technologies (including Fetch networking and the Push and Cache APIs) that lays the technical foundation for PWAs on Windows 10.

Over the coming weeks, we’re also kicking off some experiments with crawling and indexing quality PWAs from the Web to list them in the Microsoft Store, where users can find them just like any other app on Windows 10.

In this post, we’ll give a quick introduction to Progressive Web Apps – what they are, the problems they solve, and how we’ll be enabling them across Windows 10. We’ll explore how our indexing experiments will ramp to an end-to-end PWA discovery experience later this year, and how we’ll empower developers to differentiate their PWAs on Windows – including allowing developers to claim and monetize their PWAs in the Store, interact with customers via reviews and telemetry, and enhance the app with WinRT capabilities.

Let’s dive in!

What’s a Progressive Web App, anyway?

The excitement about PWAs in the developer community is almost palpable – but amongst all that excitement, it can be hard to pin down a single, concise, authoritative definition of a “Progressive Web App.” For the purposes of this discussion, here’s how we define a PWA:

Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.

Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.

Unlike a “packaged” web app experience, PWAs are hosted on your servers and can be updated without issuing new updates to an app store. Additionally, new web standards (such as Service Worker) enable interoperable ways to implement push notifications, support for offline scenarios, background refreshing, and more, without platform-specific code.

It’s beyond the scope of this post to give a full crash course in the component technologies of a PWA (for that, we highly encourage you to check out Progressive Web Apps on MDN for a starter). But at a high level, these features are built to enable native-like capabilities – offline, background wake/refresh, instant loading, push notifications, and installability.

Progressive Web Apps in Microsoft Edge and Windows 10

So what about PWAs in Microsoft Edge and Windows 10?

We’ve announced before in several venues that we’re all-in on PWAs. In fact, as hinted above, we want to take PWAs on Windows to the next level, by making them first-class app citizens in Windows. This follows from our general philosophy that the web platform, powered by EdgeHTML, is a core part of the Universal Windows Platform on Windows 10. Because of this any device running EdgeHTML 17 gets full access to the technologies and characteristics of Progressive Web Apps.

On other platforms, PWAs primarily originate from inside the browser, and can escape the browser in response to various prompts or menu options. We’re taking things one step further on Windows! Because a PWA can be a first-class citizen in the Windows Store, a user will be able to engage fully with an installed PWA—from discovery, to installation, to execution—without ever opening the browser.

On the other hand, in the browser context, all the benefits of being a PWA should still accrue to the web site, empowering the user to choose how and where they want to engage with the experience.

Progressive Web Apps in the Microsoft Store

The first and most obvious distinction here is that we believe PWAs should be discoverable everywhere apps are discoverable – this means they should appear in the Microsoft Store alongside native apps.

In the next release of Windows 10, we intend to begin listing PWAs in the Microsoft Store. Progressive Web Apps installed via the Microsoft Store will be packaged as an appx in Windows 10 – running in their own sandboxed container, without the visual or resource overhead of the browser.

This has a number of benefits to users: PWAs installed via the store will appear in “app” contexts like Start and Cortana search results, and have access to the full suite of WinRT APIs available to UWP apps. They can differentiate their experience on Windows 10 with enhancements like access to local calendar and contacts data (with permission) and more.

It also has exciting benefits to developers! Listing a PWA in the Store gives developers the opportunity to get more insight into their users with channels like reviews and ratings in the Store, analytics on installs, uninstalls, shares, and performance, and more. It also provides more natural and discoverable access to your web experience on devices where the browser is a less natural entry point, such as Xbox, Windows Mixed Reality, and other non-PC form factors.

The road from the Web to the Microsoft Store

PWAs provide a natural signal of intent to be treated as “app-like” in the Web App Manifest, which allows us to leverage Bing’s web crawler in combination with our Store catalog to identify the best candidates for indexing.

The Microsoft Store has a two-pronged approach to publishing Progressive Web Apps:

  1. Developers can proactively submit Progressive Web Apps to the Microsoft Store
  2. The Microsoft Store, powered by the Bing crawler, will automatically index selected quality Progressive Web Apps

Submitting to the Microsoft Store with PWA Builder

Proactively submitting a PWA to the Microsoft Store requires generating an AppX containing your PWA and publishing it to your Dev Center account.

The easiest way to generate an AppX with your PWA is the free PWA Builder tool. PWA Builder can generate a complete AppX for publishing using your existing site and Web App Manifest – both website and CLI options are available.

PWA Builder logo

PWA Builder takes data from your site and uses that to generate cross-platform Progressive Web Apps.

Publishing manually gives you full access to the benefits above—fine-grained control over how your app appears in the Microsoft Store, access and the ability to respond to feedback (reviews and comments), insights into telemetry (installs, crashes, shares, etc.), and the ability to monetize your app. This also gets you access to all the other benefits of the Microsoft Dev Center, including promotion and distribution in the Microsoft Store for Business and the Microsoft Store for Education.

Automatically indexing quality Progressive Web Apps with the Bing Crawler

We’ve been using the Bing Crawler to identify PWAs on the web for nearly a year, and as we’ve reviewed the nearly 1.5 million candidates, we’ve identified a small initial set of Progressive Web App experiences which we’ll be indexing for Windows 10 customers to take for a spin over the coming weeks.

Diagram with three steps, reading: 1. Crawl and Index. 2. Convert to APPX. 3. Searchable/Browseable in Store.

We will crawl and index selected PWAs from the web to be available as apps in the Microsoft Store

Over the coming months, we’ll be ramping up our automatic indexing in the Microsoft Store from a few initial candidates to a broader sample. Throughout this process, we’ll continue to vet our quality measures for PWAs, to make sure we’re providing a valuable, trustworthy, and delightful experience to our mutual customers on Windows devices.

Whether automatically indexed by the Store or manually submitted by the site owner, the Web App Manifest provides the starting set of information for the app’s Store page: name, description, icons, and screenshots. Developers should aim to provide complete and high-quality information in the manifest. Once in the Store, the publisher will have the option of claiming their apps to take complete control of their Store presence.

Quality signals for Progressive Web Apps

We’re passionate about making the Microsoft Store a home to trustworthy, quality app experiences. With that in mind, we’ve identified a set of quality measures for developers to keep in mind as you build PWAs.

We won’t ingest every app that meets these criteria, but will be including them in our considerations for candidates as we gradually expand our program.

  • Web App Manifests should suggest quality: In our initial crawl of sites looking for PWAs, we discovered over 1.5 million manifests across 800k domains. Looking at a selection of these sites, we discovered that not all are good candidates for ingestion. Some aren’t PWAs at all, and others have a boilerplate manifest generated by tools like favicon generators. We will be looking for non-boilerplate manifests that include a name, description, and at least one icon that is larger than 512px square.
  • Sites should be secure: Access to the Service Worker family of APIs requires an HTTPS connection on Windows and other platforms.
  • Service Workers should be an enhancement: We’ll look for a Service Worker as a signal for ingesting PWAs, but we also expect experiences to degrade gracefully if Service Worker is unsupported, as it may be on older browsers or other platforms. You can get started building a basic Service Worker with PWA Builder; Mozilla also has great recipes if you are looking for somewhere to start.
  • Sites should consider automated testing for quality: There are a number of tools out there for this, including our sonarwhal, Lighthouse, aXe, and more.
  • PWAs must be compliant with Microsoft Store policies: PWAs will need to meet the standards of the Microsoft Store, just like any other app. We will not ingest PWAs that violate laws or Store policies.

Once we have shipped these technologies to mainstream Windows customers with EdgeHTML 17, we will gradually expand our indexing of high-quality Progressive Web Apps into the Microsoft Store based on quality measures and the value they add to the Windows ecosystem.


Given the overlap in terms of capabilities, we often get asked about the recommended approach: PWA or UWP. We see this as a false dichotomy! In fact, on Windows 10, the Universal Windows Platform fully embraces Progressive Web Apps, because EdgeHTML is a foundational component of UWP.

For developers who are building a fully-tailored UWP experience, building from the ground up with native technologies may make the most sense. For developers who want to tailor an existing web codebase to Windows 10, or provide a first-class cross-platform experience with native capabilities and enhancements, PWA provides an on-ramp to the Universal Windows Platform that doesn’t require demoting or forking existing web resources.

When evaluating native app development in relation to Progressive Web Apps, here are some of the questions we recommend asking:

  • Are there native features the Web can’t offer that are critical to the success of this product?
  • What is the total cost (time and money) of building and maintaining each platform-specific native app?
  • What are the strengths of my dev team? or How easy will it be to assemble a new team with the necessary skills to build each native app as opposed to a PWA?
  • How critical will immediate app updates (e.g., adding new security features) be?

In other words, the choice between PWA and native should be evaluated on a case-by-case basis. For example:

  • If you are looking to craft an experience that takes full advantage of each platform you release it on and you want to agonize over every UX detail in order to differentiate your product… native might be the best choice for you.
  • If you are maintaining a product on multiple native platforms in addition to the Web and they are all largely the same in terms of look & feel and capabilities, it may make more sense to focus all of your efforts on the Web version and go PWA.
  • If you are planning a brand-new product and the Web provides all of the features you need (especially when you also consider the additional APIs provided via the host OS), building a PWA is probably going to be a faster, more cost-effective option.

For a more in-depth discussion, check out our video from Microsoft Edge Web Summit 2017: PWA, HWA, Electron, oh my! Making sense of the evolving web app landscape.

Testing your Progressive Web Apps in Microsoft Edge and Windows 10

Service Worker, Push, and other technologies are enabled by default in current Insider builds in Microsoft Edge, and we intend to enable them by default when EdgeHTML 17 ships to stable builds of Windows 10 later this year.

You can get started testing your PWA in Microsoft Edge today by downloading a recent build of Windows 10 via the Windows Insider Program, or using a free VM. We’ll be sharing more about Service Worker debugging features in the Microsoft Edge DevTools in a future post—stay tuned!

Service Worker features will be enabled for the UWP platform (including installed PWAs) with the upcoming release of Windows 10, but are currently not available to published apps in the Store, including on Windows Insider Preview builds. In the meantime, you can test them in Insider builds by sideloading your AppX using the install script provided by PWA Builder tools, or by running your PWA inside Microsoft Edge.

What’s next for Progressive Web Apps on Windows?

Over the coming months, we’re laser focused on polishing our initial implementation of the core technologies behind PWAs in EdgeHTML and the Universal Windows Platform—Service Worker, Push, Web App Manifest, and especially Fetch are foundational technologies which have a potentially dramatic impact to compatibility and reliability of existing sites and apps, so real-world testing with our Insider population is paramount.

In our initial implementation, we’ll be focused on those two components—the Service Worker family of technologies in Microsoft Edge, and PWAs in the Microsoft Store. Looking forward, we’re excited about the potential of PWA principles to bring the best of the web to native apps, and the best of native apps to the web through tighter integrations between the browser and the desktop. We look forward to hearing your feedback on our initial implementation and experimenting further in future releases.

In the meantime, we encourage you to try out your favorite PWAs in Microsoft Edge today, and get started testing your installable PWA on Windows, both via PWA Builder and in Microsoft Edge! We look forward to hearing your feedback and to digging in to any bugs you may encounter.

Here’s to what’s next!

Kyle, Kirupa, Aaron, and Iqbal

Join the conversation

  1. Maybe implementing PWA for Windows 10 Mobile Edge browser would be a nice goodbye gift to those who have suffered stoicly from the app gap.

  2. So basically you are turning Windows 10 into a Chromebook. Problem is a real Chromebook is better as it support Android apps. So why do users need Windows 10?

    • Can chromebook run windows applications? Can chromebook run linux subsystem? Windows need Android App, are you kidding me

  3. The _only_ advantage Windows had in enterprises was that it was cheap to develop LOB applications in .NET. Since the future for you guys are PWA I don’t see any point of Windows 10 at all. And without Windows 10 I don’t see any point using Azure or Office 365 either.

  4. For “have access to the full suite of WinRT APIs available to UWP apps” the PWA can use the same rules for an Hosted Web App ? (Manifest Entry + Conditional js ?)

    Can a PWA have access to MyPeople (i think it requires the multiple instances run… is it handled by the container)?

  5. 1. Can PWAs be “installed” via Edge browser (like on Android and iOS) or they must be published to Microsoft Store to be installable?
    2. If they can be installed while being outside Microsoft Store, do “unpublished” PWAs have access to WinRT/UWP API?

  6. Please comment on PWA vs. Xamarin with regards to cross-platform development. Will my Xamarin investment survive in the era of PWAs?

    • I am only a web/mobile developer reader, but in my opinion native will stay, so Xamarin Cross-platform investment is ok. I think PWA is mainly a mode for those with web/JavaScript/css skill to survive in the Apps era. Maybe in the future cross-platform app development will be easier with PWA, for now i think is not the case.

  7. This is great and exciting news. Will we be able to take advantage of fluent design with transparency etc? We really need a competitor to Material Design and can you host a gallery of the best PWAs so users can find them.

  8. As chrome and chrome already dominates, pwa I don’t see why world needs another eco system especially considering edgehtml is not available on any mobile device. Given the frequency of Microsoft’s hit refresh cycle, I would say this is dead on arrival.

    • You make no sense. You claim that google’s eco system dominates pwas so we don’t need another eco system. This is the same ecosystem!

      • “I did not get why the world needed the third ecosystem in phones unless we changed the rules.” ~Satya Nadella

  9. All my connections lean heavily on the new UWP apps.
    This will be an addition for the lighter devices.
    All development continues as usual.

  10. Well I’m in two minds about this.

    On the one hand, PWAs in Windows is great… even if Edge still has miniscule market share.

    On the other hand, I’ve absolutely no intention of packaging my PWAs as APPX just so they show up in the Windows Store… Because frankly, neither myself or my users want or use that.

    The point of PWAs is you shouldn’t need to package for platforms – you upload to your server, users find the app using the greatest content discovery platform available – the web – and then you get started progressively enhancing the web.

    I’m not sure this post really follows the spirit of PWAs. Microsoft seems to be trying to take ownership of the PWA ecosystem, and then steer developers to solve its app gap problem by ignoring PWA principles and packaging as APPX.

    And some PWAs will get arbitrarily “ingested” and others won’t; you’ve told us some “quality signals” but then admitted “we won’t ingest every app that meets these criteria.” ???!!!???

    Wtf? This isn’t what PWAs are for. I’m a web dev, and if I can provide my PWA experiences for the few people who are using new W10 versions, and who are actually still using Edge, great.

    But I’m not going to be jumping through hoops to get into your walled garden, or start packaging my apps, or do anything along those lines.

    Tread carefully, Microsoft.

    • I think it’s because there are different perspectives on the situation. Microsoft see’s the Microsoft Store as the Google/Bing of applications that run on your computer. It’s indexing those services that work for your device. You can enhance what is displayed there if you want, but if it’s a PWA and it’s good…they’ll do the work of making it fit in the store. They’ve also been involved in website, web app, web service, (what ever you want to call it) being in the store for a while, and so that’s their perspective.

      Before PWA existed you could create web sites that worked in the store and worked offline and worked with notifications and live tiles and other “native” api’s. Then PWA was pushed by Google and instead of fighting, Microsoft said, “I think we can give in and stand behind this service so that the features we built for the Windows platform web developers will tie in with PWA so that users can create truly cross-platform apps.”

      Yes they are encouraging you to enrich the PWA for Windows, but Google and Bing encourages you to enrich your website for their search engines…so I don’t see any fowl in this.

  11. I’m a developer who has published a few PWAs. This is great news; I’m looking forward to my PWAs showing up in the MS App Store.

    Testing this out, there seems to be a bug with the PWA Builder. I ran one of my sites through it, and it generated an .appx – great. But when I submit that .appx to the store in my developer account, it shows an app with the default ManifoldJS logo as the app logo. (This, despite my app already having a .manfiest file that specifies images for the app logo.)

  12. Strong agreement with James Walker from me. It’s as if somehow you don’t get PWAs at all. You are trying to cram the open web into the Windows business model. That’s the wrong approach. No developer should have to specially package a PWA for Windows. If they do, that’s not a PWA! The idea is that a developer deploys their web app and then anyone can browse to it and install it directly from the site. No platform-specific packaging involved. What you are really announcing here is a new way to make UWP apps, not true support for PWAs. I’m hugely disappointed in the Edge leadership team.

    • Packaging your PWA for windows gives you the ability to use exclusive windows 10 features in your PWA applications that you don’t have on other platforms like live tiles and …

    • Since you strongly agree with James Walker, I’ll just encourage you to read what I responded to him rather than re-posting all of it.

      Consider this
      1st – Windows was offering offline web experiences with access to “native api’s” like notifications and live tiles long before PWA.
      2nd – Microsoft is doing a lot of the work for you. If you make a good PWA and they like it, they’ll put it in the store for you. If you’d like you can add it yourself or enhance it. The Store is an index of services that work well on the platform just like Google/Bing index websites.

  13. In regard to Microsofts’ strategy in packaging PWA’s to be downloaded from the store, this provides some of the vision for how a developer could sell an app on the Microsoft app store; however, there are some questions and concerns.

    Can any one explain how monetization will be handled through out the entire web and app store landscape (not just MS)? One important part of Googles’ justification for spearheading this initiative is to make “Apps” more discoverable.

    If a developer wants to sell an app and make it available on their web site, and on the App stores of MS, Apple, Google, how will all of that work? I hope MS’s plan for this will be well received after Google unveils whatever their strategy is.

    Additionally, how will in-app purchase work? To me it seems like there are many possibilities for monetization and many competing organizations going after their own agenda. I hope this doesn’t get botched for us developers and therefore botched all together.

    It seems like each company (MS,Apple,Google) should have a payment API that works similar to one another; where a developer could implement payments to the app store of their choice when either making an in-app purchase or when downloading the app outside of a store.

    I hope MS’s strategy is on point. If MS is trying to be a lone wolf in how this works, it will not be the success that they are looking for. Please share with us, whatever you can.