Notifications

[alastaircoote]

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.