La matrice des plateformes Apple : quelles cibles méritent quelle application

Apple propose six plateformes informatiques grand public qu’un développeur peut cibler avec une seule base de code Swift : iPhone, iPad, Mac, Watch, Vision et TV. SwiftUI associé à la chaîne d’outils iOS 26 fait de l’ajout de l’une d’elles une simple opération de cocher une case dans Xcode. Cette case à cocher est le piège. Chaque cible supplémentaire est une obligation, pas une fonctionnalité : chacune étend la surface du design, des tests, de l’accessibilité, du modèle d’exécution et de la maintenance continue. Le bon nombre de cibles pour une application est inférieur à ce que le framework permet.

Les applications du cluster fonctionnent avec différentes combinaisons. Return est livrée sur six plateformes (iPhone, iPad, Mac, Watch, Vision, TV). Get Bananas est livrée sur quatre (iPhone, iPad, Mac, Watch). Reps et Water sont en pré-version avec plusieurs cibles compilées que les applications réduiront avant le lancement. Ace Citizenship et Tappy Color sont chacune livrées uniquement sur iPhone. Même développeur, même chaîne d’outils, six décisions de plateforme différentes. Ces décisions suivent des règles ; ces règles méritent une carte commune.

L’article nomme ces règles. Chaque plateforme gagne son inclusion par une valeur utilisateur spécifique que la plateforme apporte véritablement, et non par un « ça compile ». La matrice qui survit à la livraison est ce qui reste après que chaque cible se justifie elle-même ou se voit retirée.

TL;DR

• Six plateformes, six obligations différentes : iPhone (par défaut), iPad (adaptation aux classes de taille), Mac (idiomes de fenêtre, menu, clavier), Watch (contrat d’exécution), Vision (modèle mental spatial), TV (moteur de focus).
• Chaque cible supplémentaire ajoute une surface de tests, du travail de design, de l’accessibilité et une coordination continue des versions. La case « ajouter une plateforme » de Xcode masque ce coût.
• Les bons tests sont des tests de valeur utilisateur, pas des tests techniques : l’utilisateur bénéficie-t-il véritablement d’exécuter cette application sur cette plateforme ? Si la réponse est « ça fonctionne là aussi », coupez.
• La plupart des applications devraient être livrées sur une à trois plateformes. Quatre à six est inhabituel et ne mérite l’emplacement que lorsque chaque plateforme apporte véritablement une valeur utilisateur que les autres ne peuvent fournir.

L’iPhone est la valeur par défaut

Toute application Apple commence sur iPhone, sinon elle ne commence pas. L’iPhone possède la plus grande base installée, la surface d’accessibilité la plus aboutie, le chemin de distribution le plus solide via l’App Store et le langage de design SwiftUI canonique. Toutes les applications du cluster que j’ai livrées tournent sur iPhone. Aucune n’a été livrée avec un design qui ne soit pas pensé d’abord pour iPhone.

Le test de valeur utilisateur pour iPhone : un utilisateur ouvrirait-il cette application sur un téléphone ? Pour presque toutes les catégories grand public, oui. Les applications de santé et de fitness vivent sur le téléphone. Les outils de productivité vivent sur le téléphone. Les jeux vivent sur le téléphone. Les outils de communication vivent sur le téléphone. La valeur par défaut est l’iPhone parce que le téléphone est là où se trouve l’utilisateur.

L’exception concerne les outils de développement (Xcode, Terminal) et les outils créatifs qui nécessitent de l’espace (Final Cut, Logic). Ceux-ci commencent sur Mac et ne méritent un compagnon iPhone que s’il existe un transfert clair (la fréquence cardiaque sur Watch pendant un entraînement dont le téléphone affiche le graphique, Camera Continuity). Pour les logiciels grand public, l’iPhone d’abord n’est pas un débat.

L’iPad n’est pas un iPhone avec plus de pixels

Catalyst a permis de livrer une application iPhone UIKit sur iPad avec des points de rupture par classe de taille. SwiftUI a rendu la même chose plus facile via @Environment(\.horizontalSizeClass) et NavigationSplitView. Le coût technique de « livrer sur iPad » est faible. Le coût produit est la question de savoir si l’application mérite réellement la toile plus grande de l’iPad.

Trois signaux iPad-oui :

