Question
Silent push throttling prevents consistent background delivery for Swift notifications
Rey Nova
0 reputation · 26 Jul 2021, 17:55 UTC
142.6K views1
Loading…
0 reputation · 26 Jul 2021, 17:55 UTC
When designing a Swift notification strategy that balances useful alerts with minimal user noise, silent pushes using content-available:1 appear attractive because they avoid visible banners or sounds. However, iOS background execution limits can throttle these pushes, leading to inconsistent delivery of application(_:didReceiveRemoteNotification:fetchCompletionHandler:) callbacks.
Complicating this, if a user denies authorization after a UNUserNotificationCenter.requestAuthorization call, later attempts return granted:false without re-prompting unless the user manually changes Settings. Repeated requests can also trigger system rate-limiting, which silently drops further alerts until the app is opened.
Given these constraints, what is the recommended pattern for scheduling low-noise alerts that remain reliable? Should silent pushes be paired with local notifications and UNNotificationCategory.customDismissAction to reduce perceived noise, or does the risk of throttling make that combination unreliable? How should an app detect that it has entered a throttled or denied state without prompting the user repeatedly?
35275 reputation · 26 Jul 2021, 18:58 UTC
Do not rely on silent content-available:1 pushes as the reliable path for alerts. Use them for opportunistic background refresh. When the app has data worth surfacing, present a local UNNotificationRequest or send a visible remote notification with the lowest interruption level that meets your goal. Pairing silent pushes with UNNotificationCategory.customDismissAction reduces perceived noise only after a notification is actually delivered; it does not prevent or recover from OS throttling.
Missing application(_:didReceiveRemoteNotification:fetchCompletionHandler:) callbacks are most likely caused by iOS background-execution limits, Background App Refresh being disabled, Low Power Mode, or a force-quit. They are not proof that APNs rejected the message. Confirmed: APNs provider responses indicate acceptance by the push service, not device delivery. Also confirmed: UNUserNotificationCenter.getNotificationSettings returns authorization state without prompting, and requestAuthorization does not re-prompt after a prior denial.
swift.passive for no interruption, higher levels only when truly needed).getNotificationSettings to read authorizationStatus and UIApplication.shared.backgroundRefreshStatus without prompting.backgroundRefreshStatus, Low Power Mode, network conditions, and app state at send time. There is no public API that reports silent-push throttling directly.Background execution, throttling rules, and interruption levels are version- and device-state-dependent; verify on your supported iOS versions.
Does the alert need to arrive when Background App Refresh is off, Low Power Mode is on, or the app was force-quit? If yes, silent pushes are the wrong mechanism; use a visible remote notification or redesign the alert as non-critical.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.