Ho notato che su iOS 11 beta 2, le notifiche silenziose non vengono recapitate application:didReceiveRemoteNotification:fetchCompletionHandlerindipendentemente dallo stato dell'app (sfondo / primo piano).

Ho implementato il UIApplicationDelegetemetodo application:didReceiveRemoteNotification:fetchCompletionHandlere invio la seguente push silenziosa

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

ma il metodo delegato non viene chiamato su iOS 11.

Funziona bene su altre versioni di iOS e la sezione della documentazione Configurare una notifica silenziosa non menziona che altro dovrebbe essere fatto.

È un bug in iOS 11 o ho perso qualcosa di nuovo in iOS 11?

Si noti che non sto parlando o utilizzando il UserNotificationframework che non dovrebbe essere necessario per inviare push silenziose.

Ecco un progetto di esempio che illustra il problema (dovrai impostare il tuo ID bundle)

Quando pranzi il progetto di esempio e invii un payload sopra all'app, puoi usare la console macOS per vedere che il push è correttamente consegnato al dispositivo ma non all'app.

AGGIORNAMENTO 10.08

Sembra che il comportamento sia casuale. A volte dopo il riavvio del dispositivo, il payload viene consegnato correttamente ma dopo un po 'smette di funzionare.

Come puoi vedere nello screenshot seguente, il push contrassegnato come 1 viene trasferito solo al dispositivo e anche il push 2 (dopo il riavvio del dispositivo) viene consegnato all'app.

AGGIORNAMENTO 14.08 - iOS 11 Beta 6

Sempre lo stesso comportamento. Un'altra cosa che dovrebbe funzionare ma non è la seguente. Quando lo schema dell'applicazione è impostato su "Attendi l'avvio dell'eseguibile", si suppone che un push silenzioso riattivi l'app e la avvii in background.

AGGIORNAMENTO 21.08 - iOS 11 Beta 7

Sempre lo stesso comportamento e non aggiornamenti da Apple nella segnalazione di bug.

AGGIORNAMENTO 29.08 - iOS 11 Beta 8

Sempre lo stesso problema. I passaggi per riprodurre che utilizzo ora sono i seguenti:

• Nello schema del progetto Xcode, selezionare "Attendi l'avvio dell'eseguibile"
• Aggiungi un punto di interruzione in didReceiveRemoteNotification: fetchCompletionHandler
• Avvia l'app sul dispositivo
• Invia la spinta silenziosa sopra

Previsto : l'app viene portata dallo stato sospeso allo sfondo e didReceiveRemoteNotification: fetchCompletionHandlerviene chiamata

In realtà : non succede nulla

AGGIORNAMENTO 06.09 - iOS 11 Beta 10

Sto ancora avendo lo stesso comportamento buggy. Il biglietto di Apple è stato aggiornato con la seguente risposta:

Apple Developer Relations, 6 settembre 2017, 22:42 Engineering ha fornito il seguente feedback su questo problema:

Siamo riusciti a far funzionare l'app di esempio e testare il comportamento. Non abbiamo riscontrato alcun problema quando lo abbiamo testato come descritto.

Non è garantito che le push arrivino all'app quando è in esecuzione in background e i registri qui indicano che non crediamo che l'app sia stata utilizzata abbastanza per avviarla.

Ci vediamo fornire periodicamente spinte quando le condizioni sono buone.

Crediamo che questo si stia comportando correttamente.

Aggiornamento 11.09

La mia segnalazione di bug Apple è stata chiusa e contrassegnata come duplicata, di 33278611cui rimane aperta

AGGIORNAMENTO 13.09 - iOS 11 GM

Grazie ai commenti di kam800 (vedi sotto) ho fatto più test e ho avuto quelle osservazioni:

Sembra che ci sia un nuovo demone in iOS 11 dasd DuetActivitySchedulerDaemonche scarta completamente il push dei dati o ritarda la consegna del push dei dati:

Consegna posticipata

Registri della console

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

Problemi di consegna posticipati

• Quando la consegna del push di dati viene posticipata e l'app viene avviata, il push di dati viene consegnato solo quando viene raggiunta la data di consegna, che può essere diversi minuti in futuro. Ciò vanifica completamente lo scopo dell'utilizzo dei push di dati per mantenere i contenuti della nuova app pronti per il prossimo lancio. Cito di nuovo qui la documentazione di Apple:

"Le notifiche silenziose migliorano l'esperienza dell'utente aiutandoti a mantenere aggiornata l'app, anche quando non è in esecuzione."

• Quando due push di dati vengono inviati a un'app sospesa, vengono posticipati da iOS 11 invece di riattivare l'app direttamente. Quando viene raggiunto il tempo di consegna, viene consegnato solo l'ultimo push di dati! I push precedenti vengono persi e non vengono consegnati tramite il metodo delegato con conseguente perdita di dati.

