Zauważyłem, że na iOS 11 beta 2 ciche powiadomienia nie są dostarczane application:didReceiveRemoteNotification:fetchCompletionHandlerniezależnie od stanu aplikacji (tło / pierwszy plan).

Zaimplementowałem UIApplicationDelegetemetodę application:didReceiveRemoteNotification:fetchCompletionHandleri wysyłam następujący cichy przycisk

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

ale metoda delegata nie jest wywoływana w systemie iOS 11.

Działa dobrze na innych wersjach iOS, a sekcja dokumentacji Konfigurowanie cichego powiadomienia nie wspomina, że ​​cokolwiek innego należy zrobić.

Czy to błąd w iOS 11, czy przegapiłem coś nowego w iOS 11?

Zwróć uwagę, że nie mówię o UserNotificationframeworku, który nie powinien być potrzebny do wysyłania cichych pchnięć ani nie używam go .

Oto przykładowy projekt, który ilustruje problem (musisz ustawić własny identyfikator pakietu)

Po uruchomieniu przykładowego projektu i wysłaniu powyższego ładunku do aplikacji możesz użyć konsoli macOS, aby sprawdzić, czy wypychanie jest poprawnie dostarczane do urządzenia, ale nie do aplikacji.

AKTUALIZACJA 10.08.2018

Wygląda na to, że zachowanie jest przypadkowe. Czasami po ponownym uruchomieniu urządzenia ładunek jest dostarczany poprawnie, ale po chwili przestaje działać.

Jak widać na poniższym zrzucie ekranu, push oznaczony jako 1 jest dostarczany tylko do urządzenia, a push 2 (po restarcie urządzenia) jest również dostarczany do aplikacji.

AKTUALIZACJA 14.08 - iOS 11 Beta 6

Wciąż to samo zachowanie. Kolejna rzecz, która powinna działać, ale nie działa, jest następująca. Gdy schemat aplikacji jest ustawiony na „Czekaj na uruchomienie pliku wykonywalnego”, ciche naciśnięcie powinno obudzić aplikację i uruchomić ją w tle.

AKTUALIZACJA 21.08 - iOS 11 Beta 7

Nadal to samo zachowanie, a nie aktualizacje od Apple w raporcie o błędzie.

AKTUALIZACJA 29.08 - iOS 11 Beta 8

Wciąż ten sam problem. Kroki do odtworzenia, których teraz używam, są następujące:

• W schemacie projektu Xcode wybierz „Czekaj na uruchomienie pliku wykonywalnego”
• Dodaj punkt przerwania w didReceiveRemoteNotification: fetchCompletionHandler
• Uruchom aplikację na urządzeniu
• Wyślij powyższe ciche pchnięcie

Oczekiwano : aplikacja jest przenoszona ze stanu zawieszenia do tła i didReceiveRemoteNotification: fetchCompletionHandlerjest wywoływana

Rzeczywiste : nic się nie dzieje

AKTUALIZACJA 06.09 - iOS 11 Beta 10

Nadal mam takie samo wadliwe zachowanie. Bilet od Apple został zaktualizowany następującą odpowiedzią:

Apple Developer Relations 6 września 2017, 22:42 Inżynierowie przekazali następującą opinię dotyczącą tego problemu:

Udało nam się uruchomić przykładową aplikację i przetestować zachowanie. Nie widzieliśmy żadnych problemów, gdy testowaliśmy to zgodnie z opisem.

Nie ma gwarancji, że wypychanie dotrze do aplikacji, gdy działa w tle, a dzienniki tutaj wskazują, że nie uważamy, że aplikacja jest używana wystarczająco, aby ją uruchomić.

Widzimy, jak od czasu do czasu dostarczamy pchnięcia, gdy warunki są dobre.

Uważamy, że działa to poprawnie.

Aktualizacja 11.09.2018

Mój raport o błędzie Apple został zamknięty i oznaczony jako duplikat, 33278611który pozostaje otwarty

AKTUALIZACJA 13.09 - iOS 11 GM

