Ich habe festgestellt, dass unter iOS 11 Beta 2 die stillen Benachrichtigungen nicht an das gesendet werden application:didReceiveRemoteNotification:fetchCompletionHandler unabhängig vom Status der App (Hintergrund / Vordergrund) gesendet werden.

Ich habe die UIApplicationDelegeteMethode implementiert application:didReceiveRemoteNotification:fetchCompletionHandlerund sende den folgenden stillen Push

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

Die Delegate-Methode wird jedoch unter iOS 11 nicht aufgerufen.

Es funktioniert gut mit anderen Versionen von iOS und dem Dokumentationsabschnitt Konfigurieren einer stillen Benachrichtigung wird nicht erwähnt, dass etwas anderes getan werden sollte.

Ist das ein Fehler in iOS 11 oder habe ich etwas Neues in iOS 11 verpasst?

Bitte beachten Sie, dass ich nicht über das spreche oder es benutze UserNotification Framework für das Senden stiller Pushs nicht benötigt werden sollte.

Hier ist ein Beispielprojekt , das das Problem veranschaulicht (Sie müssen Ihre eigene Bundle-ID festlegen).

Wenn Sie das Beispielprojekt zu Mittag essen und eine der oben genannten Nutzdaten an die App senden, können Sie mithilfe der macOS-Konsole feststellen, ob der Push korrekt an das Gerät, jedoch nicht an die App gesendet wurde.

UPDATE 10.08

Es scheint, dass das Verhalten zufällig ist. Manchmal wird die Nutzlast nach dem Neustart des Geräts korrekt geliefert, funktioniert aber nach einer Weile nicht mehr.

Wie Sie auf dem folgenden Screenshot sehen können, wird der als 1 gekennzeichnete Push nur an das Gerät gesendet, und der Push 2 (nach dem Neustart des Geräts) wird auch an die App gesendet.

UPDATE 14.08 - iOS 11 Beta 6

Immer noch das gleiche Verhalten. Eine andere Sache, die funktionieren soll, aber nicht funktioniert, ist die folgende. Wenn das Schema der Anwendung auf "Warten auf den Start der ausführbaren Datei" eingestellt ist, soll ein stiller Push die App aktivieren und im Hintergrund starten.

UPDATE 21.08 - iOS 11 Beta 7

Immer noch das gleiche Verhalten und keine Updates von Apple im Fehlerbericht.

UPDATE 29.08 - iOS 11 Beta 8

Immer noch das gleiche Problem. Die Schritte zum Reproduzieren, die ich jetzt verwende, sind die folgenden:

• Wählen Sie im Xcode-Projektschema "Warten Sie, bis die ausführbare Datei gestartet wird".
• Fügen Sie einen Haltepunkt in das Feld ein didReceiveRemoteNotification: fetchCompletionHandler
• Starten Sie die App auf dem Gerät
• Senden Sie den obigen stillen Druck

Erwartet : Die App wird aus dem angehaltenen Zustand in den Hintergrund gebracht und didReceiveRemoteNotification: fetchCompletionHandleraufgerufen

Tatsächlich : nichts passiert

UPDATE 06.09 - iOS 11 Beta 10

Ich habe immer noch das gleiche Buggy-Verhalten. Das Ticket von Apple wurde mit folgender Antwort aktualisiert:

Apple Developer Relations 6. September 2017, 22:42 Uhr Engineering hat das folgende Feedback zu diesem Problem gegeben:

Wir konnten die Beispiel-App zum Laufen bringen und das Verhalten testen. Wir haben keine Probleme gesehen, als wir dies wie beschrieben getestet haben.

Es wird nicht garantiert, dass Pushs bei der App ankommen, wenn sie im Hintergrund ausgeführt wird. Die Protokolle hier zeigen, dass wir nicht glauben, dass die App zum Starten ausreichend verwendet wird.

Wir sehen, dass wir von Zeit zu Zeit Pushs liefern, wenn die Bedingungen gut sind.

Wir glauben, dass sich das richtig verhält.

Update 11.09

Mein Apple-Fehlerbericht wurde geschlossen und als Duplikat markiert, von 33278611dem noch offen ist

UPDATE 13.09 - iOS 11 GM

Dank der Kommentare von kam800 (siehe unten) habe ich weitere Tests durchgeführt und diese Beobachtungen gemacht:

