J'ai remarqué que sur iOS 11 bêta 2, les notifications silencieuses ne sont pas livrées au application:didReceiveRemoteNotification:fetchCompletionHandlerquel que soit l'état de l'application (arrière-plan / premier plan).

J'ai implémenté la UIApplicationDelegeteméthode application:didReceiveRemoteNotification:fetchCompletionHandleret j'envoie le push silencieux suivant

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

mais la méthode déléguée n'est pas appelée sur iOS 11.

Cela fonctionne bien sur les autres versions d'iOS et la section de documentation Configurer une notification silencieuse ne mentionne pas que quoi que ce soit d'autre doit être fait.

Est-ce un bogue dans iOS 11 ou ai-je manqué quelque chose de nouveau dans iOS 11?

Veuillez noter que je ne parle pas ou n'utilise pas le UserNotificationframework qui ne devrait pas être nécessaire pour envoyer des push silencieux.

Voici un exemple de projet qui illustre le problème (vous devrez définir votre propre identifiant de bundle)

Lorsque vous exécutez l'exemple de projet et envoyez une charge utile ci-dessus à l'application, vous pouvez utiliser la console macOS pour voir que le push est correctement transmis à l'appareil mais pas à l'application.

MISE À JOUR 10.08

Il semble que le comportement soit aléatoire. Parfois, après le redémarrage de l'appareil, la charge utile est livrée correctement mais elle cesse de fonctionner après un certain temps.