L’application lit ou crée du contenu pour lequel l’utilisateur veut plus d’écran. Applications de lecture (Books, actualités, BD, longs documents). Applications de dessin/peinture (Procreate). Prise de notes avec l’Apple Pencil (Notability, GoodNotes). Get Bananas mérite son emplacement iPad parce qu’une liste de courses avec des sections est plus utile sur une toile plus large que sur une toile étroite ; le design iPad adapte la même liste de sections à la zone plus grande.

L’application a une valeur de transfert avec iPhone ou Mac. Apple Notes, Reminders et Mail méritent tous des emplacements iPad parce que l’utilisateur attend de la continuité. L’historique de méditation de Return sur iPad mérite son emplacement pour la même raison : l’utilisateur commence sur iPhone, jette un œil à l’iPad pendant que le minuteur tourne.

L’application possède une affordance d’entrée native iPad. Apple Pencil pour le croquis/l’écriture manuscrite. Gestes multi-doigts sur une surface plus grande. Workflows Stage Manager qui bénéficient d’une mise en page en tuiles. Si l’affordance n’existe pas sur iPhone, la cible iPad mérite sa place.

Les signaux iPad-non :

Contenu en colonne unique sans valeur supplémentaire à l’échelle. La vue principale d’un minuteur de méditation est un compte et un bouton. L’iPad rend les deux plus grands ; ce n’est pas une fonctionnalité. Un suivi d’hydratation à enregistrement rapide est identique ; l’écran plus large ne change pas ce que fait l’utilisateur pendant une session d’enregistrement de cinq secondes.

Applications qui dépendent de matériel spécifique à l’iPhone (Lock Screen, Dynamic Island, ProMotion dans certaines configurations spécifiques à l’iPhone, certains formats de caméra). Ces hypothèses de design se traduisent mal ; il faut soit reconstruire le design, soit ignorer la cible.

Applications pour lesquelles l’utilisateur a déjà une meilleure destination sur Mac. Un éditeur de code sur iPad sans support clavier est une version handicapée de l’application Mac. Ignorez la cible à moins que le design ne mérite sa place sur le modèle d’entrée spécifique de l’iPad.

Le Mac, ce sont les idiomes de fenêtre, de barre de menus et de clavier

Une application SwiftUI livrée sur Mac via Mac Catalyst ou « Designed for iPad » s’exécute sur macOS sans produire une véritable application Mac. Une véritable application Mac respecte la sémantique de redimensionnement des fenêtres, la barre de menus (Commands(content:) en SwiftUI), les raccourcis clavier, le sélecteur de fichiers macOS, le glisser-déposer avec le Finder, et le partage natif Mac. Ignorer l’un de ces éléments produit une expérience d’application iPad dans une fenêtre que les utilisateurs Mac remarquent et jugent.

Signaux Mac-oui :

L’utilisateur passe du temps dans l’application et bénéficierait qu’elle soit une véritable fenêtre de bureau. Get Bananas sur Mac mérite son emplacement parce que les utilisateurs qui éditent une longue liste de courses à un bureau bénéficient d’une véritable fenêtre avec navigation au clavier. Return sur Mac le mérite parce que les utilisateurs qui veulent un minuteur de méditation tournant sur leur machine de travail bénéficient d’une véritable application de barre de menus ou d’une fenêtre épinglée à un coin spécifique.

Workflows multi-fenêtres ou multi-documents. Un éditeur de code avec des panneaux divisés. Un éditeur photo avec des images de référence côte à côte. Un tableur. Aucun de ceux-ci ne survit sur iPad ou iPhone dans sa forme appropriée ; le Mac est la bonne plateforme.

Interaction pilotée par le clavier. Une application SwiftUI sur Mac qui ignore le clavier n’est une application Mac que de nom. Cmd+N pour nouveau, Cmd+W pour fermer, Tab pour la traversée du focus, flèches pour la sélection. Le coût est par application : chaque cible Mac nécessite une surface clavier réfléchie.

Signaux Mac-non :

L’application est un petit outil à tâche unique qui ne bénéficie pas d’une fenêtre. Un minuteur du matin que l’utilisateur exécute une fois par jour pendant cinq minutes n’a pas besoin d’une cible Mac. L’utilisateur peut l’exécuter sur l’iPhone à côté du Mac.

Applications dont l’interface utilisateur en forme d’iPhone ne se traduit fondamentalement pas. Applications de caméra. Applications compagnon Apple Watch. Applications dont le modèle d’entrée est tactile-d’abord et dont l’équivalent clavier/souris serait pire que de toucher le téléphone.

