Silent push notification denied: pushDisallowed

Question

Created Jun ’24

Replies 1

Boosts 0

Participants 2

Hi We are using silent push notifications in our app, these trigger our app to run code that syncs data with our server. This includes time sensitive data which the user will want to know about (which we send alerts generated on the device for). We know we are probably not using the notifications system as intended, we plan to rectify this soon using alert push notifications. To begin, we were willing to run the risk of sometimes having our code not be able to run in background, in exchange for less code complexity.

However we did not expect it to be this unreliable. The app is functionally never allowed to promptly run our sync code. We believe the likelihood of promptly being able to run code has also declined significantly in the last few months. It used to perform better.

There are of course many reasons that the app may be denied being able to run, battery, wifi / data, cpu. But when any of these are the reason these provide transparent rationale. The most common rationale we see is Rationale: [{[pushDisallowed]: Required:0.00, Observed:1.00},

TLDR "pushDisallowed" is a very opaque rationale, we were hoping to have some insight as what makes up the "pushDisallowed" reasoning.

Presumably there are many factors that go into this, a rough list would be very helpful. We aren't necessarily seeking an answer for why our app is being denied, but why apps in general are denied with this rationale. We cannot find anything in the documentation outlining this.

Full example console message

default	16:16:12.710320+1200	dasd com.apple.pushLaunch.nz.co.appName.ios:7808B2:[
	{name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{[pushDisallowed]: Required:0.00, Observed:1.00},]}}

Boost

Answer 1

Engineer OP

Apple

Jun ’24

The behavior you are seeing is expected, and it is NOT because content-available (aka "background" or "silent") push notifications are unreliable. These kinds of notifications will be 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. Furthermore, whether they will or will not be delivered right away is under the discretion of the APNs servers and the receiving device. They are absolutely not suitable to be used for time sensitive data.

You are correct about not using the notifications system as intended. If you have time sensitive information to pass to your app, you would want to send high priority alert notifications and handle them in 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, which will be delivered as soon as possible as long as the priority is set to 10.

As for the pushDisallowed messages you see in the console, yes, these might be opaque, but (putting aside that these are meant to help debug our own internal processes, and not indicators to apps about why they weren't being given runtime) the state of the device the app is running on and the long list of factors that result in this decision will be unique to every device, and determining the actual reason during your tests will not mean much to explain what might be happening in the users' hands. Making assumptions about reasons while your app is not working as intended on users' hands based on your own device state will only end up in making assumptions.

So, indeed, you may want to consider your risk taken without the results you were expecting, and implement alert notifications with a NSE for your time sensitive notifications.

0