Тихие нажатия не доставляются в приложение на iOS 11

Я заметил, что на iOS 11 beta 2 тихие уведомления не передаются в application:didReceiveRemoteNotification:fetchCompletionHandler независимо от состояния приложения (фон/передний план).

Я реализовал метод UIApplicationDelegete application:didReceiveRemoteNotification:fetchCompletionHandler, и я посылаю следующий тихий push

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

но метод делегата не вызывается в iOS 11.

Он отлично работает в других версиях iOS, а раздел документации "Настройка бесшумного уведомления" не упоминает, что что-то еще нужно сделать.

Является ли это ошибкой в iOS 11 или я пропустил что-то новое в iOS 11?

Обратите внимание, что я не говорю и не использую структуру UserNotification, которая не нужна для отправки тихих нажатий.

Вот пример пример проекта, который иллюстрирует проблему (вам нужно будет установить свой собственный идентификатор пакета)

Когда вы обедаете образец проекта и отправляете вышеприведенную полезную нагрузку в приложение, вы можете использовать консоль macOS, чтобы убедиться, что нажатие правильно доставлено на устройство, но не в приложение.

ОБНОВЛЕНИЕ 10.08

Похоже, что поведение случайное. Иногда после перезапуска устройства полезная нагрузка поставляется правильно, но через некоторое время она перестает работать.

Как вы можете видеть на следующем снимке экрана, push, помеченный как 1, отправляется только на устройство, а push 2 (после перезагрузки устройства) также доставляется в приложение.

ОБНОВЛЕНИЕ 14.08 - бета-версия iOS 11

По-прежнему такое же поведение. Другое дело, что должно работать, но не так. Когда для схемы приложения установлено значение "Ожидание запуска исполняемого файла", тихий push должен пробудить приложение и запустить его в фоновом режиме.

ОБНОВЛЕНИЕ 21.08 - iOS 11 Beta 7

По-прежнему такое же поведение, а не обновление от Apple в отчете об ошибке.

ОБНОВЛЕНИЕ 29.08 - бета-версия iOS 11

По-прежнему та же проблема. Ниже приведены шаги для воспроизведения, которые я использую:

В схеме проекта Xcode выберите "Подождите, пока исполняемый файл будет запущен"
Добавить точку останова в didReceiveRemoteNotification: fetchCompletionHandler
Запустите приложение на устройстве
Отправляйте отключенное нажатие кнопки

Ожидаемое: приложение переводится из приостановленного состояния в фоновое и didReceiveRemoteNotification: fetchCompletionHandler называется

Фактический: ничего не происходит

ОБНОВЛЕНИЕ 06.09 - iOS 11 Beta 10

У меня все еще такое же плохое поведение. Билет от Apple был обновлен следующим ответом:

Отношения с разработчиками Apple 6 сентября 2017, 10:42 предоставили следующую информацию по этой проблеме:

Нам удалось запустить приложение примера и проверить его поведение. Мы не видел никаких проблем, когда мы тестировали это, как описано.

Точки не гарантированно прибудут в приложение, когда оно запущено в фон и журналы здесь показывают, что мы не считаем, что приложение достаточно для его запуска.

Мы видим, что мы время от времени нажимаем на то, когда условия хорошо.

Мы считаем, что это ведет себя правильно.

Обновление 11.09

Мой отчет об ошибке Apple был закрыт и помечен как дубликат 33278611, который остается открытым

ОБНОВЛЕНИЕ 13.09 - iOS 11 GM

Благодаря комментариям kam800 (см. ниже) я сделал больше тестов и придумал эти наблюдения:

Кажется, в iOS 11 dasd DuetActivitySchedulerDaemon появился новый демон, который либо полностью отбрасывает передачу данных, либо задерживает доставку данных:

Отложенная доставка

Консольные журналы

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

Отложенные проблемы с доставкой

Когда перенос данных переносится и приложение запускается, то нажатие на данные доставляется только в том случае, если дата доставки будет достигнута, и это может быть несколько минут в будущем. Это полностью разрушает цель использования данных, чтобы поддерживать готовность нового приложения к следующему запуску. Я цитирую здесь еще раз документацию Apple:

"Тихие уведомления улучшают работу пользователей, помогая вам поддерживать ваше приложение обновлено, даже если оно не работает."

Когда двапередача данных отправляется в приостановленное приложение, которое переносится iOS 11 вместо того, чтобы просто просыпать приложение. Когда время доставки достигнуто, доставляется только последний нажатие данных! Предыдущие нажатия теряются и не передаются через метод делегата, что приводит к потере данных.

Отмена доставки

Консольные журналы

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

Отмененные проблемы с доставкой

Ну, в этом случае, толчок данных полностью потерян и никогда не был доставлен на iOS 11, пока он был правильно доставлен на iOS 10.

ОБНОВЛЕНИЕ 19.09 - iOS 11 GM

Я также заметил, что когда приложение находится на переднем плане и уведомление не доставляется в приложение, я вижу следующие журналы в консоли:

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

Ответ 1

Итак, заметки о выпуске iOS 11.1 beta 1 говорят

