Companion App — qu'est-ce que c'est, le développement d'applications compagnons

Qu'est-ce que Companion App — une application pour wearable ?

Companion App — une application pour les appareils portables Apple Watch ou Wear OS qui est fournie avec l'application principale iOS ou Android. L'objectif principal est d'étendre les fonctionnalités au poignet : visualisation rapide des informations, réponse aux messages, contrôle de la musique, suivi des entraînements. Companion App s'installe automatiquement sur la montre lors de l'installation de l'application principale sur le téléphone, si le développeur l'a incluse dans le build.

Architecture d'une application compagnon comprend deux composants : l'application iOS/Android (principale) et l'application watchOS/Wear OS (compagnon). La communication entre eux se fait via les API système : WatchConnectivity pour Apple et Wearable Data Layer pour Google. Les données sont transférées en arrière-plan via Bluetooth ou Wi-Fi — l'utilisateur ne voit pas le processus de synchronisation. L'application sur la montre peut avoir sa propre interface utilisateur, différente de celle du mobile, adaptée à un petit écran.

Types d'applications compagnons diffèrent par leur degré de dépendance au téléphone. Les applications miroir affichent une copie des données du téléphone et ne fonctionnent pas sans connexion. Les applications découplées ont leur propre logique, mettent en cache les données et conservent une partie des fonctionnalités lorsqu'elles sont déconnectées du téléphone. Les applications indépendantes (watchOS 6+ et Wear OS 3+) peuvent être installées sans téléphone et fonctionner de manière totalement autonome avec leur propre accès réseau.

WatchConnectivity : synchronisation iPhone et Apple Watch

WatchConnectivity — le framework d'Apple pour la communication bidirectionnelle entre iPhone et Apple Watch. Il fournit quatre mécanismes de transfert de données : Application Context (dernier état connu), File Transfer (fichiers de toutes tailles), User Info (dictionnaires avec livraison garantie) et Interactive Messaging (communication bidirectionnelle en temps réel). Le système choisit automatiquement le Bluetooth ou le Wi-Fi en fonction de la distance et de la qualité du signal.

import WatchConnectivity

class PhoneSessionManager: NSObject, WCSessionDelegate {
    func activateSession() {
        WCSession.default.delegate = self
        WCSession.default.activate()
    }
    func sendWorkoutData(_ data: WorkoutData) {
        let dict = ["heartRate": data.heartRate,
                     "calories": data.calories] as [String: Any]
        WCSession.default.transferUserInfo(dict)
    }
    func session(_: WCSession,
               didReceiveUserInfo: [String: Any]) {
        DispatchQueue.main.async {
            NotificationCenter.default.post(
                name: .workoutDataReceived,
                object: didReceiveUserInfo)
        }
    }
}

Interactive Messaging — le seul mécanisme de WatchConnectivity avec livraison garantie en temps réel. Un message est envoyé et reçoit une réponse en 200 à 500 ms lorsque la connexion est active. Il est utilisé pour les actions nécessitant une réponse immédiate : démarrer un entraînement, confirmer un paiement, ouvrir une porte de maison intelligente. La session doit être active sur les deux appareils — si la montre est verrouillée ou l'application en arrière-plan, la livraison n'est pas garantie.

File Transfer API est conçu pour de grands volumes de données — images, fichiers audio, entraînements exportés. Les fichiers sont transférés en arrière-plan même lorsque l'application est fermée. La limite est de 10 transferts simultanés dans la file d'attente. Application Context est le mécanisme le plus économique : il transmet uniquement le dernier état, annulant les contextes précédents non envoyés. Il est idéal pour synchroniser les paramètres et l'état actuel.

Wearable Data Layer : synchronisation Android et Wear OS

Wearable Data Layer — une API de Google Play Services pour synchroniser les données entre un appareil Android et les montres Wear OS. Il fournit trois protocoles : DataItem (synchronisation de paires clé-valeur), MessageClient (messages unidirectionnels) et ChannelClient (données en streaming). Les DataItems sont synchronisés automatiquement via Google Cloud — si le téléphone est indisponible, les données sont livrées lorsque la connexion est rétablie.

class WearableSyncService : WearableListenerService() {
    override fun onDataChanged(dataEvents: DataEventBuffer) {
        dataEvents.forEach { event ->
            when (event.type) {
                DataEvent.TYPE_CHANGED -> {
                    val uri = event.dataItem.uri
                    val path = uri.path // /workout/heartrate
                    val data = DataMapItem
                        .fromDataItem(event.dataItem)
                        .dataMap
                    val bpm = data.getInt("bpm")
                    updateUI(bpm)
                }
            }
        }
    }
}