Consegna annullata

Registri della console

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

Problemi di consegna annullati

Bene, in questo caso, il push dei dati è completamente perso e mai consegnato su iOS 11 mentre è stato consegnato correttamente su iOS 10.

AGGIORNAMENTO 19.09 - iOS 11 GM

Ho anche notato che quando l'applicazione è in primo piano e la notifica non viene recapitata all'app, vedo i seguenti registri nella console:

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

Quindi dicono le note di rilascio di iOS 11.1 beta 1

iOS 11.1 beta 1 è stato appena rilasciato e menzionano: "Notifiche risolte Problemi • Le notifiche push silenziose vengono elaborate più frequentemente. (33278611)

Ho fatto alcuni test e sembra che sia stato corretto:

Stato sospeso

Quando avvio l'app in modalità sospesa e invio un push silenzioso, l'app viene riportata in background e didReceiveRemoteNotification:fetchCompletionHandlerviene chiamato il delegato.

Stato in primo piano

Allo stesso modo, quando l'applicazione è in primo piano e viene inviato un push silenzioso, il delegato sembra essere chiamato come previsto. Questo non funzionava in modo casuale nelle precedenti versioni di iOS 11, quindi lo confermerò dopo ulteriori test.

Volevo solo aggiungere i miei 2 centesimi qui perché sono stato colpito anche da questo problema e ho notato che Apple ha chiuso diversi radar su questo problema dicendo che non potevano riprodursi. Una cosa interessante che ho scoperto è che i push verranno consegnati se l'app è in background mentre è collegata al debugger.

Se uccido il debugger, scollego il telefono, avvio l'app e invio il payload push silenzioso vedo che l'app NON viene svegliata. Nel registro della console vedo che il sistema annulla la consegna del payload alla mia app.

Ho inviato un radar con una piccola app di esempio che riproduce il problema. Ho anche notato esplicitamente nel radar che la persona che lavora sul mio ticket non deve eseguire l'app allegata al debugger per riprodurre il problema. Ecco il link: https://bugreport.apple.com/web/?problemID=34461063

Si spera che ciò comporti alcuni progressi su questo problema.

Sembra un nuovo comportamento di iOS 11. iOS 11 beta 10 fornisce alcuni registri descrittivi riguardanti questo problema:

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

Sembra che ogni push silenzioso sia consegnato a iOS, ma il demone dasd usa un paio di criteri per decidere se il push silenzioso debba essere consegnato all'app (ad esempio il livello della batteria). Sono riuscito a ricevere una spinta silenziosa ieri sera, ma il mio iPhone era collegato al caricabatterie in quel momento - probabilmente il punteggio BatteryLevelPolicy era abbastanza alto da ricevere quella spinta silenziosa.

Apple non fornisce informazioni ufficiali su questo comportamento lato iOS, ci sono solo informazioni sulla limitazione lato server:

Le notifiche silenziose non sono pensate come un modo per mantenere la tua app in background, né sono pensati per aggiornamenti ad alta priorità. Gli APN considerano le notifiche silenziose come a bassa priorità e possono limitare del tutto la loro consegna se il numero totale diventa eccessivo. I limiti effettivi sono dinamici e possono variare in base alle condizioni, ma cerca di non inviare più di alcune notifiche all'ora.

Tengo le dita incrociate e hanno cambiato quel comportamento, perché ciò avrebbe risolto la mia app :) D'altra parte, questo cambiamento è buono - una delle molte cose che rende la batteria dell'iPhone più lunga rispetto ai telefoni Android.

Le note sulla versione beta di iOS 11.1 includono: Notifiche risolte Problemi Le notifiche push silenziose vengono elaborate più frequentemente. (33278611)

iOS 11.1 Beta 2 contiene anche

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

nelle Note di rilascio - lo testerà ora.

AGGIORNAMENTO - 11.10.2017 - iOS 11.1 Beta 2

Dopo aver usato la nostra App per 2 giorni in "scenari del mondo reale" sembra che ci sia un vero miglioramento in questa versione di iOS. Comincio con cautela a credere che sia stato risolto.

Apple Developer Relations ha appena aggiunto un commento al mio radar:

Riteniamo che questo problema sia stato risolto nell'ultima versione beta di iOS 11.2.

Si prega di testare con l'ultima beta di iOS. Se i problemi persistono, si prega di aggiornare la segnalazione di bug con eventuali registri o informazioni pertinenti che potrebbero aiutarci a indagare.

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

al momento l'installazione di iOS 11.2 beta - verificherà il comportamento push silenzioso

