Hello all 👋
We're developing an app for families with neurodivergent members (primarily autistic children) and have run into a critical reliability issue with silent push notifications that breaks core functionality.
Our current implementation:
When a caretaker updates the person's daily routine/schedule in our system, we send a silent push notification to the user's device. The app wakes, connects to our server, downloads the updated schedule, and creates/updates local notifications for upcoming activities.
The problem:
Because the app is rarely/never directly interacted with by the end user (the child doesn't open the app - caregivers configure it on their behalf), silent push notifications get progressively throttled and eventually stop being delivered entirely. This means schedule changes made by caregivers never reach the device, breaking the app's core value proposition. Uninstalling and reinstalling doesn't reset the throttling state
Questions:
Is there any way to reset or mitigate throttling for devices that legitimately need background updates but have low or no user interaction? This is an accessibility use case where the end user (child) doesn't interact with the app, but the app must reliably receive updates. Would switching to regular (visible) push notifications avoid this throttling even if the app is not interacted with?
We already have Critical Alerts entitlement, but for regular updates we're worried that the "CRITICAL ALERT" banner will be too upsetting for the child. Is there any exception process for accessibility apps to change the way Critical Alerts are presented?
For neurodivergent individuals, predictable routines are essential. When schedule updates don't reach their device, it can cause significant distress. This is a genuine accessibility need, not a "nice-to-have" feature.
Any guidance from Apple engineers or developers who've solved similar challenges would be greatly appreciated.
Thank you!
There are no exceptions, entitlements, etc. that will cut through the throttling of silent notifications. These are not a suitable solution if you need the app to process or take action for all sent notifications.
What you will want to use is a Notification Service Extension as described in the article Modifying content in newly delivered notifications
The NSE will be launched for every notification, and you can create your local notifications in the extension.
The main issue you might have is, these notifications will have to have visible content. While there is an entitlement you can request, your use case is not necessarily what it was intended for, and your request could be rejected. If you want to try anyways, that's up to you.
Without the entitlement, you could make the otherwise visible notifications less disruptive. By setting the interruption-level entry in your payload to passive.
Passive notifications (as described in Notification Payload key reference) will be visible in the Notification Center, but will not wake up the screen, or play a sound, or interrupt if another app is being used at the time.
You can try those out if it works for your clients, and if not, you can try and apply for the filtering entitlement. But a mismatch of supported use cases, and the recommended way of doing what you want is to send notifications at the time, you may want to keep alternative solutions in your back pocket in case your request is denied.
Argun Tekant / WWDR Engineering / Core Technologies