L’équipe ne peut pas s’engager sur une maintenance continue spécifique au Mac. Les versions Mac sont scrutées différemment des versions iPhone. Cycles de mise à jour macOS, signature pour Gatekeeper, notarisation, examen App Store spécifique au Mac, chacun de ceux-ci ajoute du travail de cycle de release que l’équipe doit budgétiser. Si l’équipe ne le budgétise pas, ignorez la cible.

L’Apple Watch est un contrat d’exécution

La Watch est la plateforme où « livrer dessus » est une instruction activement trompeuse. Le modèle d’exécution de la Watch, couvert en détail dans watchOS Runtime Is a Contract, Not a Background Task, est fondamentalement différent de celui d’iOS : le poignet retombe, le système suspend l’application, et seuls des types de session spécifiques (mindfulness, workout-processing, alarm, etc.) peuvent s’exécuter après la suspension. Une cible Watch sans histoire d’exécution est cassée à la deuxième utilisation.

Signaux Watch-oui :

L’application a une forme de session que le modèle d’exécution watchOS reconnaît. Minuteurs de méditation (session mindfulness). Applications de fitness (workout-processing). Réveils (alarm). Navigation (le type de session navigation). Return est livrée sur Watch parce que la méditation correspond proprement à mindfulness ; l’application Watch garde le minuteur en marche à travers la chute du poignet parce que le contrat d’exécution le permet.

L’utilisateur veut véritablement le poignet comme surface d’entrée. Un visualiseur de fréquence cardiaque pendant l’exercice. Un minuteur que l’utilisateur démarre sans sortir le téléphone. Une complication qui fait remonter une information d’un coup d’œil. Get Bananas est livrée sur Watch comme surface rapide de vérification de liste, associée à l’iPhone comme magasin canonique ; une application d’entraînement comme Reps mérite sa cible Watch pour la même raison, parce qu’enregistrer une série au poignet est plus rapide que de pêcher le téléphone dans une poche.

La valeur d’application compagnon est réelle. Certaines applications Watch existent principalement comme affichages pour des données pilotées par l’iPhone (par exemple, un minuteur de recette où l’iPhone fait tourner le minuteur et la Watch affiche le compte restant). Celles-ci ne méritent leur emplacement que si la synchronisation entre appareils est construite honnêtement (couvert dans Single Source of Truth: SwiftData + MCP + iCloud) et que la vue Watch fait un travail réel au-delà du simple miroir.

Signaux Watch-non :

L’application n’a aucun type de session qu’elle puisse revendiquer. Une application de lecture sur la Watch n’est une application Watch que de nom. L’utilisateur ne peut pas lire un livre sur un poignet ; le modèle d’exécution n’étend pas la session. Ignorez.

L’équipe ne peut pas s’engager sur du débogage spécifique à watchOS. Le débogage Watch est uniquement pénible : le comportement du simulateur diverge du comportement sur appareil réel d’une manière qui ne se manifeste que sur une véritable Apple Watch dans des conditions de chute du poignet. Si l’équipe n’a pas le matériel et la volonté de tester dessus, la cible Watch est livrée cassée.

Le modèle de données ne tient pas dans une enveloppe de synchronisation entre appareils de 1 Mo. La synchronisation entre appareils d’iPhone à Watch passe généralement par NSUbiquitousKeyValueStore (couvert dans l’article sur la livraison multi-plateforme). Le store dispose de 1 Mo total + 1 Mo par valeur + 1 024 clés. Si l’état de session de l’application ne tient pas dans cette enveloppe, la cible Watch nécessite une architecture de synchronisation différente, ce qui représente un véritable investissement d’ingénierie.

Vision est le modèle mental spatial

Le Vision Pro tente les applications de se livrer comme un panneau plat flottant dans l’espace 3D. Ce panneau est une fenêtre SwiftUI, et SwiftUI sur visionOS rend sa livraison une opération en un clic. Le panneau est un iPad en pire. La véritable valeur de la plateforme vient du modèle mental spatial, couvert dans RealityKit and the Spatial Mental Model, où le contenu vit dans la pièce plutôt que dans le panneau.

Signaux Vision-oui :

