静默推送未传送到 iOS 11 上的应用程序

Silent pushes not delivered to the app on iOS 11

提问by Jan

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

我注意到在 iOS 11 beta 2 上，application:didReceiveRemoteNotification:fetchCompletionHandler无论应用程序的状态如何（后台/前台），无提示通知都不会发送到应用程序。

I implemented the UIApplicationDelegetemethod application:didReceiveRemoteNotification:fetchCompletionHandlerand I send the following silent push

我实现了该UIApplicationDelegete方法application:didReceiveRemoteNotification:fetchCompletionHandler并发送了以下静默推送

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

but the delegate method is not called on iOS 11.

但是在 iOS 11 上没有调用委托方法。

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

它在其他版本的 iOS 上运行良好，文档部分配置静默通知没有提到应该做任何其他事情。

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

这是 iOS 11 中的错误还是我错过了 iOS 11 中的新功能？

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

请注意，我不是在谈论或使用UserNotification发送静默推送不需要的框架。

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

这是一个说明问题的示例项目（您必须设置自己的包 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.

当您完成示例项目并将上述有效负载发送到应用程序时，您可以使用 macOS 控制台查看推送是否正确发送到设备而不是应用程序。

UPDATE 10.08

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

正如您在以下屏幕截图中看到的，标记为 1 的推送仅传送到设备，推送 2（设备重启后）也传送到应用程序。

UPDATE 14.08 - iOS 11 Beta 6

更新 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

更新 21.08 - iOS 11 Beta 7

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

仍然是相同的行为，而不是错误报告中来自 Apple 的更新。

UPDATE 29.08 - iOS 11 Beta 8

更新 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

• 在Xcode项目方案中，选择“等待可执行文件启动”
• 在程序中添加断点 didReceiveRemoteNotification: fetchCompletionHandler
• 在设备上启动应用程序
• 发送上面的无声推送

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

预期：应用程序从挂起状态进入后台并被didReceiveRemoteNotification: fetchCompletionHandler调用

Actual: nothing happens

实际：没有任何反应

UPDATE 06.09 - iOS 11 Beta 10

更新 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 的票已更新为以下答案：

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.

Apple 开发者关系 2017 年 9 月 6 日晚上 10:42 工程已提供有关此问题的以下反馈：

我们能够运行示例应用程序并测试其行为。当我们按照描述进行测试时，我们没有发现任何问题。

当应用程序在后台运行时，不能保证推送到达应用程序，这里的日志表明我们认为应用程序的使用量不足以启动它。

我们确实看到我们在条件良好时不时提供推送。

我们相信这是正确的行为。

Update 11.09

11.09 更新

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

我的 Apple 错误报告已关闭并标记为重复，33278611但仍处于打开状态

UPDATE 13.09 - iOS 11 GM

更新 13.09 - iOS 11 GM

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

感谢 kam800 的评论（见下文），我做了更多的测试并得出了这些观察结果：

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

iOS 11dasd DuetActivitySchedulerDaemon中似乎有一个新的守护进程，它要么完全丢弃数据推送，要么延迟数据推送交付：

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 minutesin 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:

• 当数据推送延迟并启动应用程序时，只有在到达交付日期时才会交付数据推送，可能是未来几分钟。这完全违背了使用数据推送来保持新应用程序的内容为下一次发布做好准备的目的。我在这里再次引用 Apple 的文档：

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

“静默通知可帮助您保持应用程序的最新状态，即使它未运行，也能改善用户体验。”

• When twodata 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 lastdata push is delivered! The previous pushes are lost and not delivered via the delegate method resulting in a data loss.

• 当两次数据推送被发送到暂停的应用程序时，它们会被 iOS 11 推迟，而不是直接唤醒应用程序。当到达交付时间时，只交付最后一次数据推送！之前的推送会丢失并且不会通过委托方法传递，从而导致数据丢失。

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.

那么在这种情况下，数据推送完全丢失并且从未在 iOS 11 上交付，而在 iOS 10 上正确交付。

UPDATE 19.09 - iOS 11 GM

更新 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

回答by Jan

So the release notes of iOS 11.1 beta 1 say

所以iOS 11.1 beta 1的发行说明说

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

