Silent pushes not delivered to the app on iOS 11

Question

I noticed that on iOS 11 beta 2, the silent notifications are not delivered to the application:didReceiveRemoteNotification:fetchCompletionHandler regardless the state of the app (background / foreground).

I implemented the UIApplicationDelegete method application:didReceiveRemoteNotification:fetchCompletionHandler and I send the following silent push

{  
  "aps": {  
    "content-available": 1  
  },  
  "mydata": {  
    "foo": "bar"  
  }  
} 

but the delegate method is not called on iOS 11.

It works fine on other versions of iOS and the documentation section Configuring a Silent Notification does not mention that anything else should be done.

Is this a bug in iOS 11 or did I miss something new in iOS 11?

Please note that I'm not talking about or using the UserNotification framework which should not be needed for sending silent pushes.

Here is a sample project that illustrates the issue (you'll have to set your own bundle id)

When you lunch the sample project and send a above payload to the app, you can use the macOS console to see that the push is correctly delivered to the device but not to the app.

UPDATE 10.08

It appears that the behaviour is random. Sometimes after restarting the device, the payload is delivered correctly but it stops working after a while.

As you can see on the following screenshot, the push marked as 1 is delievered only to the device and the push 2 (after device restart) is also delivered to the app.

UPDATE 14.08 - iOS 11 Beta 6

Still the same behaviour. Another thing that is supposed to work but does not is the following. When the application's scheme is set to "Wait for executable to be launched", a silent push is supposed to wake up the app and start it in background.

UPDATE 21.08 - iOS 11 Beta 7

Still the same behaviour and not updates from Apple in the bug report.

UPDATE 29.08 - iOS 11 Beta 8

Still the same problem. The steps to reproduce I use now are the following:

• In the Xcode project scheme, select "Wait for executable to be launched"
• Add a breakpoint in the didReceiveRemoteNotification: fetchCompletionHandler
• Start the app on device
• Send the above silent push

Expected: The app is brought from suspended state to background and the didReceiveRemoteNotification: fetchCompletionHandler is called

Actual: nothing happens

UPDATE 06.09 - iOS 11 Beta 10

I'm still having the same buggy behaviour. The ticket from Apple was updated with the following answer:

Apple Developer Relations September 6 2017, 10:42 PM Engineering has provided the following feedback regarding this issue:

We were able to get the sample app running and test the behavior. We didn’t see any issues when we tested this as described.

Pushes aren't guaranteed to arrive to the app when it is running in the background, and the logs here indicate we don't believe the app is being used enough to launch it.

We do see us delivering pushes from time to time when conditions are good.

We believe this is behaving correctly.

Update 11.09

My Apple bug report was closed and marked as duplicate of 33278611 which remains open

UPDATE 13.09 - iOS 11 GM

Thanks to kam800's comments (see below) I did more testing and came up with those observations:

There seem to be a new daemon in iOS 11 dasd DuetActivitySchedulerDaemon that either completely discards the data push or delays the data push delivery:

Delivery postponed

Console Logs

default 13:11:47.177547 +0200   dasd    DuetActivitySchedulerDaemon CANCELED: com.apple.pushLaunch.net.tequilaapps.daylight:C03A65 <private>!   lifecycle   com.apple.duetactivityscheduler
default 13:11:47.178186 +0200   dasd    DuetActivitySchedulerDaemon Removing a launch request for application <private> by activity <private>   default com.apple.duetactivityscheduler
default 12:49:04.426256 +0200   dasd    DuetActivitySchedulerDaemon Advancing start date for <private> by 6.5 minutes to Wed Sep 13 12:55:31 2017   default com.apple.duetactivityscheduler
default 13:21:40.593012 +0200   dasd    DuetActivitySchedulerDaemon Activity <private>: Optimal Score 0.6144 at <private> (Valid Until: <private>)  scoring com.apple.duetactivityscheduler
default 13:21:40.594528 +0200   dasd    DuetActivitySchedulerDaemon Setting timer (isWaking=1, activityRequiresWaking=0) between <private> and <private> for <private>  default com.apple.duetactivityscheduler

Postponed delivery issues

• When the data push delivery is postponed and the app is launched, the data push is delivered only when the delivery date is reached which can be several minutes in the future. This defeats completely the purpose of using data pushes to keep the new app's content ready for the next launch. I quote here once again Apple's documentation:

"Silent notifications improve the user experience by helping you keep your app up-to-date, even when it is not running."

• When two data pushes are sent to a suspended app they are postponed by iOS 11 instead of waking up the app directly. When delivery time is reached, only the last data push is delivered! The previous pushes are lost and not delivered via the delegate method resulting in a data loss.

Delivery cancelled

Console Logs

default 13:35:05.347078 +0200   dasd    DuetActivitySchedulerDaemon com.apple.pushLaunch.net.tequilaapps.daylight:C03A65:[
    {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}}
 ], FinalDecision: Must Not Proceed}    scoring com.apple.duetactivityscheduler