L’application a du contenu 3D qui bénéficie d’être dans la pièce. Une sculpture virtuelle autour de laquelle l’utilisateur peut marcher. Un mètre ruban qui se pose sur un mur réel. Un coach d’entraînement qui projette des indices de posture sur une image miroir du corps de l’utilisateur. La plupart des applications du cluster qui apparaissent sur visionOS le font via la compatibilité « Designed for iPad » plutôt qu’une cible visionOS native ; cette compatibilité convient à l’utilisateur mais elle ne fait pas de l’application une expérience native Vision. L’article sur le modèle mental spatial de RealityKit soutient que mériter la plateforme signifie plus que tourner dessus.

Le suivi des mains est le bon modèle d’entrée. Pincer pour saisir, mise à l’échelle à deux mains, dessin en l’air. visionOS offre une affordance d’entrée qu’aucune autre plateforme ne possède ; les applications qui méritent leur emplacement visionOS s’y appuient.

L’application gère des surfaces spécifiques au spatial (équivalents Lock Screen, espaces immersifs, ornements). Les applications de productivité qui se contentent de faire flotter leur interface iPhone sur Vision sont du bruit visible dès le premier jour de l’utilisateur avec l’appareil. Les applications qui font revenir l’utilisateur sont celles qui exploitent la surface spatiale.

Signaux Vision-non :

L’application a fondamentalement la forme d’un panneau et ne bénéficie aucunement de la profondeur. Une application de prise de notes, une application de chat, un utilitaire de paramètres. visionOS les fera tourner ; l’utilisateur n’a aucune raison de les utiliser sur visionOS plutôt que sur iPad. Ignorez.

L’équipe de développement n’a pas de tests spécifiques à visionOS. visionOS est la plateforme avec la plus petite base installée et les patterns les plus fragiles ; tester une cible Vision sans appareil réel est uniquement difficile, plus encore que dans le cas de watchOS.

Les préoccupations de confidentialité et de présence dominent. Applications de divulgation de santé. Outils de travail sensibles. L’appareil visionOS est partagé entre les membres du foyer d’une manière que l’iPhone ne l’est pas ; une application qui fait remonter des informations privées nécessite une posture différente là-bas que sur iPhone.

L’Apple TV, c’est le moteur de focus

Les applications TV sont pilotées par le moteur de focus de la Siri Remote : l’utilisateur déplace une mise en évidence du focus avec la télécommande, appuie pour sélectionner et ne voit jamais d’interaction tactile. SwiftUI sur tvOS prend en charge cela via le modificateur .focusable(...), le wrapper de propriété @FocusState et .focused(...) pour la liaison d’état, mais chaque application TV nécessite une conception du focus à partir de zéro. Le modèle iPhone tap-and-scroll ne se traduit pas.

Signaux TV-oui :

L’application est destinée à la consommation de contenu à la distance d’un téléviseur. Vidéo en streaming (Apple TV+, Netflix). Diaporamas photo. Applications de jeu familial que l’utilisateur contrôle avec la télécommande. L’utilisateur est sur un canapé, l’écran est loin, l’entrée est rare, la TV est la bonne plateforme.

L’application a un cas d’usage « lean back » que l’iPhone n’a pas. Vidéos d’entraînement que l’utilisateur suit. Applications de cuisine que l’utilisateur consulte près des fourneaux. Histoires du soir que l’utilisateur écoute en s’endormant. Aucun de ceux-ci n’est bien servi par un téléphone calé sur la table basse.

Le modèle d’interaction correspond à une navigation rare et pilotée par le focus. Une liste d’éléments que l’utilisateur sélectionne un à la fois. Une grille d’options. Un flux de lecture linéaire. Tout ce qui est plus complexe que cela, gestes multitouch, saisie de texte fine, glisser-déposer, ne fonctionne pas sur tvOS et signifie que la cible est mauvaise.

Signaux TV-non :

L’application a besoin de saisie de texte. La saisie de texte TV via la télécommande est l’un des pires modèles d’entrée sur toute plateforme Apple. Si l’application a besoin de plus qu’une boîte de recherche, ignorez la TV.

La valeur de l’application dépend de ce que les mains de l’utilisateur soient libres pour d’autres tâches. Suivi de fitness. Surveillance de la santé. Collaboration en temps réel. La TV est un écran, pas un objet portable.

Le coût de maintenance est trop élevé pour la base installée. tvOS a une petite base installée par rapport à iOS. Le coût de développement est réel (conception du focus, tests séparés, examen App Store pour tvOS). Pour la plupart des applications, les calculs ne justifient pas l’emplacement. Une application de méditation ne mérite un emplacement Apple TV qu’avec un véritable mode « laissez-le sur l’écran à faible luminosité pendant que je suis assis sur le canapé » que le cas d’usage récompense réellement ; sans ce mode, même une application dont le minuteur correspond proprement au pattern lean-back de la TV ne mérite pas la facture de maintenance.