Comme vous pouvez le voir sur la capture d'écran suivante, le push marqué comme 1 est envoyé uniquement à l'appareil et le push 2 (après le redémarrage de l'appareil) est également livré à l'application.

MISE À JOUR 14.08 - iOS 11 Bêta 6

Toujours le même comportement. Une autre chose qui est censée fonctionner mais qui ne fonctionne pas est la suivante. Lorsque le schéma de l'application est défini sur «Attendre le lancement de l'exécutable», un push silencieux est censé réveiller l'application et la démarrer en arrière-plan.

MISE À JOUR 21.08 - iOS 11 Bêta 7

Toujours le même comportement et pas les mises à jour d'Apple dans le rapport de bogue.

MISE À JOUR 29.08 - iOS 11 Bêta 8

Toujours le même problème. Les étapes à reproduire que j'utilise maintenant sont les suivantes:

• Dans le schéma de projet Xcode, sélectionnez "Attendre le lancement de l'exécutable"
• Ajouter un point d'arrêt dans le didReceiveRemoteNotification: fetchCompletionHandler
• Démarrez l'application sur l'appareil
• Envoyez la poussée silencieuse ci-dessus

Attendu : l'application passe de l'état suspendu à l'arrière-plan et didReceiveRemoteNotification: fetchCompletionHandlerest appelée

Réel : rien ne se passe

MISE À JOUR 06.09 - iOS 11 Bêta 10

J'ai toujours le même comportement de buggy. Le ticket d'Apple a été mis à jour avec la réponse suivante:

Relations avec les développeurs Apple 6 septembre 2017, 22:42 Le service technique a fourni les commentaires suivants concernant ce problème:

Nous avons pu exécuter l'exemple d'application et tester le comportement. Nous n'avons vu aucun problème lorsque nous avons testé cela comme décrit.

Les poussées ne sont pas garanties d'arriver à l'application lorsqu'elle s'exécute en arrière-plan, et les journaux ici indiquent que nous ne pensons pas que l'application est suffisamment utilisée pour la lancer.

Nous nous voyons livrer des poussées de temps en temps lorsque les conditions sont bonnes.

Nous pensons que cela se comporte correctement.

Mise à jour 11.09

Mon rapport de bogue Apple a été fermé et marqué comme doublon 33278611dont reste ouvert

MISE À JOUR 13.09 - iOS 11 GM

Grâce aux commentaires de kam800 (voir ci-dessous), j'ai fait plus de tests et suis venu avec ces observations:

Il semble y avoir un nouveau démon dans iOS 11 dasd DuetActivitySchedulerDaemonqui rejette complètement le push de données ou retarde la livraison de push de données:

Livraison reportée

Journaux de la 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

Problèmes de livraison différée

• Lorsque la livraison push de données est reportée et que l'application est lancée, la poussée de données n'est livrée que lorsque la date de livraison est atteinte, ce qui peut être plusieurs minutes dans le futur. Cela va complètement à l'encontre de l'objectif d'utiliser les poussées de données pour garder le contenu de la nouvelle application prêt pour le prochain lancement. Je cite ici encore une fois la documentation d'Apple:

"Les notifications silencieuses améliorent l'expérience utilisateur en vous aidant à maintenir votre application à jour, même lorsqu'elle n'est pas en cours d'exécution."

• Lorsque deux poussées de données sont envoyées à une application suspendue, elles sont reportées par iOS 11 au lieu de réveiller l'application directement. Lorsque le délai de livraison est atteint, seule la dernière poussée de données est livrée! Les push précédents sont perdus et ne sont pas livrés via la méthode déléguée, ce qui entraîne une perte de données.

Livraison annulée

Journaux de la 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

Problèmes de livraison annulés

Eh bien dans ce cas, la poussée de données est complètement perdue et jamais livrée sur iOS 11 alors qu'elle était correctement livrée sur iOS 10.

MISE À JOUR 19.09 - iOS 11 GM

J'ai également remarqué que lorsque l'application est au premier plan et que la notification n'est pas envoyée à l'application, je vois les journaux suivants dans la 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

Ainsi, les notes de publication d'iOS 11.1 bêta 1 disent

iOS 11.1 beta 1 vient de sortir et mentionne: "Notifications résolues Problèmes • Les notifications push silencieuses sont traitées plus fréquemment. (33278611)

J'ai fait quelques tests et cela semble effectivement corrigé:

État suspendu

Lorsque je lance l'application en mode suspendu et envoie un push silencieux, l'application est ramenée en arrière-plan et le didReceiveRemoteNotification:fetchCompletionHandlerdélégué est appelé.

État de premier plan

De la même manière, lorsque l'application est au premier plan et qu'un push silencieux est envoyé, le délégué semble être appelé comme prévu. Cela ne fonctionnait pas au hasard dans les versions précédentes d'iOS 11, je vais donc le confirmer après plus de tests.

Je voulais juste ajouter mes 2 cents ici car j'ai également été touché par ce problème et j'ai remarqué qu'Apple a fermé plusieurs radars sur ce problème en disant qu'ils ne pouvaient pas se reproduire. Une chose intéressante que j'ai trouvée est que les poussées seront livrées si l'application est en arrière-plan alors qu'elle est attachée au débogueur.

Si je tue le débogueur, débranche mon téléphone, lance l'application et envoie la charge utile push silencieuse, je vois que l'application ne se réveille PAS. Je vois dans le journal de la console que le système annule la livraison de la charge utile à mon application.

J'ai soumis un radar avec un petit exemple d'application qui reproduit le problème. J'ai également noté explicitement dans le radar que la personne travaillant sur mon ticket ne doit pas exécuter l'application associée au débogueur pour reproduire le problème. Voici le lien: https://bugreport.apple.com/web/?problemID=34461063

Espérons que cela entraînera des progrès sur cette question.

On dirait un nouveau comportement d'iOS 11. iOS 11 beta 10 fournit quelques journaux descriptifs concernant ce problème:

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

On dirait que chaque push silencieux est livré à iOS, mais le démon dasd utilise quelques politiques pour décider si le push silencieux doit être livré à l'application (par exemple, niveau de batterie). J'ai réussi à recevoir une poussée silencieuse hier soir, mais mon iPhone était connecté au chargeur à ce moment-là - probablement le score BatteryLevelPolicy était suffisamment élevé pour recevoir cette poussée silencieuse.

Apple ne donne aucune information officielle sur ce comportement côté iOS, il n'y a que des informations sur la limitation côté serveur:

Les notifications silencieuses ne sont pas conçues comme un moyen de garder votre application éveillée en arrière-plan, ni pour les mises à jour hautement prioritaires. Les APN considèrent les notifications silencieuses comme de faible priorité et peuvent ralentir complètement leur diffusion si le nombre total devient excessif. Les limites réelles sont dynamiques et peuvent changer en fonction des conditions, mais essayez de ne pas envoyer plus de quelques notifications par heure.

Je garde les doigts croisés, ils ont changé ce comportement, car cela réparerait mon application :) D'un autre côté, ce changement est bon - une parmi tant d'autres qui fait que la batterie de l'iPhone dure plus longtemps que les téléphones Android.

Les notes de version bêta d'iOS 11.1 incluent: Notifications Problèmes résolus Les notifications push silencieuses sont traitées plus fréquemment. (33278611)

iOS 11.1 Beta 2 contient également

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

dans les notes de version - va le tester maintenant.

MISE À JOUR - 11.10.2017 - iOS 11.1 Bêta 2

Après avoir utilisé notre application pendant 2 jours dans des «scénarios du monde réel», il semble qu'il y ait une réelle amélioration dans cette version d'iOS. Je commence prudemment à croire que c'est réglé.

Les relations avec les développeurs Apple viennent d'ajouter un commentaire à mon radar:

Nous pensons que ce problème est résolu dans la dernière version bêta d'iOS 11.2.

Veuillez tester avec la dernière version bêta d'iOS. Si vous rencontrez toujours des problèmes, veuillez mettre à jour votre rapport de bogue avec tous les journaux ou informations pertinents qui pourraient nous aider à enquêter.

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

installer actuellement iOS 11.2 beta - testera le comportement de push silencieux

J'ai eu un problème similaire avec mon application, jusqu'à iOS 10, je recevais des notifications push et application:didReceiveRemoteNotification:fetchCompletionHandler recevais un appel correct.Mais lors de la mise à jour vers iOS 11, les notifications push ont cessé de fonctionner.

