User Profile

I had spent weeks looking for ways to make the silent notification more reliable as one of my app's functionality critically depends on it. So far, I couldn't find a satisfactory solution. During the course of it, I find that indeed the notifications are delivered and reach the device, but on the device, a daemon plays a gatekeeper and rejects it unless the device is in a state that meets multiple criteria. To check this in detail, connect your device to the console, and in its search box, add "dads" (it's the name of the daemon) & "your apps name".Use your app or a 3rd party app such as "Push Hero" (that allows easy generation of app targetted push notifications both alert- and silent-type) and examine what is printed out on the console under the set search criteria. You will find messages like:com.apple.pushLaunch.<your App ID>:627306:[ {name: DeviceActivityPolicy, policyWeight: 5.000, response: {Decision: Can Proceed, Score: 0.67}}] sumScores:95.343333, denominator:97.010000, FinalDecision: Can Proceed FinalScore: 0.982820}I found numerous criteria (CPU Usage, Device Polity, Thermal, ThunderingHerdEvents, DataBudgetPolicy, BatteryLevelPolicy...) that will affect "FinalDecision" to become "Should Not Proceed". That is when your silent notification (already on your device) is silently ignored to wake up the App. This is probably to prevent apps from abusing APNs to drain the battery or deteriorate performance, but even for a very small amount of tiny APNs, it gets harder than for a camel to pass through the eye of a needle. Virtual useless as far as my app is concerned. What a shame it is... Please post a reply if you came across a more up-to-date resolution for this issue. I'd appreciate it.

I just noticed the same problem. After about 30 minutes of frantic googling (nothing relevant turning up as of Mar 26-2020), it started to work again. bhugo's solution seems to resolve it (didn't check yet...). In addition to this, so many issues for remote push notifications, especially the inconsistent accepting/rejecting criteria for the silent (bg) push notifications. I feel like quitting developing for iOS.

I have the same issue. Too many things seem to conspire to prevent it from actually happening.1) Thermal state2) CPU usage3) a mysterious Device Activity Policy4) Thundering herd event, which seems to require at least 15 minutes before relenting5) and finally this "DataBudgetPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[/system/budgets/networking", which happens reliably whenever I switch from Wifi to cellular (I have ATT unlimited) - very occasionally, it seems to work in the wee hours - maybe I was hallucinating...., but during the day, the problem happens most reliably.I understand Apple's issue with too many apps trying to grab precious background resources with dynamic fluctuations, but trying to juggle a few ad-hoc criteria to allow/reject background notifications and/or background tasks is just inviting trouble.My app requires only a few robust silent push notifications that can wake up the app from suspension, but without requiring user intervention. It is probably a relatively feather-weight requirement(**) compared to various other usage scenarios, but as of now, I cannot achieve that. Apple should at least allow a budget, i.e. a number of total such tasks allowed per day per app before being limited by these intractable constraints.Personally, I wouldn't mind having just about a dozen such BGRefresh events allowed per day unconditionally before being shut out for the rest of the cycle. Is this asking too much?(**: parsing a simple payload in the silent notification and adjust the app badge icon number accordingly.)