Significant Location Change — qu’est-ce que c’est, déclencheurs et mécanisme de fonctionnement

Qu’est-ce que Significant Location Change

Significant Location Change (SLC) est un service de géolocalisation économe en énergie d’iOS, intégré au framework Core Location. Il est conçu pour les applications qui doivent suivre les grands déplacements de l’utilisateur sans utiliser constamment le module GPS. SLC s’active automatiquement lors du changement entre les antennes relais et notifie l’application via le délégué CLLocationManagerDelegate par la méthode didUpdateLocations.

Contrairement au suivi de niveau GPS (standard startUpdatingLocation), SLC ne nécessite pas une activité constante du processeur et de la puce GPS. iOS utilise les signaux des antennes relais pour déterminer la position approximative et ne lance l’application qu’en cas de différence significative des coordonnées. Cela permet à l’application de « dormir » entre les mises à jour, consommant un minimum d’énergie.

SLC est disponible sur tous les appareils avec module cellulaire depuis iOS 5. Sur iPod Touch et iPad Wi-Fi uniquement, le service n’est pas disponible car ce sont les antennes relais qui sont utilisées pour déterminer les coordonnées. Core Location décide automatiquement quels événements sont considérés comme significatifs — le développeur ne peut pas ajuster la sensibilité de SLC ni spécifier la distance minimale pour le déclenchement.

Pour quelles applications SLC est-il adapté

SLC est idéal pour les applications qui n’ont pas besoin d’une haute précision de géolocalisation : les trackers météo, les services de livraison, les applications de recherche d’objets à proximité, l’analyse des lieux visités. SLC est également utilisé par le système iOS pour activer le géorepérage (Geofencing) en mode d’économie d’énergie. Les applications de navigation nécessitent un suivi GPS plus précis.

Comment fonctionne Significant Location Change

Significant Location Change fonctionne sur la base de l’analyse des identifiants des antennes relais (Cell ID) que l’appareil reçoit lors de la connexion au réseau. iOS maintient une base de données des coordonnées des antennes et peut déterminer la position approximative sans activer le GPS. Lorsque l’appareil passe à une nouvelle antenne, le système compare la nouvelle et l’ancienne position et, si la différence est significative, lance l’application pour traiter l’événement.

Le système utilise une approche par clusters : l’espace géographique est divisé en clusters d’un rayon déterminé. SLC ne génère un événement qu’au franchissement de la limite d’un cluster, et non lors de chaque micro-déplacement à l’intérieur de celui-ci. Cela empêche les appels en avalanche de l’application lors des déplacements dans une même zone de couverture (par exemple, dans un bâtiment ou un quartier). La précision de SLC varie de 500 mètres à plusieurs kilomètres selon la densité des antennes relais.

Lorsque iOS détecte un changement significatif, il réveille l’application depuis l’état d’arrière-plan (si elle n’est pas en cours d’exécution) et transmet l’événement au délégué Core Location. L’application dispose d’un temps court pour le traitement (environ 10 à 30 secondes de temps d’arrière-plan) — il faut traiter les coordonnées et, si nécessaire, planifier une mise à jour plus précise via GPS.

Lancement de l’application depuis l’arrière-plan

SLC a le privilège de réveiller l’application depuis l’état Suspendu ou Arrière-plan. Si l’application a été tuée par le système en raison d’un manque de mémoire, SLC la redémarrera (relance) en arrière-plan. Pour cela, l’application doit être abonnée à UIApplication.LaunchOptionsKey.location dans la méthode didFinishLaunchingWithOptions. Après le traitement de l’événement, le système peut remettre l’application en état Suspendu.

Déclencheurs de Significant Location Change

Les déclencheurs de SLC sont exclusivement déterminés par le système iOS — le développeur ne peut pas influencer programmatiquement quel changement de coordonnées est considéré comme « significatif ». Cependant, il existe des scénarios documentés dans lesquels SLC génère un événement de manière garantie. Comprendre ces déclencheurs aide le développeur à concevoir un comportement d’application correct.

Changement d’antenne relais

Cell tower change — le déclencheur principal de SLC. Lorsque l’appareil bascule entre les antennes relais (en se déplaçant en ville, sur l’autoroute), le système vérifie si les coordonnées ont suffisamment changé entre l’ancienne et la nouvelle antenne. Si oui, un événement est généré. Dans les conditions urbaines avec un réseau d’antennes dense, SLC peut se déclencher tous les 1 à 3 kilomètres.