In iOS 11 scheint es einen neuen Daemon zu geben dasd DuetActivitySchedulerDaemon, der den Daten-Push entweder vollständig verwirft oder die Daten-Push-Bereitstellung verzögert:

Lieferung verschoben

Konsolenprotokolle

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

Verschobene Lieferprobleme

• Wenn die Übermittlung des Daten-Push verschoben und die App gestartet wird, wird der Daten-Push nur zugestellt, wenn der Übermittlungstermin erreicht ist, der in Zukunft mehrere Minuten betragen kann. Dies macht den Zweck der Verwendung von Daten-Pushs zunichte, um den Inhalt der neuen App für den nächsten Start bereit zu halten. Ich zitiere hier noch einmal Apples Dokumentation:

"Stille Benachrichtigungen verbessern die Benutzererfahrung, indem sie Ihnen helfen, Ihre App auf dem neuesten Stand zu halten, auch wenn sie nicht ausgeführt wird."

• Wenn zwei Daten-Pushs an eine angehaltene App gesendet werden, werden sie von iOS 11 verschoben, anstatt die App direkt zu aktivieren. Wenn die Lieferzeit erreicht ist, wird nur der letzte Daten-Push geliefert! Die vorherigen Pushs gehen verloren und werden nicht über die Delegate-Methode übermittelt, was zu einem Datenverlust führt.

Lieferung storniert

Konsolenprotokolle

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

Stornierte Lieferprobleme

In diesem Fall geht der Daten-Push vollständig verloren und wird unter iOS 11 nie geliefert, während er unter iOS 10 korrekt geliefert wurde.

UPDATE 19.09 - iOS 11 GM

Ich habe auch festgestellt, dass in der Konsole die folgenden Protokolle angezeigt werden, wenn sich die Anwendung im Vordergrund befindet und die Benachrichtigung nicht an die App gesendet wird:

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

So heißt es in den Versionshinweisen von iOS 11.1 Beta 1

iOS 11.1 Beta 1 wurde gerade veröffentlicht und sie erwähnen: "Benachrichtigungen Behobene Probleme • Stille Push-Benachrichtigungen werden häufiger verarbeitet. (33278611)

Ich habe einige Tests durchgeführt und es scheint tatsächlich behoben zu sein:

Suspended State

Wenn ich die App in einem angehaltenen Modus starte und einen stillen Push sende, wird die App wieder in den Hintergrund gebracht und der didReceiveRemoteNotification:fetchCompletionHandlerDelegat wird angerufen.

Vordergrundzustand

Auf die gleiche Weise scheint der Delegat wie erwartet aufgerufen zu werden, wenn sich die Anwendung im Vordergrund befindet und ein stiller Push gesendet wird. Dies funktionierte in früheren iOS 11-Versionen zufällig nicht , daher werde ich dies nach weiteren Tests bestätigen.

Ich wollte nur meine 2 Cent hier hinzufügen, da ich ebenfalls von diesem Problem betroffen bin und festgestellt habe, dass Apple in diesem Problem mehrere Radargeräte geschlossen hat, die besagen, dass sie nicht reproduziert werden konnten. Eine interessante Sache, die ich gefunden habe, ist, dass die Pushs geliefert werden, wenn die App im Hintergrund ist, während sie an den Debugger angehängt ist.

Wenn ich den Debugger töte, den Stecker aus der Steckdose ziehe, die App starte und die stille Push-Nutzlast sende, wird die App NICHT geweckt. Im Konsolenprotokoll wird angezeigt, dass das System die Übermittlung der Nutzdaten an meine App abbricht.

Ich habe ein Radar mit einer kleinen Beispiel-App eingereicht, die das Problem reproduziert. Ich habe im Radar auch ausdrücklich darauf hingewiesen, dass die Person, die an meinem Ticket arbeitet, die an den Debugger angehängte App nicht ausführen darf, um das Problem zu reproduzieren. Hier ist der Link: https://bugreport.apple.com/web/?problemID=34461063

Hoffentlich werden dadurch einige Fortschritte in diesem Bereich erzielt.

Sieht aus wie ein neues Verhalten von iOS 11. iOS 11 Beta 10 enthält einige beschreibende Protokolle zu diesem Problem:

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