Dzięki komentarzom kam800 (patrz poniżej) przeprowadziłem więcej testów i doszedłem do następujących spostrzeżeń:

Wygląda na to, że w iOS 11 pojawił się nowy demon, dasd DuetActivitySchedulerDaemonktóry całkowicie odrzuca wypychanie danych lub opóźnia ich dostarczanie:

Dostawa odroczona

Dzienniki konsoli

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

Problemy z opóźnioną dostawą

• Gdy dostarczanie danych w trybie push zostanie odroczone i aplikacja zostanie uruchomiona, wypychanie danych jest dostarczane tylko wtedy, gdy zostanie osiągnięta data dostarczenia, która może nastąpić kilka minut w przyszłości. To całkowicie mija się z celem korzystania z wypychania danych w celu przygotowania zawartości nowej aplikacji do następnego uruchomienia. Cytuję tutaj jeszcze raz dokumentację Apple:

„Ciche powiadomienia poprawiają komfort użytkowania, pomagając w utrzymywaniu aktualności aplikacji, nawet gdy nie jest uruchomiona”.

• Gdy dwa wypychania danych są wysyłane do zawieszonej aplikacji, są one odkładane przez iOS 11 zamiast bezpośrednio budzić aplikację. Kiedy nadejdzie czas dostawy, dostarczane jest tylko ostatnie wypychanie danych! Poprzednie wypychania są tracone i nie są dostarczane za pośrednictwem metody delegata, co powoduje utratę danych.

Dostawa anulowana

Dzienniki konsoli

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

Problemy z anulowaną dostawą

W tym przypadku wypychanie danych jest całkowicie utracone i nigdy nie jest dostarczane na iOS 11, podczas gdy zostało poprawnie dostarczone na iOS 10.

AKTUALIZACJA 19.09 - iOS 11 GM

Zauważyłem też, że gdy aplikacja jest na pierwszym planie, a powiadomienie nie jest dostarczane do aplikacji, w konsoli widzę następujące logi:

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

Tak mówią informacje o wydaniu iOS 11.1 beta 1

iOS 11.1 beta 1 został właśnie wydany i wspominają: „Powiadomienia rozwiązane problemy • Ciche powiadomienia push są przetwarzane częściej. (33278611)

Zrobiłem kilka testów i wydaje się, że rzeczywiście zostało to naprawione:

Stan zawieszony

Kiedy uruchamiam aplikację w trybie zawieszonym i wysyłam cichy komunikat, aplikacja jest przywracana do tła i didReceiveRemoteNotification:fetchCompletionHandlerwywoływany jest delegat.

Stan pierwszoplanowy

W ten sam sposób, gdy aplikacja jest na pierwszym planie i jest wysyłane ciche wypychanie, delegat wydaje się być wywoływany zgodnie z oczekiwaniami. Losowo nie działało to w poprzednich wersjach iOS 11, więc potwierdzę to po dalszych testach.

Chciałem tylko dodać moje 2 centy, ponieważ również uderzył mnie ten problem i zauważyłem, że Apple zamknął kilka radarów w tej sprawie, mówiąc, że nie mogą się odtworzyć. Interesującą rzeczą, jaką znalazłem, jest to, że wypychania zostaną dostarczone, jeśli aplikacja będzie działać w tle, gdy jest podłączona do debugera.

Jeśli zabiję debugera, odłączę telefon, uruchomię aplikację i wyślę cichy ładunek push, widzę, że aplikacja NIE jest budzona. Widzę w dzienniku konsoli, że system anuluje dostarczanie ładunku do mojej aplikacji.

Przesłałem radar z małą przykładową aplikacją, która odtwarza problem. Wyraźnie zauważyłem również na radarze, że osoba pracująca nad moim biletem nie może uruchamiać aplikacji dołączonej do debugera, aby odtworzyć problem. Oto link: https://bugreport.apple.com/web/?problemID=34461063

Miejmy nadzieję, że spowoduje to pewien postęp w tej kwestii.

