Silent Push — essence, tâches en arrière-plan et configuration de livraison

Qu'est-ce que Silent Push — essence et but

Silent Push est un mécanisme iOS qui livre des données à l'appareil sans aucune notification visuelle à l'utilisateur. Contrairement à un push standard qui affiche une bannière, joue un son et apparaît dans le Centre de notifications, un silent push « réveille » l'application en arrière-plan et lui transmet des données à traiter. L'utilisateur ne sait jamais qu'une telle notification a été livrée — le résultat est un contenu mis à jour la prochaine fois qu'il ouvre l'application.

Différence avec les notifications push régulières

La différence clé réside dans le payload JSON : un silent push contient l'indicateur content-available: 1 et NE contient PAS alert, sound ou badge. Une notification standard avec alert est toujours affichée à l'utilisateur, indépendamment de content-available. Silent push fonctionne uniquement avec content-available: 1 et sans alert — si vous ajoutez alert, le système affichera la notification même avec l'indicateur de livraison en arrière-plan.

Quand utiliser Silent Push

Les notifications silencieuses sont indispensables pour les scénarios où les données doivent être fraîches au moment où l'utilisateur ouvre l'application, mais sans le distraire. Exemples : mise à jour du fil d'actualités en arrière-plan, synchronisation des abonnements, téléchargement de nouveau contenu pour accès hors ligne, mise à jour des widgets, invalidation du cache. Silent Push est également utilisé pour « préchauffer » l'application avant une action attendue de l'utilisateur.

Comment fonctionne la livraison des notifications silencieuses

La livraison de Silent Push diffère considérablement des notifications régulières et suit des règles d'optimisation énergétique. Le système iOS reçoit la requête push d'APNS, détermine qu'il s'agit d'un silent push (content-available: 1) et décide de le livrer en fonction de multiples facteurs : niveau de batterie, mode d'économie d'énergie, fréquence des silent pushes précédents, activité de l'application et charge actuelle du CPU.

Le rôle de Power Nap et des modes arrière-plan

Sur les appareils équipés d'une puce Apple M et d'iOS 15+, le silent push s'intègre au mécanisme Power Nap qui réveille périodiquement l'appareil pour des tâches en arrière-plan. Power Nap consolide plusieurs silent pushes en une période d'activité, réduisant la consommation d'énergie globale. Le développeur ne peut pas contrôler Power Nap directement — le système prend des décisions automatiquement en fonction du comportement de l'utilisateur et de l'historique d'utilisation de l'application.

La fenêtre de traitement de 30 secondes

Lorsque le système livre un silent push, l'application reçoit un appel à application(_:didReceiveRemoteNotification:fetchCompletionHandler:) dans AppDelegate. Le développeur doit appeler le completion handler dans les 30 secondes, en passant le résultat correct (UIBackgroundFetchResult). Si le traitement n'est pas terminé à temps, le système peut limiter la fréquence des silent pushes pour cette application ou cesser complètement de les livrer.

// Traitement de Silent Push dans AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

Intervalles entre les livraisons

Apple ne publie pas d'intervalles exacts entre les silent pushes, mais sur la base de tests et de documentation, il est recommandé de ne pas envoyer plus de 2–3 notifications silencieuses par heure par appareil. En cas d'envoi plus fréquent, le système commence à ignorer les silent pushes et les données cessent d'être livrées. Si une synchronisation plus fréquente est nécessaire, envisagez d'utiliser URLSession avec une configuration en arrière-plan ou VoIP push.

Cas d'utilisation de Silent Push

Silent Push est utilisé dans une large gamme de tâches où les données doivent être à jour sans la participation active de l'utilisateur. Examinons les cas d'utilisation les plus efficaces de ce mécanisme dans les applications iOS réelles.

Mise à jour du contenu pour accès hors ligne

Les applications d'actualités, les lecteurs et les applications de voyage utilisent Silent Push pour télécharger du nouveau contenu en arrière-plan. Lorsque l'utilisateur ouvre l'application, les données sont déjà chargées et disponibles même sans connexion Internet. Cette approche améliore considérablement l'expérience utilisateur — les écrans de chargement vides disparaissent et le contenu s'affiche instantanément. Le serveur envoie un silent push lorsque de nouveaux articles apparaissent et l'application les télécharge en arrière-plan pour une lecture hors ligne.

Synchronisation de l'état des widgets

iOS WidgetKit met à jour les widgets selon un calendrier, mais pour des mises à jour instantanées après des modifications de données côté serveur, Silent Push est utilisé. L'application en arrière-plan traite le silent push, met à jour le stockage de données local pour les widgets et actualise de force la timeline via WidgetCenter. L'utilisateur voit des informations à jour sur le widget sans ouvrir l'application — taux de change, prévisions météo, statut de livraison.

