UNUserNotificationCenter: Configuring Silent Notifications to Avoid Banner Noise

Answer to the Questions

1. Does UNNotificationPresentationOptions.banner override a silent push’s lack of visual presentation, or can a banner still appear under specific notification settings?

When a notification payload contains content‑available: 1 and no alert, sound, or badge keys, iOS treats it as a silent push. The system never considers it for visual display, so UNNotificationPresentationOptions.banner has no effect. The banner can only appear if the payload includes an alert dictionary or if the system is forced to present something (e.g., a user‑initiated local notification). In short: a truly silent push will never trigger a banner, regardless of user settings such as “Show Previews” or “Allow Alerts”.

2. Are there documented edge cases where a silent notification (content‑available = 1) will produce a visible banner or alert even when UNNotificationPresentationOptions is set to .none?

• Alert included in payload. If the server accidentally sends an alert dictionary along with content‑available: 1, iOS treats it as a normal notification. The UNNotificationPresentationOptions you set in the delegate only affects how the system presents that alert; it does not suppress the banner if the alert is present.
• Incorrect APNs priority. Sending the push with apns‑priority: 10 (foreground) can cause the system to treat it as a user‑visible notification even if no alert is present, because the high‑priority flag triggers immediate delivery and may prompt a banner under some rare user‑configurations. Using apns‑priority: 5 (background) is the safe choice.
• Background App Refresh disabled. If the user has turned off Background App Refresh for your app, iOS may drop the silent push entirely. In that case no banner will appear, but the background update will also not run.

3. What best‑practice configuration ensures silent notifications remain truly silent across iOS 10+ while still allowing background processing?

1. Request notification permission once (UI‑only) and enable Background App Refresh in the Xcode Capabilities tab.
2. Send a payload that omits alert, sound, and badge**:

{
  "aps": {
    "content-available": 1
  },
  "customKey": "value"
}

3. Set the APNs header apns-priority: 5 to indicate background delivery.
4. In application(_:didReceiveRemoteNotification:fetchCompletionHandler:) or the UNNotificationServiceExtension, process the data quickly and call the completion handler within the 30‑second window.
5. Do not set UNNotificationPresentationOptions.banner or any presentation options for silent pushes; they are ignored anyway.
6. Optionally, add a guard in your server code: if content-available is present, strip any alert, sound, or badge keys before sending.

With these steps, the notification will always be silent, the system will not display a banner, and the app will be given background time to perform its update.

Verification Checklist

• On device: Settings → Notifications → YourApp – ensure permission is granted and Background App Refresh is ON.
• Send a test push with the payload shown above.
• Observe that no banner appears and that your background handler logs the receipt.
• Check the console for the completion handler being called promptly.

Missing Diagnostic Detail

To tailor the recommendation to your environment, could you confirm whether the user’s Background App Refresh setting is enabled for your app? This influences whether silent pushes are delivered at all.