Cancelled delivery issues

Well in this case, the data push is completely lost and never delivered on iOS 11 while it was delivered correctly on iOS 10.

UPDATE 19.09 - iOS 11 GM

I also noticed that when the application is in the foreground and the notification is not delivered to the app, I see the following logs in the console:

default 08:28:49.354824 +0200   apsd    apsd    <private>: Received message for enabled topic '<private>' onInterface: NonCellular with payload '<private>' with priority 10 for device token: NO   courier-oversized   com.apple.apsd

fault   08:33:18.128209 +0200   dasd    Foundation  <NSXPCConnection: 0x151eee460> connection from pid 55: Exception caught during decoding of received message, dropping incoming message.
Exception: Exception while decoding argument 0 (#2 of invocation):
Exception: value for key 'NS.objects' was of unexpected class 'NSNull'. Allowed classes are '{(
    NSArray,
    NSData,
    NSString,
    NSNumber,
    NSDictionary,
    NSUUID,
    _DASActivity,
    NSSet,
    _DASFileProtection,
    NSDate,
    NWParameters,
    NWEndpoint
)}'.    general com.apple.foundation.xpc

Conjectural

I see the same issue. – Choirmaster

what is the payload you are sending? – Armin

@Armin the one that is in the origianl post – Conjectural

@Conjectural yeah you are right. I tested it and behaviour is random. If the application is in foreground it might 1 notification but if it is background it doesn't get any notifications. Can you add a link to the case you opened in Apple – Armin

Still the same on iOS 11 beta 6. I've updated the main question. I cannot link to the bug report since they are private and accessible only to Apple – Conjectural

@Conjectural please keep updated on this. I have an interesting observation though If your device is attached to the debugger and is running with development profile I can get silent notifications perfectly but as soon as I dettach the debugger the notifications are not sent – Armin

Still not fixed in Beta 8....... – Stingaree

yes, I updated my original post with additional steps to reproduce. I also updated the reported bug at Apple – Conjectural