Activation du GPS par d’autres applications

Si une autre application ou un service système (par exemple, « Localiser mon iPhone », navigation) active le module GPS, SLC peut également recevoir une mise à jour des coordonnées précises. C’est un effet secondaire : le GPS détermine la position exacte et iOS la transmet à toutes les applications abonnées à SLC. Cependant, il ne faut pas compter sur ce déclencheur — il n’est pas garanti.

Transition entre réseaux Wi-Fi

Bien que SLC n’utilise pas directement le Wi-Fi, le changement de réseau Wi-Fi peut indirectement provoquer un événement si l’appareil reçoit de nouvelles coordonnées via Apple Location Service (localisation par bases de données Wi-Fi). iOS hache les coordonnées des points d’accès Wi-Fi et les utilise pour affiner la position entre les changements d’antennes.

SLC vs autres services de géolocalisation iOS

iOS propose plusieurs mécanismes pour obtenir la géolocalisation, chacun avec sa propre précision, consommation d’énergie et scénarios d’utilisation. Significant Location Change occupe une niche entre l’approximation grossière par antennes et le suivi GPS précis, offrant un équilibre optimal pour les applications qui n’ont pas besoin d’une haute précision en temps réel.

Standard Location Service

Standard Location Service (startUpdatingLocation()) utilise le GPS, le Wi-Fi et les antennes relais pour déterminer les coordonnées avec la plus grande précision. La précision atteint 10 mètres, mais la consommation d’énergie est élevée — le module GPS est constamment actif. Convient pour la navigation, les trackers de fitness, les applications de réalité augmentée. SLC, en revanche, n’utilise pas le GPS en permanence et a une précision de 500 mètres ou moins.

Region Monitoring (Géorepérage)

Region Monitoring surveille l’entrée et la sortie de zones géographiques définies. Contrairement à SLC, le développeur définit lui-même les limites des régions (rayon à partir de 100 mètres). Le géorepérage utilise SLC comme mécanisme auxiliaire — le système détermine d’abord la position approximative via SLC, puis active le GPS pour la détection précise de l’entrée/sortie de la zone. Le nombre maximum de régions surveillées est de 20.

Visit Monitoring

Visit Monitoring est un service spécialisé d’iOS 8+ qui suit la visite de lieux (arrivée et départ). Il utilise une combinaison de SLC et d’autres signaux pour déterminer quand l’utilisateur s’est arrêté à un endroit et quand il l’a quitté. Visit Monitoring est plus économe en énergie que SLC car il génère moins d’événements et utilise l’apprentissage automatique sur l’appareil.

Consommation d’énergie et batterie

SLC est le moyen le plus économe en énergie d’obtenir la géolocalisation sur iOS, à l’exception de Visit Monitoring. Selon Apple, SLC consomme environ 0,1 à 0,5% de charge de batterie par heure dans un scénario d’utilisation typique, tandis que le suivi GPS continu peut consommer 5 à 10% par heure. L’économie est réalisée car le module GPS n’est activé que brièvement pour vérifier les coordonnées lors de chaque événement.

iOS gère la consommation d’énergie de SLC via l’optimisation de la batterie. Si le système remarque que l’application traite trop fréquemment des événements SLC (par exemple, lors d’un déplacement en train avec des changements fréquents d’antennes générant de nombreux événements), iOS peut temporairement réduire la fréquence des notifications. C’est un mécanisme automatique que le développeur ne peut pas désactiver.

À chaque version majeure d’iOS, Apple renforce la politique d’accès à la géolocalisation en arrière-plan. Depuis iOS 13, la boîte de dialogue de demande d’autorisation pour l’utilisation de la localisation en arrière-plan a changé : l’utilisateur doit explicitement choisir « Toujours » (Always) et non simplement « Lors de l’utilisation » (While Using). Sans l’autorisation Always, SLC ne fonctionnera pas lorsque l’application est en arrière-plan ou tuée par le système.

• SLC — 0,1–0,5% de batterie par heure ; GPS — 5–10% par heure en utilisation continue
• iOS 13+ — autorisation Always requise pour SLC en arrière-plan
• Optimisation — iOS réduit automatiquement la fréquence de SLC en cas de mouvement actif
• Traitement par lots — plusieurs événements SLC peuvent être regroupés en une seule notification

Implémentation en Swift