Le problème avec mon code était, même si j'utilisais content-available: 1 et mutable-content: 1 dans la charge de notification push, l'option de récupération en arrière-plan n'était pas activée. Mais cela fonctionnait parfaitement jusqu'à iOS 10.

Après avoir activé la fonction de récupération en arrière-plan, elle fonctionne maintenant

iOS 11.4.1, Swift 4

J'avais des problèmes avec les poussées silencieuses qui n'arrivaient pas (de CloudKit) et j'ai essayé tout ce que tout le monde a mentionné ici. Ensuite, j'ai décidé d'essayer de mettre un blanc alertBodyà mes CKNotificationInfo()objets comme ceci:

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

Cela a fait que les poussées étaient envoyées à une priorité plus élevée (mais elles étaient toujours des poussées silencieuses) et je n'ai plus eu l'erreur dans les journaux de mon appareil indiquant que la poussée était ignorée.

J'espère que cela aide quelqu'un. :)

Il s'agit donc bien d'un bogue dans iOS 11 et il est maintenant corrigé dans iOS 11 beta 3. Le application:didReceiveRemoteNotification:fetchCompletionHandler s'appelle désormais correctement lorsqu'un push silencieux est reçu à la fois au premier plan ou en arrière-plan.

METTRE À JOUR

Non, ce n'est pas corrigé et se produit toujours dans iOS beta 3 et 4

Comme solution de contournement, nous ajoutons une clé "notification" et à l'intérieur d'un "titre" avec une chaîne vide comme valeur. C'est réveiller le rappel didReceive dans l'appDelegate.

Au moment d'écrire cette réponse, je suis confronté au même problème que celui de Bill Dunay. réponse de .

Mon exigence était de recevoir des notifications silencieuses lorsque l'application est au premier plan et rien lorsque l'application est en arrière-plan / ne fonctionne pas. Et ma solution de contournement était la suivante. Je n'utilise pas de badges, donc le mettre à zéro n'est pas un problème pour moi.

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

Veuillez noter que je n'utilise délibérément pas «contenu disponible». Paramètre qui amène la logique d'optimisation iOS à retarder / annuler la livraison de la notification.

J'ai eu le même problème pour certaines notifications (pas nécessairement silencieuses).

Après avoir examiné toutes les mises à jour et les réponses, je suis en mesure d'ajouter deux mises à jour qui peuvent aider:

• J'ai trouvé que l'accès à la UIApplication.shared.isRegisteredForRemoteNotificationsméthode lors de la réception d'une notification provoquait le blocage de l'application sans rien signaler à Xcode. Vérifiez si vous exécutez du code après avoir reçu la notification qui accède à la méthode. ( isRegisteredForRemoteNotifications verrouillant l'interface utilisateur avec semaphore_wait_trap ).

  • J'ai découvert que j'avais une erreur d'analyse de notification push sur la console en raison du fait que le "title-loc-args" : [3333]3333 n'acceptait pas littéralement mais l'acceptait comme une chaîne "title-loc-args" : ["3333"]. Cela a rendu toute mon interface bloquée après avoir accédé à la méthode ci-dessus, uniquement sur iOS 11, cela fonctionne sur iOS 12.

• J'ai également découvert que, avec exactement le même code, cela fonctionne sans aucun problème sur iOS 12.0 (16A5366a) . Mais sur iOS 11, cela se produit.

Dans mon cas, des notifications silencieuses ont été utilisées pour mettre à jour l'interface utilisateur après que le travail ait été effectué sur le site du serveur, il était donc pénible d'avoir un contenu non pertinent dans l'application. Parce que notre charge utile pour la notification silencieuse contient même le titre et le corps, j'implémente ces méthodes pour obtenir des notifications de travail dans l'application active / inactive, sans charger et avec l'actualisation de l'application en arrière-plan désactivée et même en état de faible consommation.

Pour que cela fonctionne, j'ajoute un délégué et crée une extension avec le UNUserNotificationCenterDelegateprotocole et la willPresent notificationméthode (iOS 10+), qui est déclenchée à chaque fois avec une charge utile correcte. Pour ne pas afficher de notification lorsque l'application est active, appelez simplement la fin avec un badge ou un son. J'ai fini avec quelque chose comme ça

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

Et pour faire fonctionner ces états lorsque l'application est en arrière-plan et que la notification silencieuse n'appelle pas mes méthodes, je reçois des notifications du centre de notification directement applicationDidBecomeActivepar:

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

Dans mon cas, "Actualisation de l'application en arrière-plan" a été désactivé dans les paramètres de l'iPhone. En raison de cette notification push a été envoyée à l'appareil mais pas sur l'application. L'activation de l'actualisation de l'application en arrière-plan reçoit le push silencieux dans l'application.

Ce n'est peut-être pas la vraie réponse à cette question, juste au cas où quelqu'un aurait besoin de vérifier.