Я помітив, що на 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, щоб переконатися, що натиск правильно подається на пристрій, а не в додаток.

ОНОВЛЕННЯ 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 Інженерія надала наступні відгуки щодо цього питання:

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

Натискання не гарантовано надходять до програми, коли він працює у фоновому режимі, а журнали тут вказують, що ми не віримо, що додаток використовується достатньо для його запуску.

Ми бачимо, що час від часу ми надаємо штовхання, коли умови хороші.

Ми вважаємо, що це поводиться правильно.

Оновлення 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 бета-версія 1 щойно випущена, і вони згадують: "Повідомлення вирішені проблеми • Тихі натискання сповіщень обробляються частіше. (33278611)

Я зробив кілька тестів і, здається, це справді виправлено:

Призупинена держава

Коли я запускаю програму в призупиненому режимі і надсилаю безшумний поштовх, програма повертається на другий план і didReceiveRemoteNotification:fetchCompletionHandlerвикликається делегат.

Держава переднього плану

Таким же чином, коли програма стоїть на передньому плані і надсилається безшумний поштовх, делегат, здається, називається так, як очікувалося. Це випадково не працювало в попередніх версіях 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, але Дэдд демон використовує декілька правил, щоб вирішити, чи потрібно тихому натисканні надходити в додаток (наприклад, рівень заряду акумулятора). Вчора ввечері мені вдалося отримати один безшумний натиск, але мій iPhone на той час був підключений до зарядного пристрою - ймовірно, оцінка BatteryLevelPolicy була достатньо високою, щоб отримати цей безшумний натиск.

Apple не надає офіційної інформації про таку поведінку на стороні iOS, є лише інформація про натискання на стороні сервера:

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

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

Примітки до випуску бета-версії iOS 11.1 включають: Повідомлення вирішені Проблеми Тихі сповіщення про натискання обробляються частіше. (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 щойно додали коментар до мого радара:

Ми вважаємо, що це питання вирішено в останній бета-версії iOS 11.2.

Перевірте тестування з останньою версією бета-версії iOS. Якщо у вас все ще виникають проблеми, оновіть звіт про помилку, будь-який відповідний журнал або інформацію, яка може допомогти нам розслідувати.

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

наразі бета-версія iOS 11.2 - перевірятиме мовчазне поводження

У мене була аналогічна проблема з моїм додатком, до iOS 10 я отримував push-сповіщення та application:didReceiveRemoteNotification:fetchCompletionHandlerотримував виклики правильно. Але, коли оновлено до iOS 11, push-сповіщення перестало працювати.

Проблема з моїм кодом полягала в тому, що я використовував доступний вміст: 1 і вміст, що змінюється: 1 у корисному навантаженні із наштовхнутим повідомленням опція "Вибір фону" не була включена. Але він працював ідеально до iOS 10.

Після ввімкнення здатності фонового вибору ввімкнено, він працює зараз

iOS 11.4.1, Swift 4

У мене виникли проблеми з тихими натисканнями, які не надходили (з CloudKit), і я спробував усе, про що тут говорилося. Тоді я вирішив спробувати встановити порожнє alertBodyдля моїх CKNotificationInfo()об’єктів, як це:

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

Це призвело до того, що натискання надсилалися з більш високим пріоритетом (але вони все ще були безшумними), і я більше не отримував помилки в журналах своїх пристроїв, що натискання ігнорувалося.

Я сподіваюся, що хтось допомагає. :)

Отже, це справді помилка в iOS 11, і тепер вона виправлена ​​в iOS 11 beta 3. The application:didReceiveRemoteNotification:fetchCompletionHandler тепер називається правильно, коли тихий натискання надходить як на передньому плані, так і на задньому плані.

ОНОВЛЕННЯ

Ні, це не виправлено і все ще відбувається в iOS beta 3 і 4

Як вирішення, ми додаємо ключ "сповіщення" і всередині "заголовок" з порожнім рядком як значення. Це викликає зворотний виклик didReceive в додаткуДелегат.

На момент написання цієї відповіді я зіткнувся з таким же питанням, як і у відповіді Білла Дуная .

Моя вимога полягала в тому, щоб отримувати безшумні сповіщення, коли додаток на передньому плані, і нічого, коли програма знаходиться у фоновому режимі / не працює. І моє вирішення було таким. Я не використовую значки, тому встановлення його в нуль не є проблемою для мене.

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

Зауважте, я навмисно не використовую "доступний вміст". Налаштування, що змушує логіку оптимізації iOS спричинити затримку / скасування доставки сповіщення.

Я отримую те саме питання для деяких сповіщень (не обов'язково беззвучних).

Переглянувши всі оновлення та відповіді, я можу додати два оновлення, які можуть допомогти:

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

  • Я виявив, що у мене була помилка розбору повідомлення про натиск на консолі через те, що він "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. Через це натискання повідомлення надійшло на пристрій, але не в додаток. Увімкнення фонового оновлення додатка отримує тихий натиск у додатку.

Це може бути не справжньою відповіддю на це питання, про всяк випадок, якщо комусь потрібно перевірити.