Es sieht so aus, als würde jeder stille Push an iOS gesendet, aber dasd daemon verwendet einige Richtlinien, um zu entscheiden, ob stiller Push an die App gesendet werden soll (z. B. Akkuladestand). Ich habe gestern Abend einen leisen Stoß erhalten, aber mein iPhone war zu diesem Zeitpunkt an das Ladegerät angeschlossen - wahrscheinlich war der BatteryLevelPolicy-Wert hoch genug, um diesen einen leisen Stoß zu empfangen.

Apple gibt keine offiziellen Informationen zu diesem iOS-seitigen Verhalten, es gibt nur Informationen zur serverseitigen Drosselung:

Stille Benachrichtigungen sind weder dazu gedacht, Ihre App im Hintergrund wach zu halten, noch für Updates mit hoher Priorität. APNs behandeln stille Benachrichtigungen als niedrige Priorität und können ihre Zustellung insgesamt drosseln, wenn die Gesamtzahl zu hoch wird. Die tatsächlichen Grenzwerte sind dynamisch und können sich je nach Bedingungen ändern. Versuchen Sie jedoch, nicht mehr als einige Benachrichtigungen pro Stunde zu senden.

Ich drücke die Daumen, sie haben dieses Verhalten geändert, weil das meine App reparieren würde :) Andererseits ist diese Änderung gut - eine von vielen Dingen, die den iPhone-Akku länger halten als Android-Telefone.

Zu den Beta-Versionshinweisen für iOS 11.1 gehören: Behobene Probleme Behebung Stille Push-Benachrichtigungen werden häufiger verarbeitet. (33278611)

iOS 11.1 Beta 2 enthält ebenfalls

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

in Versionshinweisen - wird es jetzt testen.

UPDATE - 11.10.2017 - iOS 11.1 Beta 2

Nachdem wir unsere App 2 Tage lang in "realen Szenarien" verwendet haben, scheint es eine echte Verbesserung in dieser Version von iOS zu geben. Ich fange vorsichtig an zu glauben, dass dies behoben ist.

Apple Developer Relations hat meinem Radar gerade einen Kommentar hinzugefügt:

Wir glauben, dass dieses Problem in der neuesten Beta-Version von iOS 11.2 behoben ist.

Bitte testen Sie mit der neuesten iOS Beta. Wenn Sie immer noch Probleme haben, aktualisieren Sie bitte Ihren Fehlerbericht mit relevanten Protokollen oder Informationen, die uns bei der Untersuchung helfen könnten.

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

Derzeit wird iOS 11.2 Beta installiert. Testet das stille Push-Verhalten

Ich hatte ein ähnliches Problem mit meiner App, bis iOS 10 bekam ich Push-Benachrichtigungen und application:didReceiveRemoteNotification:fetchCompletionHandler wurde korrekt aufgerufen. Aber als auf iOS 11 aktualisiert wurde, funktionierten Push-Benachrichtigungen nicht mehr.

Das Problem mit meinem Code war, dass die Option "Hintergrundabruf" nicht aktiviert war, obwohl ich in der Nutzlast für Push-Benachrichtigungen den verfügbaren Inhalt 1 und den veränderlichen Inhalt 1 verwendet habe. Aber es funktionierte perfekt bis iOS 10.

Nach dem Einschalten der Hintergrundabruffunktion funktioniert sie jetzt

iOS 11.4.1, Swift 4

Ich hatte Probleme mit stillen Pushs, die nicht eintrafen (von CloudKit), und ich habe alles versucht, was alle hier erwähnt haben. Dann habe ich beschlossen, alertBodymeine CKNotificationInfo()Objekte wie folgt leer zu lassen :

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

Dadurch wurden die Pushs mit einer höheren Priorität gesendet (es handelte sich jedoch immer noch um stille Pushs), und in meinen Geräteprotokollen wurde nicht mehr der Fehler angezeigt, dass der Push ignoriert wurde.

Ich hoffe das hilft jemandem. :) :)

Dies ist in der Tat ein Fehler in iOS 11 und jetzt in iOS 11 Beta 3 behoben application:didReceiveRemoteNotification:fetchCompletionHandler wird jetzt korrekt aufgerufen, wenn ein stiller Push sowohl im Vordergrund als auch im Hintergrund empfangen wird.

AKTUALISIEREN

Nein, es ist nicht behoben und findet immer noch in iOS Beta 3 und 4 statt