still not fixed in Beta 8, when I look in the console I see the following error: <NSXPCConnection: 0x123f43620> connection from pid 58: Exception caught during decoding of received message, dropping incoming message. Exception: Exception while decoding argument 0 (#2 of invocation): Exception: value for key 'NS.objects' was of unexpected class 'NSNull'. Allowed classes are '{( NWParameters, NWEndpoint, NSArray, NSData, NSString, NSNumber, NSDictionary, NSUUID, _DASActivity, NSSet, _DASFileProtection, NSDate )}'. – Manos

I don't see this error message in the console. Do you send the same push payload as in the original post? – Conjectural

It does not matter what I send as long as it contains "content-available": 1 - but yes, I also get this error with sending exactly the payload of the initial post – Manos

I would cautiously say it looks better in iOS 111 Beta 9 - first tests look promising – Manos

have you tried using the "Wait for executable to be launched" in the scheme to simulate an app in a suspended mode (see Update 14.08 above) ? In my case, this still doesn't work. – Conjectural

@Conjectural yeah, guess I was to early with my celebrations - it is still not fixed :/ – Manos

Hello, I was struggling with this bug recently... The bug occurs only when you send something more with the payload. If you send just this json { "aps": { "content-available": 1 } } the breakpoint will actually work in background, but only in background... hope this will help a bit with your testing – Induction

For me the scenarios is: When debugging, both foreground and background works (breakpoint at didReceiveRemoteNotification). When signed with ad hoc, foreground never worked. Remote silent push is delivered in background, didReceiveRemoteNotification only gets triggered if user launch the app by tapping the notification. Consistent behavior across all betas including GM. :( – Smoot

@Smoot All this discussion is about silent pushes so your case where a user taps on a notification is out of topic. Did you try sending a silent push when the app is "suspended"? – Conjectural

@DominikBucher, removing a custom payload did not change anything for me – Conjectural

@Conjectural Yea i attached an alert title to my silent push notification (although im not supposed to) just to make sure the notification is sent successfully. Cuz I can't even find the push notification payload log in my console or xcode device log. I can't say for sure whether my app is suspended or background state when I send the push. Update: With new GM xcode 9 (9A235) and iOS 11 (15A372), my app never stops at didReceiveRemoteNotification breakpoint in debug mode anymore. – Smoot

@Conjectural which xcode version do you use? I was on xcode 8 and everything worked fine... – Induction

@DominikBucher I tried both Xcode 8 and 9 but running iOS 11. – Conjectural

@Smoot so simulate a "suspended" mode where a silent push should bring back the app to background, you can use the "Wait for executable to be launched" in the scheme setting (see my original post) – Conjectural

@Conjectural Me too and it worked for both cases... Have you tried it in background? when you send the notification without unnecessary payload the breakpoint should stop, but only when you are on springboard with debugger attached to app... I am 100% sure about this.. – Induction

@DominikBucher just tried it and the behaviour does not change without a payload. Can you use the macOS Console, filter for dasd and post what does it say when your push is received (in suspended mode) and your breakpoint it hit? – Conjectural

So iOS 11 is released and it seems to be the same build as the GM. In other words the issue is still happening making the silent pushes unusable on iOS 11 – Conjectural

Another easy way to reproduce it is to set the UIApplicationExitsOnSuspend key in the app's plist, launch the app then press the home button. The app is directly brought to a suspended mode. When you send the silent pushes at this time, they are not delivered as I mentioned in my "UPDATE 13.09 - iOS 11 GM" – Conjectural

did some testing again today with the iOS 11 (15A372) - I got the was of unexpected class 'NSNull' error constantly, after rebooting the device everything worked as expected – Manos

yes exactly, After a while is starts again though :/ – Conjectural

Having the exact same issues - @Smoot has said only when signed with an ad-hoc certificate. Are you seeing correct behaviour when signed with production cert? ie. pushes recevied in active state as expected. Is this behaviour with you only through Xcode / ad-hoc cert? – Rosecan

I'm getting the same result with iOS 11 (not before), if I send with the push with "content-available": 1, and the app is in foreground, the callback will not be fired. – Streetlight

@Streetlight do you have the UIBackgroundModes set to remote-notification in your plist? – Conjectural

Yes, of course. And as read in above comments, rebooting the devices solved the issue so far, which drives me crazy to be honest. – Streetlight

@Rosecan Release cert same behavior with ad hoc cert. Latest update for me is: when debugging, both foreground and background works. When signed with adhoc/release cert, foreground works; background doesn't. I filed a bug report with logs 34489256 but got marked as duplicated as 33278611. – Smoot

thanks @xianxin, what's the general consensus, does this seem to be something that Apple will rectify? An amazing bug - silent pushes rendered useless. – Rosecan

Any workaround to this situation? because i dont see a solution in the near future – Skewbald

I was testing this behavior also the last weeks with no success.... to my confusion, the application(:didReceiveRemoteNotification:fetchCompletionHandler:) works again. -> After reading the release notes I additionally added the following empty function to my code: application( application: UIApplication, performFetchWithCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void). I'm not 100% sure if this is linked to the issue, but you can give it a try - it works in foreground and also in background – Phthisis

I opened a thread also in stackoverflow and answered my own question here: #46330553 – Phthisis

I opened another bug report on this with apple - this has broken our app completely. – Hatred

@Hatred it would be great, if you can also join our group chat conversation, lets see what apple responses: chat.stackoverflow.com/rooms/155203/… – Phthisis

Seems fixed in iOS 11.0.1 (still broken on High Sierra though). – Simmons

@Simmons - no it's not fixed. just tested it – Phthisis

@JanApotheker, it is not fixed in iOS 11.0.1. I have contacted the Apple and they said this is a bug. Also I realise the issue is, OS is cancelling launching the app in the background. iPhone dasd(DuetActivitySchedulerDaemon)[153] <Notice>: Removing a launch request for application <private> by activity <private> – Phillips

Ok. At least push delivery in the foreground works for me again (which was broken in iOS 11 GM). Has anyone tested it with the 11.1 beta yet? – Simmons

The new iOS11.1 beta1 contains a fix for this. – Hatred

After testing with the new iOS11.1 beta 1 it appears that this has been fixed now and is working as it was before on iOS 10 – Hatred

I'm having similar issues with iOS 11.0.1. It is difficult to test because it seems that sometimes the pushes are actually delivered, albeit late. And when they are, the delegate isn't called. – Chromatology

@Chromatology you should try 11.1 beta – Phthisis

I just tested 11.1 beta 1 and the issue was NOT fixed in my case. The first notification came immediately, the next were delayed like in 11.0 – Underwent

same problem here, using a debugger the notification come immediately, without debugger (over wifi or cable) the notification not even come ... someone out there solve this issue ? – Cesium

Whatsapp seem to have had a similar issue whatsappen.com/news/5465/… Something about users that "habitually force close their apps" which is most developers... – Maryammaryann

@Sausagedioxide The push token can change anytime and it is documented. It was changing all the time after a app reinstallation. This is off topic though as it’s not related to the notification delivery – Conjectural

@Gruntcakes I don't think What's App is using remoteNotifications for their push notifications to notify the user – Phthisis

My guess is that WhatsApp are using PushKit which is more reliable and they do provide VoIP. But all this WhatsApp conversation is off topic – Conjectural

Still problems in 11.1 B5:For me its easy to reproduce problems with silent push when the app is in the foreground with Beta 5 - a) run the power down to less than 20% and then they are not delivered (even if the device is plugged in to power) b) if battery is about 35% and the user has also turned on Low Power Mode, then they are not delivered c) change the priority and expiry values after having previously sent some pushes with different values seems to sometimes stop it from working until the device is rebooted. Things have improved though for when in the background with 11.1 – Dock

