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

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

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

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

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

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

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

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

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

Я отправил радар с небольшим примером приложения, которое воспроизводит проблему. Я также явно отметил в радаре, что человек, работающий над моим билетом, не должен запускать приложение, прикрепленное к отладчику, чтобы воспроизвести проблему. Вот ссылка: 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

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

Apple Developer Relations только что добавили на мой радар комментарий:

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

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

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

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

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

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

После включения возможности фоновой выборки он работает.

iOS 11.4.1, Swift 4

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

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

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

Надеюсь, это кому-то поможет. :)

Так что это действительно ошибка в 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).

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

• Я также обнаружил, что с тем же кодом он работает без проблем на 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-уведомление было доставлено на устройство, но не в приложение. Включение фонового обновления приложения получает в приложении тихий толчок.

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