Page MenuHomePhabricator

[Spike]: Explore breaking Push Notifications into Local Notifications
Closed, ResolvedPublicSpike


When we receive a push notification on device (via the PI Push Notification service via Echo via some notification worthy event), it's after some random delay added by the PI Push Notification service. This delay means a triggered notification message might not be received by a device until up to at worst five minutes later. In the time between a notification is scheduled to be delivered and the time it's actually received by a device, it's possible that other notification worthy events might have also happened and been scheduled to be delivered.

This means that when the iOS app receives a push notification, and it makes the remote notification API call to see what notifications are available, it may in actuality have either a. no new notifications or b. one or more new notifications available to display.

Our current solve for this situation is to display a generic "A new notification is available" message when no notifications are available, or a concatenated single message when one or multiple notifications are available at the time of API fetch.

The purpose of this spike is to investigate the feasibility of splitting the concatenated list of notifications into their own separate system notifications instead. This would be via use of iOS's Local User Notifications API. This is to confirm on a technical level we have product/design options in case we want to deviate from our current solution.

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald Transcript
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The primary goal of this spike was to discover if we could (from a technical level) leverage local user notifications to supplement our incoming push notifications in order to create separate more granular notifications (all in the case where the user receives a single push notification, but actually has many different notifications available in the remote notifications API).

For example, instead of displaying one large notification (“You’ve received 3 thanks, 2 edit reverts, and 3 talk page messages”), can we break these down into three separate ones (“You’ve received 3 thanks”, “2 of your edits have been reverted”, etc.) with discrete actions for each?

To test this, I updated the logic of the Notification Service Extension in the Notifications Utility test client. The Notification Service Extension allows us to modify the content of incoming visible push notifications. The modify distinction is important: while we can change the content (like title or body) of incoming push notifications, we can’t entirely discard the message – something has to be displayed. Since the PI push service delivers visible checkEchoV1 messages, we will have to implement a Notification Service Extension in the Wikipedia client in order to modify the content of the messages it receives (by making an API request to populate the user’s actual notification content).

An unknown that I confirmed here is that in fact we are able to access the user’s notification center related API to schedule a new local notification from within the service extension itself. A few more things I confirmed are that we’re definitely time and memory limited in the extension. If we don’t call the completion handler in the extension within around 30 seconds, it just delivers the original message it received from the push server.

Pros of breaking the remote notification into local notifications:

  • More granular, specific notifications
  • Relevant per notification type quick actions


  • Still can’t get rid of the initial “checkEchoV1” push message message
  • Needlessly complicated extra notification breakdown/management
  • Limited (<30 MB) memory availability in the extension
  • Limited (<30 seconds) runtime availability to complete all operations in the extension

To sum up, while it’s technically possible to leverage local notifications to break up a series of different notification types into separate notifications, I’d strongly recommend against that (unless we have a very strong product case for a very unique notification type) and that instead we just go with the large concatenated notification message to begin with.

A test of the local notifications work is available in this Notifications Utility branch.