Um dieses Problem zu umgehen, fügen wir einen "Benachrichtigungs" -Schlüssel und einen "Titel" mit einer leeren Zeichenfolge als Wert hinzu. Dies ist das Aufwecken des didReceive-Rückrufs im appDelegate.

Zum Zeitpunkt des Schreibens dieser Antwort stehe ich genau vor dem gleichen Problem wie Bill Dunay Antwort von .

Meine Anforderung war, stille Benachrichtigungen zu erhalten, wenn sich die App im Vordergrund befindet, und nichts, wenn sich die App im Hintergrund befindet / nicht ausgeführt wird. Und meine Problemumgehung war dies. Ich benutze keine Abzeichen, daher ist es für mich kein Problem, sie auf Null zu setzen.

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

Bitte beachten Sie, dass ich absichtlich nicht "inhaltsverfügbar" verwende. Diese Einstellung bewirkt, dass die iOS-Optimierungslogik die Zustellung der Benachrichtigung verzögert / abbricht.

Ich habe das gleiche Problem für einige Benachrichtigungen erhalten (nicht unbedingt still).

Nachdem ich alle Updates und Antworten überprüft habe, kann ich zwei Updates hinzufügen, die helfen können:

• Ich habe festgestellt, dass die Zugriffsmethode UIApplication.shared.isRegisteredForRemoteNotificationsbeim Empfang einer Benachrichtigung dazu führt, dass die Anwendung blockiert, ohne dass Xcode etwas gemeldet wird. Überprüfen Sie, ob Sie Code ausführen, nachdem Sie die Benachrichtigung erhalten haben, die auf die Methode zugreift. ( isRegisteredForRemoteNotifications sperrt die Benutzeroberfläche mit semaphore_wait_trap ).

  • Ich habe festgestellt, dass auf der Konsole ein Fehler beim Parsen der Push-Benachrichtigung aufgetreten ist "title-loc-args" : [3333], da 3333 nicht wörtlich akzeptiert, sondern als Zeichenfolge akzeptiert wurde "title-loc-args" : ["3333"]. Dadurch wurde meine gesamte Benutzeroberfläche blockiert, nachdem ich auf die oben beschriebene Methode zugegriffen hatte. Nur unter iOS 11 funktioniert sie unter iOS 12.

• Ich fand auch heraus, dass es mit genau demselben Code unter iOS 12.0 (16A5366a) problemlos funktioniert . Aber unter iOS 11 passiert es.

In meinem Fall wurden stille Benachrichtigungen verwendet, um die Benutzeroberfläche zu aktualisieren, nachdem die Arbeit auf der Server-Site erledigt wurde. Es war also nervig, nicht relevante Inhalte in der App zu haben. Da unsere Nutzdaten für stille Benachrichtigungen sogar Titel und Text enthalten, implementiere ich diese Methoden, um funktionierende Benachrichtigungen in der aktiven / inaktiven App zu erhalten, ohne sie aufzuladen und bei deaktivierter Hintergrund-App-Aktualisierung und sogar im Energiesparmodus.

Damit dies funktioniert, füge ich einen Delegaten hinzu und erstelle eine Erweiterung mit UNUserNotificationCenterDelegateProtokoll und willPresent notification(iOS 10+) Methode, die jedes Mal mit der richtigen Nutzlast ausgelöst wird. Um keine Benachrichtigung anzuzeigen, wenn die App aktiv ist, rufen Sie einfach die Fertigstellung mit Abzeichen oder Sound an. Am Ende hatte ich so etwas

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

Und damit diese Zustände funktionieren, wenn sich die App im Hintergrund befindet und stille Benachrichtigungen meine Methoden nicht aufrufen, erhalte ich Benachrichtigungen vom Benachrichtigungscenter direkt applicationDidBecomeActivevon:

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

In meinem Fall wurde "Hintergrund-App-Aktualisierung" in den iPhone-Einstellungen deaktiviert. Aus diesem Grund wurde eine Push-Benachrichtigung an das Gerät gesendet, jedoch nicht an die App. Wenn Sie die Hintergrund-App-Aktualisierung aktivieren, wird der stille Push in der App empfangen.

Dies ist möglicherweise nicht die eigentliche Antwort auf diese Frage, nur für den Fall, dass jemand dies überprüfen muss.