What Browsers Support Service Workers? ⚙️
Last Updated -
The most common question we get about service workers is what does browser support look like?
In particular do Service Workers work on iOS and iPhones?
Great questions – because service workers are relatively new, game changing technology.
Developers and technologist want to know if it’s safe to start investing their time and resources into creating service workers for their websites.
The last two major browsers to support service workers were Microsoft Edge and Apple's Safari. Both shipped support early access support in preview browsers just before Christmas 2017.
Microsoft Edge service worker support became available to general consumers on April 30th when the April 2018 Windows Update shipped to general consumers. Edge is currently the only browser supporting true native push notification support on Windows. By this I mean you do not need to have the browser open to receive a notification.
Apple surprised everyone when they made the iOS 11.3 update available with Safari 13, which included service worker support. This made service workers available on iPhones!
At this point all major browsers support service workers and progressive web app features. This is great news for businesses wanting to engage with customers. Developers also benefit because there is demand for skilled developers and a new area to explore.
Service workers are roughly 2 years old, and if you consider passing through the specification process there about a year old or less. However, browsers are investing heavily into service workers and supporting the different features recommended by the W3C.
The first browser to implement service worker support was Chrome, but Opera, Firefox and the Samsung browser now support service workers. Microsoft edge is currently working on their implementation, with plans to ship later this summer.
One browser stands out is not having any public statement on service worker support, Apple's Safari. Apple is notorious for not communication their intents to support technology, nor are they historically good at playing well with standards. However, there are some positive signs from Apple as to service worker support in Safari.
Apple has sent representatives to service worker standardization committee meetings and many are speculating the Safari team is working on service workers. If they do support service workers in the near future, we expect to see support when they ship their developer previews later this year. Since we don’t know until we know you will just have to stay tuned and see if they ship support this year.
Microsoft, is fully behind service workers and progressive web apps. They are working hard to get there service worker implementation shipped. Currently if you are on the Windows insider builds, you can turn service workers on in Microsoft Edge, which can be toggle behind a flag. You should be warned that they are an early, buggy preview.
Is Service Worker Ready
Jake Archibald, an evangelist for the Chrome developer team, maintains a site called 'Is Service Worker Ready?'. The site visually indicates browser support for service workers different key features of service workers and service worker dependency technologies.
The browsers include Chrome, Firefox, Opera, Samsung, Microsoft Edge and Apple Safari. If you see a green background it means they are supporting that feature and their latest public release. A yellow background indicates partial support the specification. A gray background means feature support has not shipped.
I like the way Jake represents support because he breaks down general service worker support as well as key aspects of service workers and its dependencies.
The first dependency service worker has is a browser supporting the Promise API. If you’re not familiar with promises it’s a clean way to code asynchronous functions and eliminates the need to work with callbacks. All modern browsers support promises, so there’s no need to worry about promise support. If a user's browser does not support promises you can dynamically load a polyfil.
The next key dependency is the Fetch API. If you are not familiar with Fetch you should get cozy with the API. It is a new way to make Ajax calls, and it supports promises. I won’t go into the details of Fetch, but just know that Fetch is a much cleaner way to make Ajax calls and will replace the traditional XML HTTP request object. The classic Ajax object will be deprecated in a few years and Fetch will completely take its place. So we do recommend you go ahead and start working with Fetch today.
The reason service workers depend on Fetch is because they need the fetch API to actually make calls to the network. The driving factor is Promise support. Remember service workers require asynchronous API support.
Service workers intercept requests to the network through a fetch event. The fetch event triggers every time a new file is requested from the network. You can assign a callback to the event handler, giving you power to serve cached response or construct a new one on the fly before hitting the network.
So it’s important to have fetch support before you have service worker support. Without it you cannot intercept calls and read through them to the network when necessary.
The final API browsers need to support is the cache API. The cache API allows you to persist request and response pairs. By accessing local cache you can return responses instantly and control how responses are cached, rather than relying on browser cache or appCache. Using the Cache API is outside the scope of the article, but a key part of our service worker courses.
As you can see most browsers currently support promise, fetch and the cache API. But what Edge, Safari and other browsers lacking support?
What About Apple and Progressive Web Apps on iOS (iPhone and iPad)?
On March 30, 2018 Apple updated iOS to 11.3 This update included Safari 13 with service worker and basic web manifest support. The initial offering included the ability to cache network addressable resources. This means your web sites can cache assets locally and load instantly, even when the device is offline.
This first service worker release is a little limited, but supports the most important caching features. Right now the background thread proxy functionality is supported in Safari and when launched from the home screen. Support seems to be limited in WebViews, which means you may not get the same support when opening links from native apps like Facebook.
Native push and background sync capabilities are not yet supported. I would not let this deter you from using service workers or upgrading your web sites to progressive web apps.
Apple has become agressive rejecting apps from the App Store and recommending the web as a better choice to many businesses.
What About Browsers That Don’t Support Service Workers?
If you develop your web app correctly then you should not worry about what browsers do and don't support service workers. So far, companies that have shipped progressive web apps have universally reported improvied key performance indicators. These include increased sales and higher engagement statistics.
While there is no true polyfil for service workers you can polyfil at least the caching capabilities. We started implementing client-side caching techniques about seven years ago when we started focusing on mobile first, off-line first websites.
Initially we would cache website assets in localStorage. Today we have migrated that indexedDB. We chose localStorage initially because indexedDB was not supported by Safari but localStorage was. IndexedDB is a better storage choice because it is asynchronous whereas local storage is synchronous. IndexedDB typically has more space available, however you probably wont need that much space.
Of course this technique will not be as performant as using service workers and the cache API. Caching this way will operate on the same thread with the rest of the UI. Our experience says this is not a noticable concern as you will typically see query times resolving within milliseconds.
This technique works in Internet Explorer and older Android and non-mainstream browsers.
Unfortunately you can’t polyfil push notifications because they do require background thread and platform integration. An alternative might be setting up an SMS based infrastructure. A service like Twilio can provide an easy to implement solution.
I did hear about a recent study that indicated that text messaging receives about three times the engagement level as push notifications, so it might be a good idea to implement an SMS infrastructure regardless.
Summary
So right now the current state of service worker support is pretty high. I’ve seen recent estimates that the number of users with browser supporting service workers has passed 4 billion. This creates a rich platform for us to develop websites that take advantage of service workers and create better user experiences.
We encourage you to go ahead and start adding service workers to your website. Remember, it’s going to be a journey not a sprint. So start with a simple service worker and get your feet wet and grow from there. This will prepare your website to handle today’s demands as well as many into the future.
Do you want a much more detailed set of progressive web app and service worker tutorials? I just launched a new course, Progressive Web Apps : From Beginner to Expert.
This course covers everything you need to know to make any website a progressive web application. There are beginner topics to help anyone get started with progressive web app and service worker development. There are also modules to teach you how to polyfil many modern PWA features like offline and add to homescreen tactics.
Enroll today and save $171 off the $200 price. Progressive Web Apps : From Beginner to Expert is only $29.