Introduction

On iOS 10, didReceiveRemoteNotification is not the callback for every push-notification scenario. Which method runs depends on whether the notification is visible or silent, whether the app is in the foreground or background, and whether the event is being handled through UNUserNotificationCenterDelegate instead.

Start with the iOS 10 Notification Model

iOS 10 moved notification handling into the UserNotifications framework. That means debugging begins with the modern setup:

1import UIKit
2import UserNotifications
3
4@main
5class AppDelegate: UIResponder, UIApplicationDelegate, UNUserNotificationCenterDelegate {
6    func application(
7        _ application: UIApplication,
8        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
9    ) -> Bool {
10        let center = UNUserNotificationCenter.current()
11        center.delegate = self
12
13        center.requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in
14            print("granted:", granted, "error:", String(describing: error))
15        }
16
17        application.registerForRemoteNotifications()
18        return true
19    }
20}

If authorization is missing or remote-notification registration never succeeds, none of the later callbacks will behave the way you expect.

The Callback Depends on the Scenario

This is the main source of confusion. On iOS 10, different notification scenarios use different callbacks:

• foreground visible notification: userNotificationCenter(_:willPresent:withCompletionHandler:)
• user taps a delivered notification: userNotificationCenter(_:didReceive:withCompletionHandler:)
• silent background notification: application(_:didReceiveRemoteNotification:fetchCompletionHandler:)

So if you are testing a visible alert while the app is open, didReceiveRemoteNotification may not be the method you see.

Foreground Notifications Use the Notification Center Delegate

If the app is open when a visible notification arrives, implement:

1func userNotificationCenter(_ center: UNUserNotificationCenter,
2                            willPresent notification: UNNotification,
3                            withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
4    print("foreground notification:", notification.request.content.userInfo)
5    completionHandler([.banner, .sound, .badge])
6}

This is the correct place to observe or customize foreground presentation on iOS 10 and later.

If the user taps a delivered notification, use:

1func userNotificationCenter(_ center: UNUserNotificationCenter,
2                            didReceive response: UNNotificationResponse,
3                            withCompletionHandler completionHandler: @escaping () -> Void) {
4    print("user tapped notification:", response.notification.request.content.userInfo)
5    completionHandler()
6}

Silent Push Uses the Fetch Variant

If your app is supposed to wake in the background and do work without showing an alert, the relevant method is the fetch variant:

1func application(_ application: UIApplication,
2                 didReceiveRemoteNotification userInfo: [AnyHashable: Any],
3                 fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
4    print("silent push:", userInfo)
5    completionHandler(.newData)
6}

For this to work reliably, the notification payload typically needs:

1{
2  "aps": {
3    "content-available": 1
4  }
5}

And the app must have the Remote notifications background capability enabled.

App State Changes the Observed Behavior

You should test notification delivery by specific app state, not as one generic feature:

• app in foreground
• app in background
• app launched from a tapped notification
• app receiving a silent push

Those are related but different flows. If you only say "push is not calling my method," you may be watching the wrong method for the state you are actually testing.

Registration and APNs Delivery Still Matter

Before blaming the callback, confirm that:

• the app requested notification authorization
• the device token registration succeeded
• the push payload is the type you think it is
• the notification is being tested on a real device

The simulator has historically not been the right place to validate full APNs delivery behavior.

A Practical Debugging Order

When didReceiveRemoteNotification is "not called," walk this order:

1. confirm notification permission
2. confirm APNs registration succeeded
3. identify whether the push is visible or silent
4. identify whether the app is foreground, background, or launched from a tap
5. verify the correct delegate or app callback is implemented for that scenario

That sequence solves most notification callback confusion quickly.

Common Pitfalls

• Expecting didReceiveRemoteNotification to handle every notification scenario on iOS 10.
• Forgetting to assign UNUserNotificationCenter.current().delegate.
• Sending an alert notification while expecting silent-push behavior.
• Missing the Remote notifications background capability for silent pushes.
• Testing only in the simulator instead of validating on a real device.

Summary

• On iOS 10, push handling is split across several callbacks depending on app state and payload type.
• Foreground and tap handling usually go through UNUserNotificationCenterDelegate.
• Silent pushes use didReceiveRemoteNotification with the fetch completion handler.
• Authorization, APNs registration, payload content, and background capabilities all matter.
• Debug notification delivery by exact scenario, not as one generic push path.