Examinons une implémentation complète de Significant Location Change en Swift. L’exemple inclut la configuration de CLLocationManager, la demande d’autorisation Always, le démarrage de la surveillance, le traitement des événements et la reprise de l’application après sa terminaison par le système. Le code utilise le Swift moderne avec async/await pour le traitement des coordonnées et les tâches d’arrière-plan via BGTaskScheduler.

import CoreLocation
import UIKit

class LocationManager: NSObject, CLLocationManagerDelegate {

    private let manager = CLLocationManager()

    override init() {
        super.init()
        manager.delegate = self
        manager.pausesLocationUpdatesAutomatically = true
        manager.desiredAccuracy = kCLLocationAccuracyThreeKilometers
    }

    func requestAlwaysAuthorization() {
        manager.requestAlwaysAuthorization()
    }

    func startSignificantLocationUpdates() {
        manager.startMonitoringSignificantLocationChanges()
    }

    func locationManager(_ manager: CLLocationManager,
                           didUpdateLocations locations: [CLLocation]) {
        guard let location = locations.last else { return }
        Task.detached {
            await LocationProcessor.handleLocationUpdate(location)
        }
    }

    func locationManager(_ manager: CLLocationManager,
                           didFailWithError error: Error) {
        Logger.log("SLC error: \(error.localizedDescription)")
    }
}

Gestion du redémarrage de l’application

Si l’application a été tuée par le système, SLC la redémarrera automatiquement lors d’un nouvel événement. Dans AppDelegate, il faut ajouter une vérification de lancement par événement de localisation via UIApplication.LaunchOptionsKey.location. Après le redémarrage, l’application doit initialiser CLLocationManager et appeler startMonitoringSignificantLocationChanges() pour continuer la surveillance.

class AppDelegate: NSObject, UIApplicationDelegate {

    private let manager = LocationManager()

    func application(_ application: UIApplication,
                           didFinishLaunchingWithOptions launchOptions:
                               [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        if launchOptions?.keys.contains(.location) == true {
            Logger.log("App relaunched by SLC event")
        }
        manager.requestAlwaysAuthorization()
        manager.startSignificantLocationUpdates()
        return true
    }
}

Bonnes pratiques

L’utilisation correcte de Significant Location Change nécessite un équilibre entre fonctionnalité et efficacité énergétique. Apple contrôle strictement l’accès à la géolocalisation en arrière-plan, et les applications qui abusent de SLC ou l’utilisent sans nécessité explicite risquent un refus lors de la publication sur l’App Store.

Toujours expliquer la nécessité de SLC

Dans Info.plist, il faut ajouter des chaînes de justification : NSLocationAlwaysAndWhenInUseUsageDescription et NSLocationWhenInUseUsageDescription. La description doit expliquer clairement pourquoi l’application a besoin d’un accès à la géolocalisation en arrière-plan. App Review lit ces chaînes et peut rejeter l’application si la justification est insuffisante ou formulée de manière vague. Exemple : « Cette application utilise SLC pour mettre à jour les prévisions météorologiques lors de vos déplacements. »

Ne traiter que les événements nécessaires

N’exécutez pas d’opérations coûteuses (localisation GPS, requêtes réseau) à chaque événement SLC. SLC peut générer des dizaines d’événements par heure lors d’un déplacement en transport. Utilisez le debouncing : enregistrez l’heure de la dernière mise à jour complète et ignorez le traitement si moins de 5 à 10 minutes se sont écoulées depuis la précédente mise à jour. Cela économisera la batterie et le trafic réseau.

Combiner avec BGTaskScheduler

Pour un traitement prolongé après un événement SLC, utilisez BGTaskScheduler. Lorsque l’application reçoit un événement SLC, elle peut planifier une tâche d’arrière-plan via BGProcessingTaskRequest ou BGAppRefreshTaskRequest. Cela permet de reporter les opérations gourmandes en ressources (synchronisation avec le serveur, analyse d’itinéraire) à la prochaine fenêtre d’exécution en arrière-plan, sans bloquer le thread principal de réponse à SLC.

• Info.plist — chaînes de justification obligatoires pour l’accès à la géolocalisation en arrière-plan
• Debouncing — ne pas traiter les événements plus d’une fois toutes les 5 à 10 minutes
• BGTaskScheduler — planifier des tâches d’arrière-plan après un événement SLC
• Autorisation Always — ne demander qu’en cas de réelle nécessité
• pausesLocationUpdatesAutomatically — activer pour la pause automatique du GPS