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.
Not all browsers support service workers, yet. As of this writing the only mainstream browsers lacking consumer release support are Microsoft Edge and Apple's Safari. Both have shipped support in preview browsers.
Microsoft has shipped in Windows Insiders builds since early October 2017. Apple delivered its first implementations in a recent Safari technology preview and continues to update about every 2 weeks.
We know Microsoft plans on making service workers live for everyone in the next major Windows release, known as 'RedStone 4'. This Windows update is expected sometime in the Spring of 2018, so very, very soon!
Apple is always a bit more foggy, but my guess is Safari will support service workers by next Fall on MacOS and iOS.
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?
Microsoft Edge Status
The site indicates when a specification support shipped, or if they’re developing a currently or have no current plans to support the feature. It also indicate that other browsers and their level of support as well as links to the actual specification.
Another neat feature of the site is also list community voice feature votes. The Edge User Voice site allows you to vote on what features the team should focus on.
I encourage you to check out status.modern.i.e., that way you can keep up with the latest trends and implementations. The site is useful because you will find specifications and features that you did not know existed.
What About Apple
We don't know when Apple will ship service workers to general consumers. It will ship when it ships if it ships.
That’s the general status of anything Apple.
With the recent activity of implementing service workers and web manifest support Apple is sending clear signals of PWA support. They have also become agressive rejecting apps from the App Store and recommending the web as a better choice to many businesses.
The signs of full service worker support on iOS are strong. My guess is September because that is when iOS updates ship to consumers. The current cadence from the Safari team is to post WebKit updates to Technology Preview subscribers about every 2 weeks. Each update has included service worker bug fixes and feature enhancements.
I don't know if they will support native push and background sync in the first implementation for consumers. But we should get cache and fetch event support in the first release since we are already seeing that in the TCP.
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, Safari and Edge.
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.
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 2 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.