La matrice en pratique

La matrice réelle de chaque application du cluster :

Le pattern : chaque ligne est une coupe délibérée autant qu’un ajout délibéré. Return atteint six plateformes parce que chacune est justifiée par un test de valeur utilisateur spécifique ; les applications iPhone uniquement y restent parce que rien d’autre ne l’est. Même chaîne d’outils, produits différents, matrices différentes.

Trois décisions d’architecture qui rendent la matrice durable

Trois patterns qui empêchent les applications multi-plateformes de s’effondrer sous leur propre poids :

Un cœur partagé cible #if canImport(SwiftUI) && canImport(<platform>) pour les surfaces spécifiques aux plateformes. La logique de domaine principale (modèles de données, règles métier, synchronisation) compile partout. L’interface utilisateur spécifique à la plateforme vit derrière des conditionnels à la compilation. Le @available(iOS 26.0, macOS 26.0, ...) de SwiftUI couvre la plupart des cas ; les surfaces qui divergent véritablement (une barre de menus Mac qui n’a pas d’équivalent iPhone, une complication Watch qui n’a pas d’équivalent iPad) ont leurs propres fichiers dans des groupes spécifiques à la cible.

La synchronisation entre appareils passe par un seul substrat, choisi par domaine. NSUbiquitousKeyValueStore pour l’état de niveau session de petite taille à travers les appareils (Return l’utilise pour l’état du minuteur entre appareils). Fichiers iCloud Drive JSON pour les ponts entre processus (Get Bananas l’utilise avec son serveur MCP, couvert dans Single Source of Truth). SwiftData pour l’état en cours de processus. Mélanger les substrats par domaine est acceptable ; utiliser deux substrats pour le même domaine est le mode d’échec qui produit la dérive.

Chaque plateforme a des patterns de refus explicites documentés par application. « Nous ne livrerons pas sur TV à moins que le cas d’usage n’ait un mode lean-back. » « Nous ne livrerons pas sur Vision à moins que l’application n’utilise RealityKit, pas un panneau. » « Nous ne livrerons pas sur Watch sans un type de session. » Les refus sont des décisions de projet capturées par application et appliquées de manière cohérente, dans l’esprit de What I Refuse To Write About.

Quand ajouter des plateformes est une erreur

Trois cas où le chemin le plus facile est le mauvais.

L’équipe ajoute une cible parce que la chaîne d’outils le rend facile. L’assistant « duplicate target » de Xcode rend l’ajout d’une cible Mac ou visionOS une opération en quatre clics. Les quatre clics n’incluent pas la revue de design, l’audit d’accessibilité, la création de captures d’écran App Store, la coordination continue des versions ou les tests par plateforme. Les cibles livrées depuis l’assistant sans ce travail sont livrées cassées dès le premier jour.

L’équipe traite le nombre de cibles comme un signal de statut. « Nous livrons sur cinq plateformes Apple » sonne impressionnant dans un tweet de lancement. Le tweet de lancement ne tourne pas sur les appareils des utilisateurs ; les applications, oui. Une application sur deux plateformes qui réussit les deux est un meilleur produit qu’une application sur cinq plateformes qui est étirée.

L’équipe sous-estime la maintenance continue. Chaque plateforme Apple publie des mises à jour majeures du système d’exploitation chaque année. Une application sur cinq plateformes a cinq jeux de notes de version auxquels réagir, cinq jeux de changements de comportement à tester, cinq jeux de métadonnées App Store à maintenir à jour. Le coût se cumule ; les équipes qui livrent sur les cinq sans la bande passante pour les maintenir produisent des produits qui se dégradent lentement sur trois de ces plateformes.

Ce que ce pattern signifie pour les applications livrant sur iOS 26+

Trois enseignements.

1. L’inclusion d’une plateforme est une décision produit avant d’être une décision d’ingénierie. La case à cocher Xcode est le côté ingénierie ; le test de valeur utilisateur est le côté produit. Sans une réponse claire à « l’utilisateur bénéficie-t-il véritablement d’exécuter cette application sur cette plateforme », la cible est coupée.

