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

Solution 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.

Solution 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.

Solution 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.

Solution 4

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

Solution 5

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

View more solutions

Comments

[pds]

I see the same issue.

[hariszaman]

what is the payload you are sending?

[Jan]

@hariszaman the one that is in the origianl post

[hariszaman]

@Jan 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

[Jan]

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

[hariszaman]

@Jan 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

[Justin Stanley]

Still not fixed in Beta 8.......

[Jan]

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

[Thomas Einwaller]

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 )}'.

[Jan]

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

[Thomas Einwaller]

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

[Thomas Einwaller]

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

[Jan]

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.

[Thomas Einwaller]

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

[Dominik Bucher]

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

[xiangxin]

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. :(

[Jan]

@xiangxin 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"?

[Jan]

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

[xiangxin]

@Jan 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.

[Dominik Bucher]

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

[Jan]

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

[Jan]

@xiangxin 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)

[Dominik Bucher]

@Jan 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..

[Jan]

@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?

[Jan]

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

[Jan]

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"

[Thomas Einwaller]

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

[Jan]

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

[MagicFlow]

Having the exact same issues - @xiangxin 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?

[GoRoS]

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.

[Jan]

@GoRoS do you have the UIBackgroundModes set to remote-notification in your plist?

[GoRoS]

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

[xiangxin]

@MagicFlow 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.

[MagicFlow]

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

[DaNLtR]

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

[AlexWoe89]

I was testing this behavior also the last weeks with no success.... to my confusion, the application(:didReceiveRemoteNotification:fetchCompletionHan‌​dler:) 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

[AlexWoe89]

I opened a thread also in stackoverflow and answered my own question here: stackoverflow.com/questions/46330053/…

[Lee]

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

[AlexWoe89]

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

[JanApotheker]

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

[AlexWoe89]

@JanApotheker - no it's not fixed. just tested it

[Chinthaka]

@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>

[JanApotheker]

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?

[Lee]

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

[Lee]

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

[shadowmoses]

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.

[AlexWoe89]

@shadowmoses you should try 11.1 beta

[txulu]

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

[ilmetu]

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 ?

[toxaq]

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...

[Jan]

@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

[AlexWoe89]

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

[Jan]

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

[Gruntcakes]

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

[Gruntcakes]

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.

[Gruntcakes]

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.

[Gopik]

Seems, Still issue appear in iOS 11.2.6.

[US-1234]

i am facing same issue in 11.4.1 veriosn

[Hugo Allexis Cardona]

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

[malhal]

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.

[Dr TJ]

The answer in this post worked for me: stackoverflow.com/a/64690793/451383

[Jan]

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

[ov1d1u]

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

[Jan]

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

[ov1d1u]

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?

[Justin Stanley]

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.

[Jan]

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

[Yaman]

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

[Jan]

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

[Ben Dodson]

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!

[kanekin]

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

[Jan]

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

[Jan]

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?

[Jan]

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

[kanekin]

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

[Jan]

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

[kanekin]

@Jan 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.

[Jan]

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)

[PiyushRathi]

hi, @Jan is your issue resolved in the latest beta release?

[Azu]

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} ]

[Jan]

@Azu 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?

[Azu]

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

[Azu]

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 @Jan had experienced. Judging from the message in my case, it seems the notification was received but then discarded by the os.

[hariszaman]

same problem with Beta 9

[Jan]

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

[Jan]

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.

[kam800]

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).

[Jan]

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.

[Thomas Einwaller]

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}

[Jan]

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.

[Jan]

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

[kam800]

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

[kam800]

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.

[Jan]

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

[Thomas Einwaller]

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

[MagicFlow]

are there any updates on your bug reportwith apple @bill

[Abras]

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.

[Thomas Einwaller]

unbelievable :(

[Lee]

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

[Abras]

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.

[Jan]

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

[James L Harris]

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

[Abras]

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.

[Shankari]

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.

[Shankari]

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/…

[AlexWoe89]

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

[Jan]

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

[Bill Dunay]

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.

[AlexWoe89]

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?

[AlexWoe89]

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

[Thomas Einwaller]

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

[AndaluZ]

@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.

[Olecramoak]

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.

[Lee]

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

[Olecramoak]

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?

[AlexWoe89]

@Olecramoak for me iOS11.1 beta 4 is working like iOS 10.

[AlexWoe89]

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

[Sudeep george]

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.

[Olecramoak]

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? @AlexWoe89

[Gruntcakes]

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.

[Olecramoak]

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

[AlexWoe89]

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

[Rool Paap]

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)

[Joe Benton]

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.

[Olecramoak]

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?

[elkorb]

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

[Olecramoak]

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?

[Olecramoak]

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.

[Sujal]

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

[Sujal]

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.

[Sujal]

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

[Gopik]

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

[US-1234]

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

[powertoold]

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

[Yogendra Patel]

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

[malhal]

This doesn't make any difference for me.