Invalidation du cache et nettoyage des données obsolètes

Lorsque le serveur met à jour des données critiques (par exemple, les règles de tarification, les fonctionnalités disponibles pour les utilisateurs premium), Silent Push permet d'invalider instantanément le cache local. À la prochaine ouverture, l'application chargera des données fraîches du serveur au lieu d'utiliser un cache obsolète. Ceci est particulièrement pertinent pour les applications avec contenu payant ou abonnements.

Mise à jour du badge sans notification visible

Dans certains scénarios, le badge sur l'icône de l'application doit être mis à jour sans afficher de notification. Un Silent Push avec le champ badge dans le payload permet de définir la valeur de compteur souhaitée sans déranger l'utilisateur avec une bannière. Par exemple, une application de chat peut mettre à jour le badge avec le nombre de messages non lus sans afficher chaque nouveau message comme notification si l'utilisateur est déjà dans l'application.

Configuration de Silent Push : payload et capacités

Pour le bon fonctionnement de Silent Push, une configuration est nécessaire à trois niveaux : le projet Xcode, le payload JSON sur le serveur et le code de traitement dans l'application. Chaque niveau est critique : sauter une étape entraînera la livraison de la notification comme normale ou son absence de livraison.

Configuration des capacités dans Xcode

Dans Xcode, vous devez activer la capacité Push Notifications et Background Modes avec la case Remote notifications cochée. Push Notifications génère un certificat pour APNS, tandis que Remote notifications dans Background Modes permet au système de réveiller l'application lors de la réception d'un silent push. Sans Remote notifications, le silent push sera livré, mais l'application ne sera pas activée en arrière-plan et les données ne seront pas traitées.

Structure du payload JSON

Un payload Silent Push doit contenir la clé aps avec content-available: 1 et NE doit PAS contenir alert, sound ou badge. Les champs personnalisés sont passés au même niveau que aps et contiennent des données à traiter : type d'opération, identifiants d'objets, métadonnées. Un payload sans content-available sera traité comme une notification normale ; avec alert, il sera normal même avec content-available.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

Traitement côté client

Lors de la réception d'un silent push, iOS appelle application(_:didReceiveRemoteNotification:fetchCompletionHandler:) avant que l'application ne devienne visible. Dans cette méthode, vous devez analyser userInfo, effectuer le travail nécessaire (requêtes réseau, écritures Core Data, mises à jour de cache) et toujours appeler le completionHandler avec le résultat correct dans les 30 secondes. Ne pas appeler le completionHandler est considéré comme une erreur par le système et affecte la fréquence des futurs silent pushes.

Limitations et bonnes pratiques

Silent Push n'est pas un canal de livraison de données fiable pour les opérations critiques — c'est un mécanisme d'optimisation, pas une synchronisation garantie. Le développeur doit comprendre les limitations et concevoir le système pour que l'application fonctionne correctement avec et sans silent push.

Limitations de livraison

iOS ne garantit pas la livraison de chaque silent push. Le système peut retarder ou annuler la livraison lorsque la batterie est faible (moins de 20 %), en mode basse consommation, après des silent pushes fréquents ou si l'application n'a pas été utilisée depuis longtemps. Statistiques de livraison moyennes selon Apple : environ 70–80 % des silent pushes sont livrés dans les 5 minutes, les autres peuvent être retardés ou perdus.

Recommandations Apple pour Silent Push

Apple recommande de suivre plusieurs règles pour une utilisation efficace de silent push. N'envoyez pas plus de 2–3 silent pushes par heure par appareil — le dépassement de la limite entraîne un blocage. Utilisez un payload compact : une taille de payload minimale accélère le traitement et réduit la charge réseau. Appelez toujours le completionHandler aussi rapidement que possible : plus le traitement est long, plus le risque que le système restreigne les silent pushes à l'avenir est élevé.

Alternatives à Silent Push

Pour les scénarios nécessitant une livraison garantie ou plus de temps de traitement, envisagez des alternatives. VoIP push (PushKit) garantit la livraison et donne plus de temps, mais est destiné uniquement aux applications VoIP. Background fetch (UIApplication background fetch) est lancé par le système selon un calendrier, mais ne peut pas être initié par le serveur. WebSocket maintient une connexion persistante mais consomme plus de batterie et ne convient pas à tous les types d'applications.

Surveillance et débogage

Pour déboguer Silent Push, utilisez Console.app sur Mac et filtrez par nom d'application. Le système enregistre chaque silent push avec l'étiquette « background task » et indique si le traitement a réussi. Sur un appareil, vérifiez via Réglages → Développeur → Background Modes Logging. Le suivi côté serveur est effectué via APNS Feedback Service pour identifier les notifications non livrées.