didReceiveRemoteNotification fires on Xcode build but not on .ipa builds.

Hi,

We are trying to implement a system that delivers real time data updates to our apps through the Firebase Cloud Messaging system using the REST API with the relevant payload. We set content-available to 1 so that the payload delivery is silent.

We use the didReceiveRemoteNotification delegate function to receive the push notification. It works seamlessly when the app is built through Xcode but when we tried it on an .ipa, the delegate function is not called.

We have tried setting different parameters in apps-priority and apps-push-type but without much success. Apple documentation points out that there are some restrictions when it comes to receiving silent push notifications in this way. But in our case, it looks like Xcode builds work perfectly while ipa builds are very spotty at best.

Is this not the right method to receive real time data updates? It was our impression that this is how chat apps for example are setup to receive real time text updates.

If this method cannot be used, does anyone have any other suggestion as to how to go about achieving the same behaviour within our apps?

Thank you! Fardin

Answered by DTS Engineer in 790990022

The behavior you are seeing is expected, and it is due to content-available (aka "background" or "silent") push notifications being throttled when being delivered to apps that are in the background.

Background push notifications are never guaranteed to be delivered to the app every single time. Notifications sent at low priority (priority 5) are throttled, regardless of payload. Background push notifications are always sent at low priority.

Although you may expect up to several background push notifications per hour across all apps on a device, it is entirely possible and appropriate that you may receive none at all. In addition to being throttled based on device state at the time, background notifications can be delayed when being sent from APNs, and will never be delivered to the app if the user has force closed it, or has not launched it for a while.

The throttle is disabled if you run your app with a debugger attached, which is probably what you have been seeing with your "Xcode builds". This allows you to test that your notifications are being received correctly, but should only be considered a best-case scenario.

As such, background pushes are not designed for, and not suitable to be used for running arbitrary code in response to every single notification request.

If the purpose of using silent notifications is to execute some code that is triggered remotely, I suggest looking into using a Notification Service Extension as discussed at https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension. The Notification Service Extension will be executed for every visible push notification. So, it could serve your needs, as long as the user has not disabled the visibility of your notifications through various settings. The service extension will not be executed for push notifications that will not be presented visually, therefore every push you send has to have visible content.

Chat apps may be eligible for a special entitlement that will allow you to silence the visible pushes by using a Notification Service Extension. You can read more about this here: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_usernotifications_filtering

The criteria for being eligible for this entitlement is explained at the top of the request form. If you believe your app's use case is suitable you could try applying for it, but you may want to consider your eligibility carefully before tying your time and resources to receiving this entitlement.

Accepted Answer

The behavior you are seeing is expected, and it is due to content-available (aka "background" or "silent") push notifications being throttled when being delivered to apps that are in the background.

Background push notifications are never guaranteed to be delivered to the app every single time. Notifications sent at low priority (priority 5) are throttled, regardless of payload. Background push notifications are always sent at low priority.

Although you may expect up to several background push notifications per hour across all apps on a device, it is entirely possible and appropriate that you may receive none at all. In addition to being throttled based on device state at the time, background notifications can be delayed when being sent from APNs, and will never be delivered to the app if the user has force closed it, or has not launched it for a while.

The throttle is disabled if you run your app with a debugger attached, which is probably what you have been seeing with your "Xcode builds". This allows you to test that your notifications are being received correctly, but should only be considered a best-case scenario.

As such, background pushes are not designed for, and not suitable to be used for running arbitrary code in response to every single notification request.

If the purpose of using silent notifications is to execute some code that is triggered remotely, I suggest looking into using a Notification Service Extension as discussed at https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension. The Notification Service Extension will be executed for every visible push notification. So, it could serve your needs, as long as the user has not disabled the visibility of your notifications through various settings. The service extension will not be executed for push notifications that will not be presented visually, therefore every push you send has to have visible content.

Chat apps may be eligible for a special entitlement that will allow you to silence the visible pushes by using a Notification Service Extension. You can read more about this here: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_usernotifications_filtering

The criteria for being eligible for this entitlement is explained at the top of the request form. If you believe your app's use case is suitable you could try applying for it, but you may want to consider your eligibility carefully before tying your time and resources to receiving this entitlement.

Thanks a lot for this. It’s very clear and informative and helps us assess the next steps for how we can proceed.

It appears that the Service Extension by itself may not be sufficient for us as we don’t want to present visual data, so we’ll look into our eligibility for the entitlement.

Kind regards, Fardin

didReceiveRemoteNotification fires on Xcode build but not on .ipa builds.
 
 
Q