I want to understand if my Remote notification will be throttled based on the payload that I am sending from my backend.
The confusion is due to the introduction of apns-alert-type key with possible values of alert and background.
I want to understand if I set the value of apns-alert-type to alert but include the content-available key in the aps dictionary, will such notifications be throttled if sent at a more than recommended frequency of two or three per hour?
I have documented by understand here in this sheet: https://docs.google.com/spreadsheets/d/13RU0tS9w4OsPpFjqPeoM0DNm045_5CF9DDdhIM9jarQ/edit?usp=sharing
Also adding the same here for easy reference:
| Notification displayed? | App woken up? | ||||||
| 1 | background | 5 | 0 | absent | Misconfiguration: content-available should not be 0. | ❌ | ❌ |
| 2 | background | 5 | 0 | present | Misconfiguration: content-available should not be 0. alert/badge/sound is not alllowed. | ❌ | ❌ |
| 3 | background | 5 | 1 | absent | Correct Configuration: This is a background notification. | ❌ | ✅ |
| 4 | background | 5 | 1 | present | Misconfiguration: alert/sound/badge is not allowed. | ❌ | ✅ |
| 5 | background | 10 | 0 | absent | Misconfiguration:priority 10 is not allowed. content-available should not be 0. | ❌ | ❌ |
| 6 | background | 10 | 0 | present | Misconfiguration:priority 10 is not allowed. content-available should not be 0. alert/sound/badge is not allowed. | ❌ | ❌ |
| 7 | background | 10 | 1 | absent | Misconfiguration: priority 10 is not allowed. | ❌ | ✅ |
| 8 | background | 10 | 1 | present | Misconfiguration:priority 10 is not allowed. alert/sound/badge is not allowed. | ❌ | ✅ |
| 9 | alert | 5 | 0 | absent | Misconfiguration: alert/sound/badge should not be absent. | ❌ | ❌ |
| 10 | alert | 5 | 0 | present | Correct configuration: Alert is shown w/o waking up the app. | ✅ | ❌ |
| 11 | alert | 5 | 1 | absent | Misconfiguration: alert/sound/badge should not be absent. | ❌ | ❌ |
| 12 | alert | 5 | 1 | present | Correct configuration: Alert is shown with waking up the app. | ✅ | ✅ |
| 13 | alert | 10 | 0 | absent | Misconfiguration: alert/sound/badge should not be absent. | ❌ | ❌ |
| 14 | alert | 10 | 0 | present | Correct configuration: Alert is shown w/o waking up the app. | ✅ | ❌ |
| 15 | alert | 10 | 1 | absent | Misconfiguration: alert/sound/badge should not be absent. | ❌ | ❌ |
| 16 | alert | 10 | 1 | present | Correct configuration: Alert is shown with waking up the app. | ✅ | ✅ |
For content-available notifications, there are two levels of "throttling" (to use that word).
One happens during delivery to the device. If the push type is background with no visible content, the priority must be set to 5. This may cause the notification delivery to be delayed as necessary depending on the state of the receiving device.
The second step is the "throttling" of the content-available notification being delivered to the app. This delivery is heavily throttled, and whether there is actual visible content, or what the push priority is does not matter. The throttle is the same, and the app can expect perhaps 1 or 2 notifications delivered to it every hour - although getting less or none is also a possibility, depending on the state of the device.
To summarize, the visible content, the push type, and push priority will effect the delivery of the notification of the device, but will have no effect on whether this notification is delivered to the app or not - which will be dependent on the on-system logic for delivery.
The WWDC 2020 video "Background execution demystified" (https://developer.apple.com/videos/play/wwdc2020/10063/) explains the factors that effect background runtime, and for this case, background delivery of notifications.