Wygląda na nowe zachowanie iOS 11. iOS 11 beta 10 zawiera kilka opisowych dzienników dotyczących tego problemu:

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

Wygląda na to, że każde ciche wypychanie jest dostarczane do iOS, ale demon dasd używa kilku zasad, aby zdecydować, czy ciche wypychanie powinno być dostarczane do aplikacji (np. Poziom naładowania baterii). Wczoraj wieczorem udało mi się otrzymać jedno ciche naciśnięcie, ale mój iPhone był wtedy podłączony do ładowarki - prawdopodobnie wynik BatteryLevelPolicy był wystarczająco wysoki, aby otrzymać to jedno ciche naciśnięcie.

Apple nie podaje oficjalnych informacji o tym zachowaniu po stronie iOS, są tylko informacje o ograniczaniu przepustowości po stronie serwera:

Ciche powiadomienia nie służą do utrzymywania aplikacji w stanie czuwania w tle ani nie są przeznaczone do aktualizacji o wysokim priorytecie. APN traktują ciche powiadomienia jako niski priorytet i mogą całkowicie ograniczyć ich dostarczanie, jeśli łączna liczba stanie się nadmierna. Rzeczywiste limity są dynamiczne i mogą się zmieniać w zależności od warunków, ale staraj się nie wysyłać więcej niż kilka powiadomień na godzinę.

Trzymam kciuki, że zmienili to zachowanie, bo to by naprawić moją aplikację :) Z drugiej strony ta zmiana jest dobra - jedna z wielu spraw, że bateria iPhone'a wytrzyma dłużej niż telefony z Androidem.

Informacje o wersji beta systemu iOS 11.1 obejmują: Powiadomienia Rozwiązane problemy Ciche powiadomienia push są przetwarzane częściej. (33278611)

iOS 11.1 Beta 2 zawiera również

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

w Uwagach do wydania - przetestuję teraz.

AKTUALIZACJA - 11.10.2017 - iOS 11.1 Beta 2

Po 2 dniach korzystania z naszej aplikacji w „rzeczywistych scenariuszach” wygląda na to, że w tej wersji iOS nastąpiła realna poprawa. Ostrożnie zaczynam wierzyć, że to zostało naprawione.

Apple Developer Relations właśnie dodał komentarz do mojego radaru:

Uważamy, że ten problem został rozwiązany w najnowszej wersji beta systemu iOS 11.2.

Przetestuj z najnowszą wersją beta systemu iOS. Jeśli nadal masz problemy, zaktualizuj swój raport o błędzie o odpowiednie dzienniki lub informacje, które mogą nam pomóc w zbadaniu sprawy.

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

obecnie instaluję iOS 11.2 beta - przetestuje zachowanie cichego wypychania

Miałem podobny problem z moją aplikacją, aż do iOS 10 otrzymywałem powiadomienia push i application:didReceiveRemoteNotification:fetchCompletionHandlerdzwoniłem poprawnie, ale po aktualizacji do iOS 11 powiadomienia push przestały działać.

Problem z moim kodem polegał na tym, że mimo że korzystałem z content-available: 1 i mutable-content: 1 w ładunku powiadomień wypychanych, opcja pobierania w tle nie została włączona. Ale działało idealnie do iOS 10.

Po włączeniu funkcji pobierania w tle działa teraz

iOS 11.4.1, Swift 4

Miałem problemy z nie docierającymi cichymi naciśnięciami (z CloudKit) i próbowałem wszystkiego, o czym wszyscy tutaj wspominali. Potem postanowiłem spróbować ustawić puste miejsce alertBodyna moich CKNotificationInfo()obiektach w następujący sposób:

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

To sprawiło, że wypychania były wysyłane z wyższym priorytetem (ale nadal były to ciche naciśnięcia) i nie otrzymałem już błędu w dziennikach mojego urządzenia, że ​​wypychanie było ignorowane.

Mam nadzieję, że to komuś pomoże. :)

Jest to więc rzeczywiście błąd w iOS 11 i został naprawiony w iOS 11 beta 3. application:didReceiveRemoteNotification:fetchCompletionHandlerTeraz jest wywoływany poprawnie, gdy ciche wypychanie jest odbierane zarówno na pierwszym planie, jak iw tle.