Defiantly there are still problems with 11.1 Beta 5. I've been extensively testing for days. In particular when apps are in the foreground the pushes can just stop being delivered. Whats interesting is if they stop for app A, then at the same time they may continue to work for app B. But another time or day app B may not work and app A does. Implying as well as device factors affecting the delivery (battery strength, charging, Wifi enabled etc.) each app may also have some budget limit. Apple have previously documented there are device push budgets, now there may be also app push budgets. – Dock

And exactly the same with the public release of 11.1. If you are using silent pushes and your app is in the foreground, don't expect them to be delivered depending upon several things, but primarily battery levels, even if the device is plugged in to a power supply. – Dock

Seems, Still issue appear in iOS 11.2.6. – Birmingham

i am facing same issue in 11.4.1 veriosn – Lodestar

@Jan, great answer and follow-up with the latest iOS versions. Have you had the chance of testing this on iOS 12? – Bind

I'm experiencing this problem on iOS 14 and on 14.2 Beta. Not getting a single background push, even leaving the it for 24 hours. – Vulcanite

The answer in this post worked for me: https://mcmap.net/q/144423/-ios-silent-push-notification-cancelled – Friday

Answer 1

So the release notes of iOS 11.1 beta 1 say

iOS 11.1 beta 1 was just released and they mention: "Notifications Resolved Issues • Silent push notifications are processed more frequently. (33278611)

I did some tests and it seems to be indeed fixed:

Suspended State

When I launch the app in a suspended mode and send a silent push, the app is brought back to background and the didReceiveRemoteNotification:fetchCompletionHandler delegate is called.

Foreground State

In the same way, when the application is in foreground and a silent push is sent, the delegate seems to be called as expected. This was randomly not working in previous iOS 11 versions so I will confirm this after more testing.

Conjectural

On my initial testings I thought it was fixed. It worked for a while. But after some heavy testing, things started to fall a part. Suddenly it stopped calling the delegate for every silent push, even with the app in foreground. Apparently, this new "duet" system is blocking my app's delegate to get called due to the lack of "energyBudget". So, unfortunately, still not fixed. – Lith

