In the course of writing the README for the project, I found out that ServiceWorkerGlobalScope.skipWaiting() actually returns a promise... that returns immediately with a value of undefined:

https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/skipWaiting

Our version just returns undefined. Should be a pretty simple fix.

In browsers, you can run text(), json() and so on onRequest, the same as you can Response, because they both inherit from Body: https://developer.mozilla.org/en-US/docs/Web/API/Request

We should do the same too, to allow workers to parse content sent in (even factoring in the caveats of #1). Things to do:

• abstract out these functions from FetchResponse into a new FetchBody class, have FetchResponse inherit from it
• have FetchRequest also inherit from it, and read in the request body as an InputStream.

Without a LICENSE file all the work contained in this repo is considered to have their copyright assigned to the author. Adding a LICENSE file to the repo will help make it easier for others to contribute to this repo.

I've opened a bug for this: http://www.openradar.me/radar?id=4952053319204864 but so far no replies.

Any POST request coming from SWWebView doesn't have its HTTP body attached. Right now I have a very horrible patch on fetch that inserts the (string) body as a header before performing the fetch. The native code repatches this to be the actual body so no backend code ever needs to be aware of this, but there are still a lot of issues:

• It only works with strings.
• Presumably there is a character limit eventually.
• It doesn't cover POST page requests, and I don't know how it could.

There are some stopgap fixes we could implement:

• base64 encoding (to allow non-strings)
• sending the body though the JS API, returning a unique ID, then sending that in the header (to get around character limits)

But they're all pretty awful. Unfortunately the only real fix I can see is Apple fixing the original bug, but depending on how long that takes, we might need to implement some stopgaps. In the more immediate term, we could get some tests going to see what these character limits actually are.

This is a meta issue that will have to be split into multiple issues at some point, because there's a lot to do here.

Difference between iOS and Web APIs

The most fundamental and important difference is that the Web APIs are split between Push and Notification APIs. Right now Chrome enforces that you must show a notification in response to a push, but with the Budget API that's going to change.

iOS has a split, sort of, but it's not one that is very useful. You can send a silent notification, which would serve as the equivalent of a web push, but:

• it's throttled much more aggressively than a non-silent notification
• the app must be active in the background in order to receive it. This means that if a user has swiped the app out of the task switcher, you won't receive the notification at all.

The combination of those two factors leads me to think that I'd rather enforce that you have to show a notification in response to a push than mess around with silent notifications (maybe in the future we can make it a customisable thing). But this opens up a new issue: traditionally, the content of an iOS notification is decided on the server, not the client. So we wouldn't be able to mirror the web APIs for customising notification content locally. But...

Notification Service Extension to the rescue, ish

In iOS 10, Apple introduced Notification Service Extensions. They're small targets, separate from your main app, that are spun up whenever you receive a notification, and before it is displayed. Within a certain time limit, you can customise the contents of this notification before the user ever sees it. So we can spin up the worker, run the push event and listen for a showNotification call. But two big issues with these extensions:

• They run on a very, very tight memory limit. Apple doesn't say what that limit is, and I suspect it's dynamic, or depends on device. However, I ran some encouraging early tests that were able to create a JSContext, and assign an ArrayBuffer of about 8MB before the process was terminated. So we have some space to play with, I'm just not sure how much (once the rest of the worker APIs are added, which they weren't when I did those tests)

• They're in a separate process to the main app. It's quite plausible (likely, even) that a worker might call update() in response to a push, which might result in an entirely new worker being installed. The main app won't be aware of any of that happening. So somehow we need the extension to check if the main app is active in the background, and send updates over as needed.

Things to do

• Implement local notifications. By comparison to the rest of this, that's pretty easy.
• Set up those same tests I had running before to check that the worker runs OK in an extension. The only way to test one is to manually send notifications, so it'll take some work to get that going.
• Work out methods for cross-process communication
• Make an entry point that people can run in an extension (don't make an extension itself) that'll indicate whether it handled the push or not.