The Apple Platform Matrix: Which Targets Deserve Which App

TITLE : La matrice des plateformes Apple : quelles cibles méritent quelle application DESCRIPTION : iOS, iPad, Mac, Watch, Vision, TV. Six plateformes, six obligations. Choisir des cibles Apple est une décision produit avant d’être une décision d’ingénierie. BODY: Apple commercialise 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’entre elles une simple opération de case à cocher dans Xcode. Cette case à cocher est le piège. Chaque cible supplémentaire est une obligation, pas une fonctionnalité : chacune étend la surface de conception, de tests, d’accessibilité, de modèle d’exécution et de maintenance continue. Le bon nombre de cibles pour une application est inférieur à ce que le framework permet.

Les applications du cluster fonctionnent avec des combinaisons différentes. 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 restreindront 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.

Chaque plateforme gagne son inclusion grâce à une valeur utilisateur spécifique qu’elle apporte véritablement, et non parce que « ça compile ». La matrice qui survit à la livraison, c’est ce qui reste après que chaque cible se soit justifiée ou ait été coupée.

TL;DR

• Six plateformes, six obligations différentes : iPhone (par défaut), iPad (adaptation des classes de taille), Mac (idiomes 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 conception, de l’accessibilité et une coordination de release continue. 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 tire-t-il un bénéfice réel à exécuter cette application sur cette plateforme ? Si la réponse est « ça marche aussi là-bas », coupez.
• La plupart des applications devraient être livrées sur une à trois plateformes. Quatre à six est rare et ne mérite sa place que lorsque chaque plateforme apporte véritablement une valeur utilisateur que les autres ne peuvent pas offrir.

L’iPhone est la valeur par défaut

Toute application Apple commence sur iPhone, sinon elle ne commence pas. L’iPhone dispose de la plus grande base installée, de la surface d’accessibilité la plus aboutie, du chemin de distribution le plus solide via l’App Store et du langage de conception SwiftUI canonique. Toutes les applications du cluster que j’ai livrées fonctionnent sur iPhone. Aucune n’a été livrée avec une conception qui ne soit pas iPhone-first.

Le test de valeur utilisateur pour l’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, ce sont les outils de développement (Xcode, Terminal) et les outils créatifs qui ont besoin d’espace (Final Cut, Logic). Ceux-ci commencent sur Mac et ne gagnent un compagnon iPhone que s’il existe un transfert clair (fréquence cardiaque sur Watch pendant un entraînement dont le téléphone affiche le graphique, Continuité de l’appareil photo). Pour les logiciels grand public, l’iPhone-first ne se discute pas.

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

Les binaires universels et les classes de taille ont rendu possible la livraison d’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 de savoir si l’application mérite vraiment le canevas plus large de l’iPad.

Trois signaux iPad-oui :

L’application lit ou crée du contenu pour lequel l’utilisateur souhaite plus d’écran. Applications de lecture (Books, actualités, BD, longs documents). Applications de dessin/peinture (Procreate). Prise de notes avec Apple Pencil (Notability, GoodNotes). Get Bananas mérite sa place sur iPad parce qu’une liste de courses avec des sections est plus utile sur un canevas plus large que sur un canevas étroit ; la conception 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 toutes leur place sur iPad parce que l’utilisateur s’attend à de la continuité. L’historique de méditation de Return sur iPad mérite sa place pour la même raison : l’utilisateur commence sur iPhone, jette un œil sur l’iPad pendant que la minuterie tourne.

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

Les signaux iPad-non :

Contenu sur une seule colonne sans valeur supplémentaire à grande échelle. La vue principale d’une minuterie de méditation est un compteur et un bouton. L’iPad rend les deux plus grands ; ce n’est pas une fonctionnalité. Un traceur d’hydratation à journalisation rapide est identique ; l’écran plus large ne change pas ce que l’utilisateur fait pendant une session de journalisation de cinq secondes.

Applications dépendant de matériel spécifique à l’iPhone (Dynamic Island, certains formats d’appareil photo réservés au Pro, l’ergonomie de la prise en main en forme d’iPhone). Ces hypothèses de conception se traduisent mal ; soit reconcevez, soit sautez la cible.

Applications pour lesquelles l’utilisateur dispose déjà d’une meilleure destination sur Mac. Un éditeur de code sur iPad sans prise en charge du clavier est une version dégradée de l’application Mac. Sautez la cible à moins que la conception ne mérite sa place sur le modèle d’entrée spécifique de l’iPad.

Le Mac, c’est les idiomes fenêtre, barre de menus et clavier

Une application SwiftUI livrée sur Mac via la cible macOS native ou « Designed for iPad » (Mac Catalyst étant le chemin équivalent UIKit qui amène le code UIKit sur le Mac) 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 (le modificateur Scene .commands { } avec les builders CommandMenu et CommandGroup dans SwiftUI), les raccourcis clavier, le sélecteur de fichiers macOS, le glisser-déposer avec le Finder et le partage natif Mac.³ Sauter 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 sa place parce que les utilisateurs qui modifient une longue liste de courses à un bureau bénéficient d’une véritable fenêtre avec une navigation au clavier. Return sur Mac le mérite parce que les utilisateurs qui souhaitent qu’une minuterie de méditation tourne 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 sous sa forme adéquate ; 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, touches fléchées pour la sélection. Le coût est par application : chaque cible Mac a besoin d’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. Une minuterie matinale que l’utilisateur lance une fois par jour pendant cinq minutes n’a pas besoin d’une cible Mac. L’utilisateur peut la lancer sur l’iPhone à côté du Mac.

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

L’équipe ne peut pas s’engager dans une maintenance continue spécifique au Mac. Les versions Mac sont scrutées différemment des versions iPhone. Les cycles de mises à jour de macOS, la signature pour Gatekeeper, la notarisation, la revue App Store spécifique au Mac, chacun de ces éléments ajoute du travail de cycle de release que l’équipe doit budgétiser. Si l’équipe ne le budgétise pas, sautez 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 (self-care, mindfulness, physical-therapy, alarm pour WKExtendedRuntimeSession, plus workout-processing pour HKWorkoutSession et underwater-depth pour les sessions de plongée) 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. Minuteries de méditation (session mindfulness). Applications de fitness (HKWorkoutSession avec le mode d’arrière-plan workout-processing). Alarmes intelligentes (alarm). Applications de kinésithérapie et de soins personnels (les types de session correspondants). Return est livrée sur Watch parce que la méditation correspond proprement à mindfulness ; l’application Watch maintient la minuterie en marche malgré la chute du poignet parce que le contrat d’exécution le permet.

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

La valeur d’application compagnon est réelle. Certaines applications Watch existent principalement comme afficheurs pour des données pilotées par l’iPhone (par exemple, une minuterie de recette où l’iPhone fait tourner la minuterie et la Watch affiche le décompte restant). Celles-ci ne méritent leur place que si la synchronisation entre appareils est construite honnêtement (couvert dans Single Source of Truth: SwiftData + TERM_17 + iCloud) et que la vue Watch effectue 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. Sautez.

L’équipe ne peut pas s’engager sur le débogage spécifique à watchOS. Le débogage Watch est singulièrement pénible : le comportement du simulateur diverge du comportement de l’appareil réel d’une manière qui n’apparaît 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 sera livrée cassée.

Le modèle de données ne tient pas dans les enveloppes de synchronisation entre appareils. La synchronisation entre appareils d’iPhone à Watch est généralement WatchConnectivity pour l’état en direct et NSUbiquitousKeyValueStore pour le petit état persistant (Return utilise ce dernier pour la synchronisation de l’historique de session ; couvert dans le billet sur la livraison multi-plateformes). Le store a un plafond de 1 Mo réparti sur toutes les clés, avec un maximum de 1024 clés.⁵ Si l’état de session de l’application ne tient pas dans cette enveloppe, la cible Watch a besoin d’une architecture de synchronisation différente, ce qui représente un véritable investissement en ingénierie.

Vision est le modèle mental spatial

Vision Pro tente les applications de se livrer comme un panneau plat flottant dans un espace 3D. Ce panneau est une fenêtre SwiftUI, et SwiftUI sur visionOS rend sa livraison une opération en un clic. Ce panneau est un iPad en pire. La vraie valeur de la plateforme provient 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 indications 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 que via une cible visionOS native ; cette compatibilité convient à l’utilisateur, mais elle ne fait pas de l’application une expérience native Vision. Le billet sur le modèle mental spatial de RealityKit soutient que mériter la plateforme signifie davantage que simplement y fonctionner.

Le suivi des mains est le bon modèle de saisie. Pincer-pour-attraper, mise à l’échelle à deux mains, dessin en l’air. visionOS offre une affordance de saisie qu’aucune autre plateforme n’a ; les applications qui méritent leur place sur visionOS s’appuient dessus.

L’application gère des surfaces spécifiques au spatial (équivalents de l’écran de verrouillage, 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 est fondamentalement en forme de panneau et ne tire aucun bénéfice de la profondeur. Une application de prise de notes, une application de chat, un utilitaire de paramètres. visionOS les exécutera ; l’utilisateur n’a aucune raison de les utiliser sur visionOS plutôt que sur iPad. Sautez.

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 motifs les plus fragiles ; tester une cible Vision sans appareil réel est singulièrement 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 sensibles en milieu professionnel. L’appareil visionOS est partagé entre membres du foyer d’une manière que l’iPhone n’est pas ; une application qui fait remonter des informations privées a besoin d’une posture différente sur cette plateforme par rapport à l’iPhone.

L’Apple TV 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 surbrillance de focus avec la télécommande, appuie pour sélectionner et ne voit jamais d’interaction tactile. SwiftUI sur tvOS prend cela en charge via le modificateur .focusable(...), le property wrapper @FocusState et .focused(...) pour la liaison d’état, mais chaque application TV a besoin d’une conception de focus partant de zéro.⁶ Le modèle iPhone tap-and-scroll ne se traduit pas.

Signaux TV-oui :

L’application sert à la consommation de contenu à distance de visionnage TV. Vidéo en streaming (Apple TV+, Netflix). Diaporamas photo. Applications de jeux familiaux que l’utilisateur contrôle avec la télécommande. L’utilisateur est sur un canapé, l’écran est loin, la saisie 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 tout en étant aux fourneaux. Histoires du soir que l’utilisateur écoute en s’endormant. Aucune de celles-ci n’est bien servie par un téléphone calé sur la table basse.

Le modèle d’interaction convient à une navigation rare et pilotée par le focus. Une liste d’éléments parmi lesquels l’utilisateur en choisit un à la fois. Une grille d’options. Un flux de lecture linéaire. Tout ce qui est plus complexe que cela, gestes multi-touch, 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 de saisie sur toutes les plateformes Apple. Si l’application a besoin de plus qu’une boîte de recherche, sautez la TV.

La valeur de l’application dépend du fait 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, revue App Store pour tvOS). Pour la plupart des applications, le calcul ne justifie pas la place. Une application de méditation ne mérite une place sur Apple TV qu’avec un véritable mode « laissez-le sur l’écran à faible luminosité pendant que je m’assois sur le canapé » que le cas d’usage récompense réellement ; sans ce mode, même une application dont la minuterie correspond proprement au motif 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 motif : 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 spécifique de valeur utilisateur ; les applications uniquement iPhone y restent parce que rien d’autre ne le justifie. Même chaîne d’outils, produits différents, matrices différentes.

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

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

Un noyau partagé utilise #if os(iOS), #if os(macOS), #if os(watchOS) (et consorts) pour cloisonner les surfaces spécifiques à chaque plateforme.⁷ La logique de domaine du noyau (modèles de données, règles métier, synchronisation) compile partout. L’interface spécifique à chaque plateforme vit derrière des conditionnelles à la compilation. Le @available(iOS 26.0, macOS 26.0, ...) de SwiftUI couvre les différences de version d’OS ; les surfaces qui divergent réellement entre plateformes (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 derrière des barrières #if os(...).

La synchronisation entre appareils passe par un seul substrat, choisi par domaine. NSUbiquitousKeyValueStore pour le petit état au niveau session entre appareils (Return l’utilise pour l’état de minuterie entre appareils). Fichiers iCloud Drive TERM_12 pour les ponts inter-processus (Get Bananas l’utilise avec son serveur TERM_17, 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 de défaillance qui produit la dérive.

Chaque plateforme a des motifs de refus explicites documentés par application. « Nous ne livrerons pas sur la 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, et non 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 facile est le mauvais.

L’équipe ajoute une cible parce que la chaîne d’outils rend cela facile. L’assistant « duplicate target » de Xcode fait de l’ajout d’une cible Mac ou visionOS une opération en quatre clics. Ces quatre clics n’incluent ni la revue de conception, ni l’audit d’accessibilité, ni la création de captures d’écran App Store, ni la coordination de release continue, ni les tests par plateforme. Les cibles livrées depuis l’assistant sans ce travail livré avec elles sont 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 maîtrise les deux est un meilleur produit qu’une application sur cinq plateformes étirée à l’extrême.

L’équipe sous-estime la maintenance continue. Chaque plateforme Apple publie des mises à jour majeures de l’OS chaque année. Une application sur cinq plateformes a cinq ensembles de notes de version auxquels réagir, cinq ensembles de changements de comportement à tester, cinq ensembles de métadonnées App Store à maintenir à jour. Le coût se compose ; 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 motif signifie pour les applications livrées sur iOS 26+

Trois points à retenir.

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 réponse claire à « l’utilisateur tire-t-il un véritable bénéfice à 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). Sauter ces 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 rare et n’est mérité que lorsque chaque plateforme apporte véritablement une valeur utilisateur. Les applications du cluster s’étendent de une à six ; le cas à six plateformes (Return) est l’exception rare, et chaque plateforme supplémentaire y a fait l’objet d’une décision produit distincte avec son propre test de valeur utilisateur.

Le cluster Apple Ecosystem complet : App Intents typés pour la surface Apple Intelligence ; serveurs TERM_17 pour la surface agent ; la question de routage entre eux ; Foundation Models pour les fonctionnalités TERM_23 on-device en application ; la distinction TERM_23 runtime vs outillage ; la synthèse trois surfaces ; le single source of truth pattern ; Two TERM_17 Servers pour l’intégration Xcode ; les hooks pour le développement Apple ; les Live Activities ; le contrat watchOS runtime ; les internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les motifs Liquid Glass ; la livraison multi-plateformes ; ce que je refuse d’écrire. Le hub se trouve sur Apple Ecosystem Series. Pour un contexte plus large iOS-avec-agents-IA, consultez le iOS Agent Development guide.

FAQ

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

Demandez-vous si l’utilisateur tire véritablement un bénéfice à 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 marche aussi là-bas », le bon choix est généralement de sauter 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 rare et n’est mérité que lorsque chaque plateforme apporte véritablement une valeur utilisateur (Return atteint les six parce que la session mindfulness convient à la Watch, la minuterie 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 mode 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 de sauter 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 en colonne unique étirée que les utilisateurs iPad jugent immédiatement comme un travail à moitié fait. Le bon motif est de lire @Environment(\.horizontalSizeClass), d’adapter la mise en page au canevas plus grand (deux colonnes là où cela a du sens via NavigationSplitView, sinon une seule liste avec un espacement confortable), et de considérer Apple Pencil et les affordances 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 (self-care, mindfulness, physical-therapy, alarm pour WKExtendedRuntimeSession, plus workout-processing pour HKWorkoutSession) peuvent s’exécuter après la suspension.⁴ Les applications sans type de session propre produisent des expériences cassées-à-la-deuxième-utilisation. Le billet sur le runtime watchOS du cluster couvre le contrat en détail.

Comment fonctionne la synchronisation entre appareils sur la matrice de plateformes ?

Trois substrats : NSUbiquitousKeyValueStore pour le petit état clé-valeur (paramètres, dernier onglet sélectionné, état de minuterie entre appareils),⁵ fichiers iCloud Drive pour les ponts inter-processus (le motif Get Bananas + serveur TERM_17), 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. Le billet single source of truth du cluster parcourt la matrice de décision.

Références