unbelievable :( – Manos

My experience is the same as Abras above. Worked for a while then fell apart and the handler was no longer called - this sucks, – Hatred

After more testings I was able to find a way to make the device receive notifications again. Connect it to power. As soon as you connect the device to power it will start receiving all Remote Notifications again. If you disconnect it, then it stops. This makes no sense, because in all my testings the app was in foreground. And foregrounded apps are guaranteed to receive Remote Notifications. – Lith

for me it's all working well even when on a cellular connection without being connected to a power. Only when I set the device to power saving mode then I don't get the pushes even when in foreground. But that's something I'd understand – Conjectural

Thank you Jan. We will test also and get back to you... this is really good news.. and hope it is true. – Lauter

Low Power Mode always disabled Remote Notifications. Even on iOS 10. That's the correct behavior. After my device's battery reached 100%, it started receiving the Remote Notifications again, even without being connected to power. – Lith

testing on ios 11.1 (beta downloaded from the developer site) works for me. I don't see the Must Not Proceed decisions like before, the notification seems to have Can Proceed every time. – Flesh

Note though that the notification seems to be a bit delayed (~ 10-15 mins) from the time that it was sent. github.com/e-mission/e-mission-phone/issues/… – Flesh

@Conjectural Do you know if Apple has a release date for his iOS11.1 beta version – Phthisis

well the iOS 11.1 beta 1 is already released to developers. If you mean a release date for the 11.1 (non beta), I don't know – Conjectural

Answer 2

Just wanted to add my 2 cents in here as I've been hit by this issue too and I've noticed that Apple has closed several radars on this issue saying they couldn't reproduce. An interesting thing I found is that the pushes will get delivered if the app is backgrounded while it's attached to the debugger.

If I kill the debugger, unplug my phone, launch the app, and send the silent push payload I see the app NOT getting woken. I do see the in the Console log that the system cancels delivery of the payload to my app.

I've submitted a radar with a small sample app that reproduces the problem. I've also explicitly noted in the radar that the person working on my ticket must not be running the app attached to the debugger to reproduce the issue. Here's the link: https://bugreport.apple.com/web/?problemID=34461063

Hopefully this will cause some progress to be made on this issue.

Estaminet

Thanks for the report. Btw, linking the Apple bug won't help here as they are private and only the reporter and Apple can see them – Conjectural

I would like to see more people use openradar.appspot.com so that we could keep track of other peoples radars – Manos

are there any updates on your bug reportwith apple @bill – Rosecan

I haven't gotten any updates on my radar from Apple but we've installed the beta of iOS 11.1 and it appears the issue is fixed. – Estaminet

Yes, we are also facing the same issue in iOS 11.2.6, Any solution or updates? – Birmingham

@Birmingham i also face same issue, if you find any solution then please help me. – Polyphony

Answer 3

Looks like a new behaviour of iOS 11. iOS 11 beta 10 provides some descriptive logs regarding this issue:

default 23:18:51.806011 +0200   dasd    com.apple.pushLaunch.com.acme.Acme:F7E7D0:[
    {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Can Proceed, Score: 0.50}}
    {name: BatteryLevelPolicy, policyWeight: 1.000, response: {Decision: Can Proceed, Score: 0.87, Rationale: [{batteryLevel == 62}]}}
    {name: DeviceActivityPolicy, policyWeight: 5.000, response: {Decision: Can Proceed, Score: 0.20}}
 ] sumScores:52.279483, denominator:81.410000, FinalDecision: Can Proceed FinalScore: 0.642175}
default 23:18:51.806386 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' has compatibility score of 1.000000 with 'com.apple.CFNetwork-cc-111-79:E7272D'. Relaxing scores.
default 23:18:51.806855 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' CurrentScore: 0.642175, ThresholdScore: 0.738454 DecisionToRun:0

Looks like every silent push is delivered to the iOS, but dasd daemon uses couple of policies to decide if silent push should be delivered to the app (e.g. battery level). I managed to receive one silent push yesterday night, but my iPhone was connected to charger at that time – probably BatteryLevelPolicy score was high enough to receive that one silent push.

Apple gives no official information about this iOS-side behaviour, there is only information about server-side throttling:

Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour.

I keep my fingers crossed they changed that behaviour, because that would fix my app :) On the other hand, this change is good – one among many things making iPhone battery lasting longer that Android phones.

Nit

Yes the pushes are delivered to the device but not to the app. That's what I wrote in my original post. "Silent notifications are not meant as a way to keep your app awake in the background" this is ok as long as they are delivered "sometimes". The big problem is that silent notification are never delivered to the app in iOS 11 when it's in the background. This defeats completely the entire purpose of data pushes. – Conjectural

Yes, you already wrote that, I just wanted to provide full explanation regarding these new push policies. I quoted Apple docs to show that they already warned about push-delivery uncertainty. As I wrote: "I managed to receive one silent push yesterday night" (in the app I meant), and the app was in background. But in the day – my app receives no pushes :( In my opinion Apple will loosen these push-policies in RC version. On the other hand, they could restore the original push behaviour – they already used to get rid of features provided only in beta versions (e.g. 10.3 keychain autodelete). – Nit

I see similar logs when the push is received and the app is suspended. The dasd process then logs default 10:17:42.994236 +0200 dasd DuetActivitySchedulerDaemon Advancing start date for <private> by 6.3 minutes to Wed Sep 13 10:24:03 2017. The silent push seems to be delivered at that time. – Conjectural

already started testing with iOS 11 GM, still seeing weird behaviour, logs like com.apple.fetch.com.troii.timriphone:F613DA:[ {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}} ], FinalDecision: Must Not Proceed} – Manos

Also when comparing to a behaviour in iOS 10, I don't see any logs on iOS 10 from this dasd DuetActivitySchedulerDaemon` where the push is delivered directly. – Conjectural

@ThomasEinwaller I'm seeing randomly the same logs and behaviour. I updated my original post with a sum up – Conjectural

