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

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

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ 10.08

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

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

ОБНОВЛЕНИЕ 14.08 - iOS 11 Beta 6

Все то же поведение. Еще одна вещь, которая должна работать, но не работает, заключается в следующем. Когда для схемы приложения установлено значение «Ожидание запуска исполняемого файла», предполагается, что тихое нажатие активирует приложение и запускает его в фоновом режиме.

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

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

ОБНОВЛЕНИЕ 29.08 - iOS 11 Beta 8

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

• В схеме проекта XCode выберите «Ожидание запуска исполняемого файла»
• Добавьте точку останова в didReceiveRemoteNotification: fetchCompletionHandler
• Запустите приложение на устройстве
• Отправить вышеуказанный тихий толчок

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

Актуально : ничего не происходит

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

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

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

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

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

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

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

Обновление 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

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

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

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

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

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

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

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

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

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

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

Надеемся, что это приведет к некоторому прогрессу в этом вопросе.

Похоже, новое поведение 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, есть только информация о регулировании на стороне сервера:

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

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

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

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

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

в заметках о выпуске - сейчас протестирую.

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

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

Apple Developer Relations просто добавила комментарий к моему радару:

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

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

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

в настоящее время устанавливается iOS 11.2 beta - будет тестировать поведение молча

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

Проблема с моим кодом была, хотя я использовал content-available: 1 и mutable-content: 1 в полезных данных push-уведомлений, опция Background Fetch не была включена. Но это работало отлично до iOS 10.

После включения возможности Background Fetch теперь она работает

iOS 11.4.1, Swift 4

У меня были проблемы с тихими толчками, не прибывающими (из CloudKit), и я попробовал все, что все упоминали здесь. Затем я решил попробовать установить пустые объекты alertBodyдля моих CKNotificationInfo()объектов следующим образом:

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

Это сделало отправку посылок с более высоким приоритетом (но они все еще были молчаливыми посылками), и я больше не получил ошибку в журналах своего устройства, что посылка игнорировалась.

Я надеюсь, что это помогает кому-то. :)

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

ОБНОВИТЬ

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

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

На момент написания этого ответа я столкнулся с той же проблемой, что и ответ Билла Дунай .

Мое требование состояло в том, чтобы получать тихие уведомления, когда приложение находится на переднем плане, и ничего, когда приложение находится в фоновом режиме / не работает. И мой обходной путь был этим. Я не использую значки, поэтому установка его на ноль не проблема для меня.

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

Обратите внимание, что я сознательно не использую "контент-доступный". Параметр, который заставляет логику оптимизации iOS активировать задержку / отмену доставки уведомления.

Я получаю ту же проблему для некоторых уведомлений (не обязательно молчать).

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

• Я обнаружил, что доступ к UIApplication.shared.isRegisteredForRemoteNotificationsметоду при получении уведомления приводит к остановке приложения, не сообщая ничего Xcode. Проверьте, выполняется ли какой-либо код после получения уведомления о доступе к методу. ( isRegisteredForRemoteNotifications, блокирующий пользовательский интерфейс с помощью semaphore_wait_trap ).

  • Я обнаружил, что у меня была ошибка синтаксического анализа push-уведомлений из-за того, что я "title-loc-args" : [3333]не принял 3333 буквально, а принял его как строку "title-loc-args" : ["3333"]. Это заставило весь мой интерфейс зависнуть после того, как я получил доступ к описанному выше методу, только на iOS 11, он работает на iOS 12.

• Я также узнал, что с точно таким же кодом он работает без проблем на iOS 12.0 (16A5366a) . Но на iOS 11 это происходит.

В моем случае тихие уведомления использовались для обновления пользовательского интерфейса после того, как работа была выполнена на сайте сервера, поэтому было неприятно иметь не релевантный контент в приложении. Поскольку наша полезная нагрузка для тихих уведомлений содержит даже заголовок и тело, я реализую эти методы для получения рабочих уведомлений в активном / неактивном приложении, не заряжаясь и с отключенным фоновым обновлением приложения и даже в состоянии низкого энергопотребления.

Чтобы это работало, я добавляю делегата и создаю расширение с UNUserNotificationCenterDelegateпротоколом и willPresent notification(iOS 10+) методом, который запускается каждый раз с правильной полезной нагрузкой. Чтобы не показывать уведомление, когда приложение активно, просто завершите звонок со значком или звуком. Я закончил с чем-то вроде этого

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

И чтобы заставить работать эти состояния, когда приложение работает в фоновом режиме, а уведомления без уведомления не вызывают мои методы, я получаю уведомления из центра уведомлений напрямую applicationDidBecomeActive:

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`
                    }
                })
            }
        }

В моем случае «Фоновое обновление приложения» было отключено в настройках iPhone. Из-за этого push-уведомление было доставлено на устройство, но не на приложение. Включение фонового обновления приложения получает тихий толчок в приложении.

Это не может быть реальным ответом на этот вопрос, на случай, если кому-то понадобится проверить.