Ho avuto un problema simile con la mia app, fino a quando iOS 10 ricevevo notifiche push e application:didReceiveRemoteNotification:fetchCompletionHandlervenivano chiamate correttamente, ma quando sono state aggiornate le notifiche push di iOS 11 hanno smesso di funzionare.

Il problema con il mio codice era, anche se stavo usando content-available: 1 e mutable-content: 1 nel payload di notifica push, l'opzione Background Fetch non era attivata. Ma funzionava perfettamente fino a iOS 10.

Dopo aver attivato la funzionalità di recupero in background, funziona ora

iOS 11.4.1, Swift 4

Avevo problemi con il push silenzioso che non arrivava (da CloudKit) e ho provato tutto ciò che tutti hanno menzionato qui. Quindi ho deciso di provare a impostare uno spazio vuoto alertBodyper i miei CKNotificationInfo()oggetti in questo modo:

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

Ciò ha fatto sì che i push venissero inviati con una priorità più alta (ma erano comunque push silenziosi) e non ho più ricevuto l'errore nei miei registri del dispositivo che il push veniva ignorato.

Spero che aiuti qualcuno. :)

Quindi questo è davvero un bug in iOS 11 ed è ora risolto in iOS 11 beta 3. application:didReceiveRemoteNotification:fetchCompletionHandlerViene ora chiamato correttamente quando viene ricevuto un push silenzioso sia in primo piano che in background.

AGGIORNARE

No, non è stato risolto e continua a verificarsi in iOS beta 3 e 4

Come soluzione alternativa stiamo aggiungendo una chiave di "notifica" e all'interno di un "titolo" con una stringa vuota come valore. Questo è riattivare il callback didReceive in AppDelegate.

Al momento di scrivere questa risposta, sto affrontando lo stesso identico problema della risposta di Bill Dunay .

Il mio requisito era ricevere notifiche silenziose quando l'app è in primo piano e nulla quando l'app è in background / non è in esecuzione. E la mia soluzione è stata questa. Non utilizzo i badge, quindi impostarlo su zero non è un problema per me.

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

Si prega di notare che non sto usando deliberatamente "contenuto disponibile". Impostazione che provoca l'avvio della logica di ottimizzazione di iOS nel ritardare / annullare la consegna della notifica.

Ho ricevuto lo stesso problema per alcune notifiche (non necessariamente silenziose).

Dopo aver esaminato tutti gli aggiornamenti e le risposte sono in grado di aggiungere due aggiornamenti che potrebbero essere d'aiuto:

• Ho scoperto che l'accesso al UIApplication.shared.isRegisteredForRemoteNotificationsmetodo durante la ricezione di una notifica provoca lo stallo dell'applicazione senza segnalare nulla a Xcode. Controlla se stai eseguendo del codice dopo aver ricevuto la notifica che accede al metodo. ( isRegisteredForRemoteNotifications UI di blocco con semaphore_wait_trap ).

  • Ho scoperto che avevo una notifica push che analizzava l'errore sulla console a causa della "title-loc-args" : [3333]non accettazione letterale del 3333 ma dell'accettazione come stringa "title-loc-args" : ["3333"]. Questo ha reso la mia intera interfaccia bloccata dopo aver effettuato l'accesso al metodo sopra, solo su iOS 11, funziona su iOS 12.

• Ho anche scoperto che, con lo stesso identico codice, funziona senza problemi su iOS 12.0 (16A5366a) . Ma su iOS 11 sta succedendo.

Nel mio caso, le notifiche silenziose sono state utilizzate per aggiornare l'interfaccia utente dopo che il lavoro è stato eseguito sul sito del server, quindi è stato doloroso avere contenuti non pertinenti nell'app. Poiché il nostro payload per la notifica silenziosa contiene anche titolo e corpo, implemento questi metodi per ottenere notifiche funzionanti nell'app attiva / inattiva, non in carica e con Aggiornamento app in background disattivato e anche in stato di risparmio energetico.

Per farlo funzionare, aggiungo delegato e creo l'estensione con UNUserNotificationCenterDelegateprotocollo e willPresent notificationmetodo (iOS 10+), che viene attivato ogni volta con il payload corretto. Per non mostrare la notifica quando l'app è attiva, basta chiamare il completamento con badge o suono. Ho finito con qualcosa del genere

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

E per funzionare in questi stati quando l'app è in background e la notifica silenziosa non chiama i miei metodi, ricevo le notifiche dal centro notifiche direttamente applicationDidBecomeActiveda:

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

Nel mio caso, "Aggiornamento app in background" è stato disattivato nelle impostazioni di iPhone. A causa di questa notifica push è stata consegnata al dispositivo ma non sull'app. L'attivazione di Aggiornamento app in background riceve il push silenzioso nell'app.

Questa potrebbe non essere la risposta effettiva a questa domanda, nel caso in cui qualcuno debba verificare.