iOS11 silent pushes are not totally cancelled in my scenario. I received couple of silent pushes, but they seemed to be postponed. – Nit

Also - I managed to solve my app by sending non-silent push with some stub notification, and filling the notification with right content using Notification Service Extension. – Nit

Answer 4

iOS 11.1 beta release notes include: Notifications Resolved Issues Silent push notifications are processed more frequently. (33278611)

Ortego

Answer 5

iOS 11.1 Beta 2 also contains

Notifications
Resolved Issues
• Silent push notifications are processed more frequently. (33278611)

in Release Notes - will test it now.

UPDATE - 11.10.2017 - iOS 11.1 Beta 2

After using our App for 2 days in "real world scenarios" it looks like there is a real improvement in this version of iOS. I am cautiously starting to believe this is fixed.

Manos

I tested different scenarios: It was working in foreground and background state. Unfortunately it doesn't work, if the app was terminated by the user. After terminating the device doesn't receive any silent push, as long as the app is not actively launched again by the user. Did you experience the same? – Phthisis

now it works... after a 'downtime' of approx. 5 to 10 minutes the silent notifications are working as expected... sorry for my prev. comment :) – Phthisis

silent pushes never worked when the user terminates the app - see developer.apple.com/documentation/uikit/uiapplicationdelegate/… "However, the system does not automatically launch your app if the user has force-quit it." – Manos

@AlexWoe89, if app is terminated (I interpret it as 'killed') your app will never wake up by the OS, whether your OS is iOS 11 or 10 or 9, your app won't wake up. It will wake up if your app is in suspended mode, which means not killed! So according to this author of the post, iOS 11.1 beta has fixed this issue. I hope so as I haven't tested it yet. – Define

This is a pretty serious bug. I hope Apple releases iOS 11.1 with the fix soon. Looking back from iOS 8, 9 and 10, version x.1 usually is released around October 20-25th. I really hope they release even sooner than that this year, as this is a bug that breaks many apps. – Nowak

I am seeing that iOS11.1 beta 3 is working much like iOS10 was and a lot better than iOS11.1 beta 2 was. – Hatred

iOS 11.1 beta 4 was released and it seems to be the GM (no letter at the end of build number). Is the fix stable on beta 4? Does it work now as before iOS 11.0? – Nowak

@Nowak for me iOS11.1 beta 4 is working like iOS 10. – Phthisis

I am testing on iOS 11.1 beta 5 and it doesn’t seem to have fixed the issue for me. I get the remote notifications for 15 minutes after I lock the phone. If I leave it there, it seems to be in “deep sleep” and does not get silent pushes until I manually unlock the phone. Can anyone reproduce this behaviour on 11.1b5? @Phthisis – Nowak

For me its easy to reproduce problems with silent push when the app is in the foreground with Beta 5 - a) run the power down to less than 20% and then they are not delivered (even if the device is plugged in to power) b) if battery is about 35% and the user has also turned on Low Power Mode, then they are not delivered c) change the priority and expiry values after having previously sent some pushes with different values seems to sometimes stop it from working until the device is rebooted. This is when the app is in the foreground, things have improved for when in the background. – Dock

Answer 6

Apple Developer Relations just added a comment to my radar:

We believe this issue is resolved in the latest iOS 11.2 beta.

Please test with the latest iOS beta. If you still have issues, please update your bug report with any relevant logs or information that could help us investigate.

https://developer.apple.com/download/

currently installing iOS 11.2 beta - will test silent push behaviour

Manos

So does this mean that iOS 11.1 GM won’t fix the issue? :( – Nowak

Thats good to hear, when can we actually expect the official release of iOS11.1 ? – Phthisis

Keep us posted, can't currently install my app as there is no Xcode for 11.2 available. (and I removed the app from my device) – Monseigneur

Answer 7

I had similar issue with my app, till iOS 10 I was getting push notifications and application:didReceiveRemoteNotification:fetchCompletionHandler were getting called correctly.But when updated to iOS 11 push notifications stopped working.

Issue with my code was , even though i was using content-available:1 and mutable-content:1 in push notification payload,the Background Fetch option was not turned on. But It was working perfectly till iOS 10.

After Turning Background Fetch capability ON it is working Now

Shackelford

no it doesn't work for iOS11 - just terminate your app one time, then it stops waking up your app. just read the answers and comments in this topic – Phthisis

For terminated app , any push notifications (sielent or general push) wont fire delegate method in app delegate. thats the default behaviour. There no special case for iOS 11.0. – Shackelford

This doesn't make any difference for me. – Vulcanite

Answer 8

iOS 11.4.1, Swift 4

I was having issues with silent pushes not arriving (from CloudKit) and I tried everything everyone has mentioned here. Then I decided to try setting a blank alertBody to my CKNotificationInfo() objects like this:

let info = CKNotificationInfo()
info.shouldSendContentAvailable = true
info.alertBody = ""

This made the pushes get sent at a higher priority (but they were still silent pushes) and I no longer got the error in my device logs that the push was being ignored.

I hope that helps someone. :)