iOS 11.1 beta 1 был только что выпущен, и они упоминают: "Уведомление Решенные проблемы • Тихие push-уведомления обрабатываются чаще. (33278611)

Я сделал несколько тестов и, кажется, действительно исправлен:

Приостановленное состояние

Когда я запускаю приложение в режиме ожидания и отправляю тихий push, приложение возвращается на задний план и вызывается делегат didReceiveRemoteNotification:fetchCompletionHandler.

Состояние переднего плана

Таким же образом, когда приложение находится на переднем плане и отправляется тихий push, делегат, как представляется, вызывается как ожидалось. Это было случайным образом не работает в предыдущих версиях iOS 11, поэтому я подтвержу это после более тщательного тестирования.

Ответ 2

Просто хотел добавить мои 2 цента здесь, так как я тоже попал в эту проблему, и я заметил, что Apple закрыла несколько радаров по этому вопросу, говоря, что они не могут воспроизвести. Интересная вещь, которую я обнаружил, заключается в том, что нажатие будет доставлено, если приложение будет зашифровано, пока оно будет прикреплено к отладчику.

Если я убью отладчик, отключите телефон, запустите приложение и отправьте полезную нагрузку молчания, я вижу, что приложение НЕ проснулось. Я вижу в журнале консоли, что система отменяет доставку полезной нагрузки в мое приложение.

Я представил радар с небольшим образцовым приложением, которое воспроизводит проблему. Я также прямо заметил в радаре, что человек, работающий над моим билетом, не должен запускать приложение, прикрепленное к отладчику, для воспроизведения проблемы. Здесь ссылка: https://bugreport.apple.com/web/?problemID=34461063

Надеюсь, это приведет к определенному прогрессу в этой проблеме.

Ответ 3

Похоже на новое поведение 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

Похоже, что каждый тихий толчок доставляется в iOS, но демон dasd использует пару политик, чтобы решить, следует ли доставлять приложение без звука (например, уровень заряда батареи). Вчера вечером мне удалось получить один тихий толчок, но мой iPhone был подключен к зарядному устройству в то время - вероятно, оценка BatteryLevelPolicy была достаточно высокой, чтобы получить этот один тихий толчок.

Apple не дает официальной информации об этом поведении со стороны iOS, есть только информация о дросселировании на стороне сервера:

Тихие уведомления не предназначены для того, чтобы ваше приложение пробудилось в фон, и они не предназначены для высокоприоритетных обновлений. APNs рассматривает тихие уведомления как низкий приоритет и может если общее количество становится чрезмерным. Настоящий лимиты являются динамичными и могут меняться в зависимости от условий, но не пытайтесь отправлять несколько уведомлений в час.

Я скрестил пальцы, они изменили это поведение, потому что это исправило мое приложение:) С другой стороны, это изменение хорошо - одна из многих вещей, делающая iPhone-аккумулятор длительным дольше, чем Android-телефоны.

Ответ 4

Примечания к выпуску бета-версии iOS 11.1 включают: Уведомления Решенные проблемы Тихие push-уведомления обрабатываются чаще. (33278611)

Ответ 5

Отношения разработчиков Apple просто добавили комментарий к моему радару:

Мы полагаем, что эта проблема решена в последней бета-версии iOS 11.2.

Проконсультируйтесь с последней бета-версией iOS. Если у вас все еще есть проблемы, пожалуйста, обновите отчет об ошибках с помощью любых соответствующих журналов или информации, которая может помочь нам расследовать.

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

в настоящее время устанавливающая бета-версию iOS 11.2 - проверит бесшумное поведение push

Ответ 6

iOS 11.1 Beta 2 также содержит

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

в примечаниях к выпуску - проверит его сейчас.

ОБНОВЛЕНИЕ - 11.10.2017 - iOS 11.1 Beta 2

После использования нашего приложения в течение 2 дней в "сценариях реального мира" похоже, что в этой версии iOS наблюдается реальное улучшение. Я с осторожностью начинаю полагать, что это исправлено.

Ответ 7

В качестве обходного пути Мы добавляем ключ уведомления и внутри "title" с пустой строкой в качестве значения. Это пробуждает обратный вызов didReceive в appDelegate.

Ответ 8

Итак, это действительно ошибка в iOS 11, и теперь она исправлена в iOS 11 beta 3. Теперь application:didReceiveRemoteNotification:fetchCompletionHandler вызывается правильно, когда тихий push получен как на переднем плане, так и в фоновом режиме.

UPDATE

Нет, это не исправлено и все еще происходит в бета-версиях iOS 3 и 4

Ответ 9

У меня была аналогичная проблема с моим приложением, пока iOS 10 не получал push-уведомления, а application:didReceiveRemoteNotification:fetchCompletionHandler получал правильное имя. Но когда обновление до iOS 11 push-уведомлений перестало работать.

Проблема с моим кодом была, хотя я использовал контент-доступный: 1 и измененный контент: 1 в полезной нагрузке push-уведомления, опция Фоновая выборка не была включена. Но он отлично работал до IOS 10.

После включения функции фоновой выборки он работает Теперь