AKTUALIZACJA

Nie, nie zostało to naprawione i nadal dzieje się w iOS beta 3 i 4

Aby obejść ten problem, dodajemy klucz „powiadomienie” i wewnątrz „tytułu” z pustym ciągiem znaków jako wartością. To jest obudzenie wywołania zwrotnego didReceive w appDelegate.

Pisząc tę ​​odpowiedź, mam dokładnie ten sam problem, co odpowiedź Billa Dunaya .

Moim wymaganiem było otrzymywanie cichych powiadomień, gdy aplikacja jest na pierwszym planie i nic, gdy aplikacja jest w tle / nie działa. A moje obejście było takie. Nie używam odznak, więc ustawienie go na zero nie jest dla mnie problemem.

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

Należy pamiętać, że celowo nie używam opcji „dostępne treści”. Ustawienie, które powoduje, że logika optymalizacji iOS uruchamia opóźnianie / anulowanie dostarczenia powiadomienia.

Otrzymuję ten sam problem w przypadku niektórych powiadomień (niekoniecznie cichych).

Po przejrzeniu wszystkich aktualizacji i odpowiedzi mogę dodać dwie aktualizacje, które mogą pomóc:

• Odkryłem, że UIApplication.shared.isRegisteredForRemoteNotificationsmetoda dostępu podczas otrzymywania powiadomienia powoduje zawieszenie aplikacji bez zgłaszania czegokolwiek do Xcode. Sprawdź, czy uruchamiasz jakiś kod po otrzymaniu powiadomienia o dostępie do metody. ( isRegisteredForRemoteNotifications blokujący interfejs użytkownika z semaphore_wait_trap ).

  • Odkryłem, że wystąpił błąd analizowania powiadomień push na konsoli z powodu "title-loc-args" : [3333]braku akceptacji 3333 dosłownie, ale akceptowania go jako ciągu "title-loc-args" : ["3333"]. To spowodowało, że cały mój interfejs utknął po uzyskaniu dostępu do powyższej metody, tylko na iOS 11 działa na iOS 12.

• Dowiedziałem się również, że z dokładnie tym samym kodem działa bez problemu na iOS 12.0 (16A5366a) . Ale na iOS 11 to się dzieje.

W moim przypadku ciche powiadomienia zostały użyte do aktualizacji interfejsu użytkownika po wykonaniu zadania na serwerze, więc trudno było mieć nieistotne treści w aplikacji. Ponieważ nasz ładunek dla cichego powiadomienia zawiera nawet tytuł i treść, wdrażam te metody, aby otrzymywać działające powiadomienia w aktywnej / nieaktywnej aplikacji, bez ładowania i z wyłączonym odświeżaniem aplikacji w tle, a nawet w stanie niskiego zużycia energii.

Aby to działało, dodaję delegata i tworzę rozszerzenie z UNUserNotificationCenterDelegateprotokołem i willPresent notificationmetodą (iOS 10+), które jest uruchamiane za każdym razem z odpowiednim ładunkiem. Aby nie wyświetlać powiadomienia, gdy aplikacja jest aktywna, po prostu zadzwoń do zakończenia z odznaką lub dźwiękiem. Skończyło się na czymś takim

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

Aby uzyskać działanie tych stanów, gdy aplikacja jest w tle i ciche powiadomienia, nie wywołuj moich metod, otrzymuję powiadomienia z centrum powiadomień bezpośrednio applicationDidBecomeActiveprzez:

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

W moim przypadku „Odświeżanie aplikacji w tle” zostało wyłączone w ustawieniach iPhone'a. Z tego powodu powiadomienie push zostało dostarczone do urządzenia, ale nie do aplikacji. Włączenie odświeżania aplikacji w tle powoduje ciche naciśnięcie w aplikacji.

Może to nie być właściwa odpowiedź na to pytanie, na wypadek gdyby ktoś chciał to sprawdzić.