Abscind

Works for me with CloudKit as well. Without the alertBody, you would need to plug in the device to get remoteNotifications. Very odd behavior... – Chartreuse

Answer 9

So this is indeed a bug in iOS 11 and it's now fixed in iOS 11 beta 3. The application:didReceiveRemoteNotification:fetchCompletionHandler is now called correctly when a silent push is received both in foreground or in background.

UPDATE

No it is not fixed and is still happening in iOS beta 3 and 4

Conjectural

Actually it is not :( It's still happening in iOS 11 beta 3 – Conjectural

Yep, I'm also getting this issue in iOS 11 beta 3 – Kristynkrock

Apple reopened the bug report as well. I'll let you know – Conjectural

iOS 11 beta 4 is out but this is still happening. Can you check if this bug still affects you, too? What is the status of the bug report from Radar? – Kristynkrock

Background silent pushes are also not working for me on iOS 11 beta 4, despite working fine on iOS 10. That delegate callback isn't even getting called. – Stingaree

in which state is your application when you send the silent push? – Conjectural

Still not working on iOS 11 beta 4 for me, neither in foreground or background. – Nodal

Actually also not for me in beta 4 :/ No delegates called at all for silent pushes. I also tried using the UserNotifications framework but nothing happens as well – Conjectural

I'm not receiving silent pushes in iOS 11 beta 4. More concerning, if the app isn't in the foreground then they sometimes appear as regular notifications. Definitely something up! – Arbuckle

@jan Is the bug report still open? Could it be that iOS 11 will not support Silent Push? – Newfeld

@Newfeld yes still open. I can't believe that Apple would remove silent notifications without telling us so. – Conjectural

So I've just installed iOS 11 beta 5 and it looks better and the silent notifications are delivered when the app is in foreground or background via the didReceiveRemoteNotification delegate for a while then it stopped working again no matter what I do :/ Do you have the same behaviour? – Conjectural

I also noticed that short after restarting the device, the notifications are delivered but then everything stops working again ... – Conjectural

@Conjectural How often do you send remote notification? I can try to test it with the same condition. – Newfeld

that would be cool if you test as well as this is giving me a headache. The silent pushes do or don't work randomly after restarting the device. I updated my original post with a sample project so that we all use the same – Conjectural

@Conjectural I have tested your sample project shared in the description and the delivery is indeed inconsistent. I added a logger to write logs into a file, but as far as I see, there is no sign of delivery while the app is in the background. I will test it further. – Newfeld

Thanks for letting me know! I use os_log now and the macOS console where you can see that the push is correctly delivered to the device but not to the app (I updated my initial post as well as the sample project) – Conjectural

hi, @Conjectural is your issue resolved in the latest beta release? – Corinecorinna

Tried my own project with iOS 11 beta 9, and it still seems not working well. It gave me the following suspicious error message but I don't really know if it is related or not. <Error>: Ignoring notification with no alert, sound or badge <Notice>: Not saving push notification D763-E4CF to store [ error=Error Domain=UNErrorDomain Code=1401 “Notification has no user-facing content” UserInfo={NSLocalizedDescription=Notification has no user-facing content} ] – Gridley

@Gridley where do you see this message? In Xcode console or in the macOS console? Do you have the "Remote Notification" enabled in the "Background Modes" in the app's capabilities? – Conjectural

In Xcode console, and yes I did have "Remote notifications" enabled in capabilities tab. – Gridley

If the error message I posted above is really what happens when the silent push is sent, then the behavior I've met might be somewhat different from what @Conjectural had experienced. Judging from the message in my case, it seems the notification was received but then discarded by the os. – Gridley

same problem with Beta 9 – Armin

it looks like it's still not fixed in beta 10 :/ I'll do more testing and will confirm by updating the original post. – Conjectural

@Conjectural Same issue i am facing after updating OS to 11.4.1 version. Have you resolved this issue ? – Lodestar

Answer 10

As a workaround We're adding a "notification" key and inside a "title" with empty string as a value. This is wake up the didReceive callback in the appDelegate.

Rubrician

This seemed to work for me as well as a workaround to get DuetActivitySchedulerDaemon to allow the notification to wake up the app, until apple fixes the bug. – Bellay

When pushing a JSON containing an empty title, I still get the message on the console "Ignoring notification with no alert, sound or badge..." { "aps":{ "alert":{ "title":" " }, "content-available":"1" }, "gcm.message_id":"0...bb" } Is this JSON structure working for you? – Nowak

shouldn't you send the 1 (value for content available) without quotes? – Rubrician

That’s how Google Firebase formats the Json (“1”) and it always worked. Just iOS 11 with the dasd nonsense is creating an issue. Could you please post an example of a Json that is working for you? – Nowak

So what I am observing on iOS 11.1 is that silent pushes are not delivered if the device is running on the battery (not charging) and battery level is less than 20%, even when low energy mode is NOT activated. This is bad. Silent pushes on iOS 11 are not reliable at all, almost useless. – Nowak

@Rubrician Doesn't the notification appear by adding title (even though its empty)? Does this hack make it behave as silent notification? – Cordalia

my aps looks like: AnyHashable("aps"): { alert = { title = silence; }; "content-available" = 1; sound = ""; } This did not work as wake up even if I am adding the title. – Cordalia

@Rubrician Tested by adding "notification" key with empty "title" also, still not working. I am testing in ios 11.4 – Cordalia

Answer 11

As of writing this answer I am facing the exact same issue as Bill Dunay's answer.

My requirement was to receive silent notifications when the app is in foreground and nothing when the app is in the background/not running. And my workaround was this. I do not use badges hence setting it to zero is not an issue for me.

{
    "aps" : {
        "badge" : 0,
        "sound" : ""
    },
    "mydata": {  
        "foo": "bar"  
    }  
}

Please note I am deliberately not using "content-available". Setting that causes the iOS optimization logic to kick in delaying/cancelling the delivery of the notification.

Haphtarah

Answer 12

I have been getting the same issue for some notifications (not necessarily silent).

After reviewing all the updates and answers I am able to add two updates that may help:

• I found that accessing UIApplication.shared.isRegisteredForRemoteNotifications method while receiving a notification causes the application to stall without reporting anything to Xcode. Check if you are running some code after you receive the notification that accesses the method. (isRegisteredForRemoteNotifications locking UI with semaphore_wait_trap).

  • I discovered that I had a push notification parsing error on the console due to the "title-loc-args" : [3333] not accepting 3333 literally but accepting it as a string "title-loc-args" : ["3333"]. This made my entire interface stall after I access the method above, only on iOS 11, it works on iOS 12.

• I also found out that, with the exact same code, it works without any issue on iOS 12.0 (16A5366a). But on iOS 11 it is happening.

Nylons

Answer 13

In my case silent notifications was used to update ui after job was done on server site so it was pain in ass to have non relevant content in app. Because our payload for silent notification contains even title and body I implement these methods to get working notifications in active / inactive app, not charging and with Background App Refresh turned off and even in Low Power state.

To get this working I add delegate and create extension with UNUserNotificationCenterDelegate protocol and willPresent notification (iOS 10+) method, that is triggered every time with correct payload. To not show notification when app is active just call completion with badge or sound. I ended up with something like this

    import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?

    // MARK: - Lifecycle
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        UNUserNotificationCenter.current().delegate = self
        return true
    }

    //this was only method to handle notifications before
    func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any],
                     fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
        //process silent notification
        completionHandler(UIBackgroundFetchResult.newData)
    }
}

extension AppDelegate : UNUserNotificationCenterDelegate {
    func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
        //proces notification when app is active with `notification.request.content.userInfo`
        if UIApplication.shared.applicationState == .active {
            completionHandler(.badge)
        }else {
            completionHandler(.alert)
        }
    }
}

And to get working these states when app is in background and silent notification don't call my methods I get notifications from notification center directly in applicationDidBecomeActive by:

UNUserNotificationCenter.current().getDeliveredNotifications { (notifications) in
            debugLog(message: "unprocessed notification count: \(notifications.count)")
            if notifications.count > 0 {
                notifications.forEach({ (notification) in
                    DispatchQueue.main.async {
                        //handle `notification.request.content.userInfo`
                    }
                })
            }
        }

Magog

Answer 14

In my case, "Background App Refresh" was turned off in iPhone settings. Because of this push notification was delivered to the device but not on the app. Turning Background App Refresh on receives the silent push in the app.

This may not be the actual answer for this question, just in case if anyone need to check.

Colossus