MessageClient — envoie des messages unidirectionnels avec un chemin et un tableau d'octets. Il est utilisé pour des commandes comme "Démarrer l'entraînement" ou "Mettre la musique en pause". Le message est livré de manière fiable si l'appareil est connecté. Pour recevoir des messages sur Wear OS, implémentez WearableListenerService et enregistrez-le dans le manifeste. MessageClient ne prend pas en charge la mise en cache automatique — si la montre est déconnectée, le message est perdu.

ChannelClient — un protocole pour les données en streaming : audio, vidéo, flux continus de capteurs. Il ouvre un canal bidirectionnel à travers lequel des tableaux d'octets sont transmis. Il est pris en charge uniquement sur Wear OS 2.0+. ChannelClient est utile pour transmettre l'audio du téléphone à la montre pour les appels via Bluetooth et pour relayer les données des capteurs Bluetooth externes (moniteur de fréquence cardiaque, compteur de vélo) via le téléphone à la montre.

Fonctionnement autonome de l'application compagnon sur la montre

Fonctionnement autonome — la capacité d'une application compagnon à fonctionner sans connexion au téléphone. Sur watchOS avec module Cellular, l'application envoie des requêtes réseau directement via eSIM. Sur Wear OS avec LTE, des fonctionnalités similaires sont disponibles. Même sans module cellulaire, la montre met en cache les dernières données du téléphone et les affiche lorsqu'elle est déconnectée — l'utilisateur voit les informations qui étaient à jour au moment de la dernière synchronisation.

Mise en cache des données — un élément clé du fonctionnement autonome. L'application doit enregistrer le dernier état reçu dans le stockage local de la montre. Sur watchOS, on utilise UserDefaults ou CoreData, sur Wear OS — Room Database ou DataStore. Lorsque la connexion est rétablie, le cache est mis à jour par synchronisation en arrière-plan. Si les données datent de plus de 24 heures, l'application affiche un message "Mettez à jour la connexion au téléphone".

Interface wearable pour écran limité — la montre a un écran de 1,5 à 2 pouces — l'interface de l'application compagnon doit être la plus concise possible. Apple recommande NavigationView avec une colonne sur watchOS, Google recommande une liste de cartes sur Wear OS avec un balayage pour la navigation. Les boutons doivent avoir au moins 44 pt pour un toucher confortable. Évitez les champs de saisie de texte — utilisez des réponses prédéfinies, la dictée ou la molette de défilement Digital Crown.

Conception écoénergétique — l'application compagnon ne doit pas épuiser la batterie de la montre en quelques heures. Utilisez des mises à jour en arrière-plan à intervalle minimal. Sur watchOS, WatchConnectivity interrompt les transferts lorsque la batterie est faible et les reprend après la charge. Sur Wear OS, Wearable Data Layer regroupe automatiquement les petits transferts en un seul pour économiser de l'énergie. Wrist raise — mettez à jour l'interface uniquement lorsque l'utilisateur lève le poignet.

Bonnes pratiques de développement des applications compagnons

Architecture de l'application compagnon doit être conçue en tenant compte d'une éventuelle perte de connexion. Utilisez le modèle Repository : une source de données unique sur le téléphone se synchronise avec le référentiel local sur la montre. Le ViewModel sur la montre s'abonne au référentiel local et affiche les données indépendamment de l'état de la connexion. Lorsque la connexion est rétablie, le Repository sur la montre demande des données via WatchConnectivity ou Wearable Data Layer et met à jour le stockage local.

class WorkoutRepository constructor(
    private val localStorage: WorkoutDao,
    private val wearableClient: WearableClient
) {
    val workoutFlow: Flow<Workout?> = merge(
        localStorage.observeWorkout(),
        wearableClient.observeWorkout()
            .onEach { localStorage.save(it) }
    )
}

Tests d'une application compagnon nécessitent une vérification sur de vraies montres ou un émulateur. Xcode prend en charge le simulateur Apple Watch associé au simulateur iPhone — vous pouvez tester WatchConnectivity sans appareils physiques. Android Studio inclut un émulateur Wear OS avec prise en charge de Wearable Data Layer. Cas de test critiques : perte de connexion pendant le transfert, batterie faible, fonctionnement simultané de deux applications compagnons et installation sans téléphone sur des montres autonomes.

Publication d'une application compagnon sur watchOS ne nécessite pas de téléchargement séparé sur l'App Store — l'application est incluse dans le binaire de l'application iOS et est automatiquement proposée à l'installation sur la montre. Sur Wear OS, l'application compagnon est publiée séparément sur Google Play mais est liée à l'application principale via le même package. App Group sur iOS et sharedUserId sur Android permettent aux applications principale et compagnon d'utiliser un stockage de données partagé.