iOS 11.1 beta 1 刚刚发布，他们提到：“通知已解​​决问题？静默推送通知的处理频率更高。(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:fetchCompletionHandlerdelegate is called.

当我以挂起模式启动应用程序并发送静默推送时，应用程序将返回后台并didReceiveRemoteNotification:fetchCompletionHandler调用委托。

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 notworking in previous iOS 11 versions so I will confirm this after more testing.

同样，当应用程序在前台并发送静默推送时，委托似乎按预期调用。这是随机没有在以前的iOS版本11工作，所以更多的测试后，我会证实这一点。

回答by Bill Dunay

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.

只是想在这里添加我的 2 美分，因为我也遇到了这个问题，我注意到 Apple 已经关闭了几个关于这个问题的雷达，说他们无法重现。我发现一个有趣的事情是，如果应用程序在连接到调试器时处于后台，则推送将被交付。

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

我已经提交了一个带有重现问题的小示例应用程序的雷达。我还在雷达中明确指出，处理我的工单的人不得运行附加到调试器的应用程序来重现问题。这是链接：https: //bugreport.apple.com/web/?problemID=34461063

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

希望这将导致在这个问题上取得一些进展。

回答by kam800

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

看起来像是 iOS 11 的新行为。iOS 11 beta 10 提供了一些关于此问题的描述性日志：

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.

看起来每个静默推送都传递给 iOS，但 dasd 守护进程使用几个策略来决定是否应将静默推送传递给应用程序（例如电池电量）。昨天晚上我设法收到了一次无声推送，但当时我的 iPhone 已连接到充电器 - 可能 BatteryLevelPolicy 得分足够高，可以收到一次无声推送。

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

Apple 没有提供有关此 iOS 端行为的官方信息，只有有关服务器端节流的信息：

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.

静默通知并不是为了让您的应用程序在后台保持唤醒状态，也不是为了高优先级更新。APNs 将静默通知视为低优先级，如果总数过多，可能会完全限制它们的传递。实际限制是动态的，可以根据条件改变，但尽量不要每小时发送超过几个通知。

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.

我一直祈祷他们改变了这种行为，因为那会修复我的应用程序 :) 另一方面，这种改变是好的——这是使 iPhone 电池续航时间比 Android 手机更长的众多因素之一。

回答by Andrew Gould

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

iOS 11.1 测试版发行说明包括： 通知解决的问题 更频繁地处理静默推送通知。(33278611)

回答by Thomas Einwaller

iOS 11.1 Beta 2 also contains

iOS 11.1 Beta 2 还包含

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

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

在“真实世界场景”中使用我们的应用程序 2 天后，这个版本的 iOS 似乎有了真正的改进。我开始谨慎地相信这是固定的。

回答by Thomas Einwaller

Apple Developer Relations just added a comment to my radar:

Apple Developer Relations 刚刚在我的雷达中添加了一条评论：

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/

我们相信此问题已在最新的 iOS 11.2 测试版中得到解决。

请使用最新的 iOS 测试版进行测试。如果您仍有问题，请使用任何可以帮助我们调查的相关日志或信息更新您的错误报告。

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

currently installing iOS 11.2 beta - will test silent push behaviour

当前正在安装 iOS 11.2 beta - 将测试静默推送行为

回答by Sudeep george

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

我的应用程序有类似的问题，直到 iOS 10 我收到推送通知并被application:didReceiveRemoteNotification:fetchCompletionHandler正确调用。但是当更新到 iOS 11 推送通知停止工作。

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.

我的代码的问题是，即使我在推送通知负载中使用了 content-available:1 和 mutable-content:1，后台提取选项也没有打开。但它在 iOS 10 之前一直运行良好。

After Turning Background Fetch capability ON it is working Now

打开后台获取功能后，它现在可以工作了

回答by Clifton Labrum

iOS 11.4.1, Swift 4

iOS 11.4.1，斯威夫特 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 alertBodyto my CKNotificationInfo()objects like this:

我遇到了无声推送（来自 CloudKit）的问题，我尝试了每个人在这里提到的所有内容。然后我决定尝试alertBody为我的CKNotificationInfo()对象设置一个空白，如下所示：

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

我希望能帮助某人。:)

回答by elkorb

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.

作为一种解决方法，我们添加了一个“通知”键，并在一个“标题”中添加了一个空字符串作为值。这是唤醒 appDelegate 中的 didReceive 回调。

回答by Jan

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

所以这确实是 iOS 11 中的一个错误，现在在 iOS 11 beta 3 中得到修复。application:didReceiveRemoteNotification:fetchCompletionHandler现在在前台或后台收到静默推送时会正确调用。

UPDATE

更新

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

不，它不是固定的，并且仍在 iOS beta 3 和 4 中发生