2. Chaque plateforme apporte des obligations spécifiques : classe de taille (iPad), fenêtre/menu/clavier (Mac), contrat d’exécution (Watch), modèle spatial (Vision), moteur de focus (TV). Ignorer les obligations produit une application iPad sur Mac, une application téléphone sur Vision, une application iPhone sur Watch, autant d’échecs visibles que les véritables utilisateurs de la plateforme remarquent.

3. La plupart des applications devraient être livrées sur une à trois plateformes. Quatre à six est inhabituel et mérité uniquement lorsque chaque plateforme apporte véritablement une valeur utilisateur. Les applications du cluster s’étendent d’une à six ; le cas à six plateformes (Return) est l’exception qui confirme la règle, et chaque plateforme supplémentaire était une décision produit séparée avec son propre test de valeur utilisateur.

Le cluster Apple Ecosystem complet : App Intents typés pour la surface Apple Intelligence ; serveurs MCP pour la surface agent ; la question de routage entre eux ; Foundation Models pour les fonctionnalités LLM in-app sur appareil ; la distinction LLM runtime vs outillage ; la synthèse des trois surfaces ; le pattern source unique de vérité ; Two MCP Servers pour l’intégration Xcode ; hooks pour le développement Apple ; Live Activities ; le contrat runtime watchOS ; les internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les patterns Liquid Glass ; la livraison multi-plateforme ; ce sur quoi je refuse d’écrire. Le hub se trouve sur la série Apple Ecosystem. Pour un contexte plus large iOS-avec-agents-IA, consultez le guide iOS Agent Development.

FAQ

Comment décider d’ajouter ou non une cible de plateforme Apple ?

Demandez-vous si l’utilisateur bénéficie véritablement d’exécuter l’application sur cette plateforme, et non si la chaîne d’outils le permet. La case à cocher Xcode est le côté technique ; le test de valeur utilisateur est le côté produit. Chaque plateforme apporte des obligations spécifiques (classe de taille, fenêtre/menu, contrat d’exécution, modèle spatial, moteur de focus) et un coût de maintenance spécifique. Si la réponse est « ça fonctionne là aussi », le bon choix est généralement d’ignorer la cible.

Devrais-je livrer sur les six plateformes Apple ?

Généralement non. La plupart des applications bénéficient d’une à trois plateformes. Quatre à six est inhabituel et mérité uniquement lorsque chaque plateforme apporte véritablement une valeur utilisateur (Return atteint les six parce que la session mindfulness convient à la Watch, le minuteur convient à l’iPad et au Mac comme compagnons de bureau, visionOS convient à un mode immersif et la TV convient à un cas d’usage canapé en lean-back). Pour la plupart des applications, le modèle d’interaction de tvOS et les exigences spatiales de visionOS ne conviennent pas, et le bon choix est d’ignorer ces cibles.

Quelle est l’erreur la plus courante lors de l’ajout d’une cible iPad ?

Traiter l’iPad comme un « iPhone avec plus de pixels ». Une application SwiftUI iPhone déposée sur iPad sans adaptation des classes de taille produit une interface utilisateur en colonne unique étirée que les utilisateurs iPad jugent immédiatement comme un travail à moitié fait. Le bon pattern est de lire @Environment(\.horizontalSizeClass), d’adapter la mise en page à la toile plus grande (deux colonnes là où cela a du sens via NavigationSplitView, sinon une liste unique avec un espacement confortable) et de considérer les affordances Apple Pencil et multi-doigts comme une valeur spécifique à l’iPad.

Pourquoi l’Apple Watch est-elle si différente des autres plateformes ?

watchOS n’a pas le modèle d’exécution en arrière-plan d’iOS. Le poignet retombe, le système suspend l’application, et seuls des types de session spécifiques (mindfulness, workout-processing, alarm, etc.) peuvent s’exécuter après la suspension. Les applications sans un type de session propre produisent des expériences cassées à la deuxième utilisation. L’article watchOS runtime du cluster couvre le contrat en détail.

Comment fonctionne la synchronisation entre appareils à travers la matrice de plateformes ?

Trois substrats : NSUbiquitousKeyValueStore pour l’état clé-valeur de petite taille (paramètres, dernier onglet sélectionné, état du minuteur entre appareils), fichiers iCloud Drive pour les ponts entre processus (le pattern Get Bananas + serveur MCP), SwiftData pour l’état en cours de processus. Choisissez un substrat par domaine ; en mélanger deux pour le même domaine produit de la dérive. L’article single source of truth du cluster parcourt la matrice de décision.