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

Apple propose six plateformes grand public qu’un développeur peut viser depuis une seule base de code Swift : iPhone, iPad, Mac, Watch, Vision et TV. Avec SwiftUI et la chaîne d’outils iOS 26, en ajouter une se réduit à cocher une case dans Xcode. Et c’est précisément là qu’est le piège. Chaque cible supplémentaire est une obligation, pas une fonctionnalité : elle élargit la surface du design, des tests, de l’accessibilité, du modèle d’exécution et de la maintenance à venir. Le bon nombre de cibles pour une application est inférieur à ce que le framework autorise.

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

Chaque plateforme gagne sa place par la valeur d’usage précise qu’elle apporte réellement, et non parce que « ça compile ». La matrice qui survit à la mise en production, c’est ce qui reste une fois que chaque cible s’est justifiée ou a été écartée.

En bref

• Six plateformes, six obligations différentes : iPhone (le socle), iPad (adaptation aux classes de taille), Mac (idiomes de fenêtre, de barre de menus et de clavier), Watch (contrat d’exécution), Vision (modèle mental spatial), TV (moteur de focus).
• Chaque cible supplémentaire ajoute de la surface de test, du travail de design, de l’accessibilité et de la coordination continue des sorties. La case « ajouter une plateforme » de Xcode masque ce coût.
• Les bons tests portent sur la valeur d’usage, pas sur la technique : l’utilisateur tire-t-il un vrai bénéfice de l’application sur cette plateforme ? Si la réponse est « ça fonctionne là aussi », coupez.
• La plupart des applications devraient sortir sur une à trois plateformes. Quatre à six reste rare et ne se justifie que si chaque plateforme apporte réellement une valeur d’usage que les autres ne peuvent pas offrir.

L’iPhone est le socle

Toute application Apple commence sur iPhone, sinon elle ne commence pas. L’iPhone dispose du parc installé le plus important, de la surface d’accessibilité la plus aboutie, du canal de distribution le plus solide via l’App Store et du langage de design SwiftUI canonique. Toutes les applications du portfolio que j’ai publiées tournent sur iPhone. Aucune n’a été conçue d’abord pour une autre plateforme.

Le test de valeur d’usage 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. Le socle est l’iPhone parce que c’est là que se trouve l’utilisateur.

Font exception les outils de développement (Xcode, Terminal) et les outils de création qui réclament de l’espace (Final Cut, Logic). Ceux-là démarrent sur Mac et ne gagnent une déclinaison iPhone que si un relais clair existe (la fréquence cardiaque relevée par la Watch pendant une séance dont le téléphone affiche la courbe, Appareil photo Continuité). Pour le logiciel grand public, la priorité à l’iPhone ne se discute pas.

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

Les binaires universels et les classes de taille ont permis de publier une application iPhone UIKit sur iPad avec des points de rupture par classe de taille. SwiftUI a simplifié la même chose via @Environment(\.horizontalSizeClass) et NavigationSplitView.¹ Le coût technique d’une sortie sur iPad est faible. La vraie question, côté produit, est de savoir si l’application mérite la toile plus vaste de l’iPad.

Trois signaux favorables à l’iPad :

L’application lit ou crée du contenu pour lequel l’utilisateur veut plus d’écran. Applications de lecture (livres, actualité, bandes dessinées, documents longs). Applications de dessin et de peinture (Procreate). Prise de notes à l’Apple Pencil (Notability, GoodNotes). Get Bananas gagne sa place sur iPad parce qu’une liste de courses organisée en rayons est plus utile sur une toile large que sur une toile étroite ; le design iPad adapte cette même liste par rayons à la surface plus vaste.

L’application a une valeur de relais avec l’iPhone ou le Mac. Notes, Rappels et Mail méritent tous leur place sur iPad parce que l’utilisateur attend cette continuité. L’historique de méditation de Return sur iPad se justifie de la même façon : l’utilisateur démarre sur iPhone et jette un œil à l’iPad pendant que le minuteur tourne.

L’application dispose d’un mode de saisie propre à l’iPad. L’Apple Pencil pour croquer ou écrire à la main. Les gestes multi-doigts sur une surface plus grande. Les flux de travail Stage Manager qui tirent parti d’une disposition en tuiles. Si cette possibilité n’existe pas sur iPhone, la cible iPad mérite sa place.

Les signaux défavorables à l’iPad :

Un contenu en colonne unique qui ne gagne rien à s’étendre. La vue principale d’un minuteur de méditation, c’est un décompte et un bouton. L’iPad agrandit les deux ; ce n’est pas une fonctionnalité. Un suivi d’hydratation à saisie rapide relève du même cas : l’écran plus large ne change rien à ce que fait l’utilisateur pendant une saisie de cinq secondes.

Les applications qui dépendent du matériel propre à l’iPhone (Dynamic Island, certains formats photo réservés aux modèles Pro, l’ergonomie de prise en main du téléphone). Ces partis pris de design se transposent mal : soit vous refondez le design, soit vous abandonnez la cible.

Les 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 n’est qu’une version amputée de l’application Mac. Abandonnez la cible, à moins que le design ne gagne sa place sur le modèle de saisie spécifique de l’iPad.

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

Une application SwiftUI publiée sur Mac via la cible macOS native ou via « Designed for iPad » (Mac Catalyst étant le chemin équivalent côté UIKit, qui porte le code UIKit sur le Mac) tourne sur macOS sans pour autant produire une véritable application Mac.² Une vraie application Mac respecte la sémantique de redimensionnement des fenêtres, la barre de menus (le modificateur de Scene .commands { } avec les constructeurs CommandMenu et CommandGroup en SwiftUI), les raccourcis clavier, le sélecteur de fichiers macOS, le glisser-déposer avec le Finder et le partage natif du Mac.³ En négliger un seul suffit à produire une expérience d’application iPad dans une fenêtre, que les utilisateurs Mac repèrent et jugent.

Signaux favorables au Mac :

L’utilisateur passe du temps dans l’application et gagnerait à ce qu’elle soit une vraie fenêtre de bureau. Get Bananas sur Mac mérite sa place parce que les utilisateurs qui éditent une longue liste de courses à leur bureau profitent d’une vraie fenêtre avec navigation au clavier. Return sur Mac la mérite parce que ceux qui veulent un minuteur de méditation sur leur machine de travail profitent d’une vraie application de barre de menus ou d’une fenêtre épinglée dans un coin précis.

Les flux de travail multi-fenêtres ou multi-documents. Un éditeur de code avec panneaux fractionnés. Un éditeur photo avec des images de référence côte à côte. Un tableur. Aucun de ces cas ne survit sous sa forme aboutie sur iPad ou iPhone ; le Mac est la bonne plateforme.

L’interaction pilotée au clavier. Une application SwiftUI sur Mac qui ignore le clavier n’est une application Mac que de nom. Cmd+N pour créer, Cmd+W pour fermer, Tab pour parcourir le focus, les flèches pour la sélection. Le coût s’évalue par application : chaque cible Mac exige une surface clavier pensée jusqu’au bout.

Signaux défavorables au Mac :

L’application est un petit outil monotâche qui ne gagne rien à une fenêtre. Un minuteur matinal lancé une fois par jour pendant cinq minutes n’a pas besoin d’une cible Mac. L’utilisateur peut le lancer sur l’iPhone posé à côté du Mac.

Les applications dont l’UI pensée pour l’iPhone ne se transpose pas. Les applications photo. Les applications compagnons d’Apple Watch. Toutes celles dont le modèle de saisie est d’abord tactile et pour lesquelles l’équivalent clavier-souris serait pire que de toucher le téléphone.

L’équipe ne peut pas s’engager sur une maintenance Mac continue. Les sorties Mac sont scrutées autrement que les sorties iPhone. Cycles de mises à jour macOS, signature pour Gatekeeper, notarisation, examen App Store propre au Mac : chacun de ces points ajoute du travail de cycle de sortie que l’équipe doit prévoir. Si elle ne le prévoit pas, abandonnez la cible.

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

La Watch est la plateforme où « publiez-y aussi » est une consigne activement trompeuse. Son modèle d’exécution, détaillé dans L’environnement d’exécution watchOS est un contrat, pas une tâche d’arrière-plan, diffère profondément de celui d’iOS : le poignet retombe, le système suspend l’application, et seuls certains types de sessions (self-care, mindfulness, physical-therapy, alarm pour WKExtendedRuntimeSession, auxquels s’ajoutent workout-processing pour HKWorkoutSession et underwater-depth pour la plongée) continuent de s’exécuter après la suspension.⁴ Une cible Watch sans scénario d’exécution est cassée dès la deuxième utilisation.

Signaux favorables à la Watch :

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 (HKWorkoutSession avec le mode d’arrière-plan workout-processing). Réveils intelligents (alarm). Applications de kinésithérapie et de soin de soi (les types de session correspondants). Return sort sur Watch parce que la méditation correspond exactement à mindfulness ; l’application Watch garde le minuteur actif quand le poignet retombe, parce que le contrat d’exécution le permet.

L’utilisateur veut vraiment le poignet comme surface de saisie. Un affichage de fréquence cardiaque pendant l’effort. Un minuteur qu’on lance sans sortir son téléphone. Une complication qui livre une information d’un coup d’œil. Get Bananas sort sur Watch comme surface de pointage rapide, associée à l’iPhone qui fait référence ; une application d’entraînement comme Reps gagne sa cible Watch pour la même raison, parce qu’enregistrer une série au poignet va plus vite que d’extraire son téléphone de sa poche.

La valeur de l’application compagnon est réelle. Certaines applications Watch existent avant tout comme afficheurs de données pilotées par l’iPhone (un minuteur de recette, par exemple, où l’iPhone fait tourner le minuteur et la Watch montre le temps restant). Elles ne méritent leur place que si la synchronisation entre appareils est bâtie honnêtement (le sujet de Source unique de vérité : SwiftData + MCP + iCloud) et si la vue Watch fait un vrai travail au-delà du simple miroir.

Signaux défavorables à la Watch :

L’application n’a aucun type de session à revendiquer. Une application de lecture sur la Watch n’est une application Watch que de nom. On ne lit pas un livre sur un poignet ; le modèle d’exécution ne prolonge pas la session. Passez votre chemin.

L’équipe ne peut pas s’engager sur le débogage propre à watchOS. Le débogage sur Watch est d’une pénibilité rare : le comportement du simulateur s’écarte de celui de l’appareil réel de façons qui n’apparaissent que sur une vraie Apple Watch, poignet retombé. Sans matériel ni volonté de tester dessus, la cible Watch sort cassée.

Le modèle de données n’entre pas dans les enveloppes de synchronisation entre appareils. La synchronisation iPhone vers Watch passe généralement par WatchConnectivity pour l’état en direct et NSUbiquitousKeyValueStore pour le petit état persistant (Return utilise ce dernier pour synchroniser l’historique des sessions ; voir l’article sur la publication multi-plateformes). Ce stockage plafonne à 1 Mo toutes clés confondues, avec un maximum de 1 024 clés.⁵ Si l’état de session de l’application n’entre pas dans cette enveloppe, la cible Watch réclame une autre architecture de synchronisation, c’est-à-dire un investissement d’ingénierie bien réel.

Vision, c’est le modèle mental spatial

Le Vision Pro incite les applications à sortir sous forme de panneau plat flottant dans l’espace. Ce panneau est une fenêtre SwiftUI, et SwiftUI sur visionOS rend sa publication aussi simple qu’un clic. Le panneau, c’est un iPad en moins bien. La vraie valeur de la plateforme vient du modèle mental spatial, exploré dans RealityKit et le modèle mental spatial, où le contenu vit dans la pièce plutôt que dans le panneau.

Signaux favorables à Vision :

L’application propose du contenu 3D qui gagne à se trouver dans la pièce. Une sculpture virtuelle dont on peut faire le tour. Un mètre ruban qui se pose sur un vrai mur. Un coach sportif qui projette des repères de posture sur l’image miroir du corps de l’utilisateur. La plupart des applications du portfolio qui apparaissent sur visionOS le font via la compatibilité « Designed for iPad » plutôt que par une cible visionOS native ; cette compatibilité convient à l’utilisateur, mais elle ne fait pas pour autant une expérience native Vision. L’article sur le modèle mental spatial de RealityKit défend l’idée que mériter la plateforme demande plus que d’y tourner.

Le suivi des mains est le bon modèle de saisie. Pincer pour saisir, mettre à l’échelle à deux mains, dessiner en l’air. visionOS offre une possibilité de saisie qu’aucune autre plateforme n’a ; les applications qui gagnent leur place sur visionOS s’y appuient pleinement.

L’application exploite les surfaces propres au spatial (équivalents de l’écran verrouillé, espaces immersifs, ornements). Les outils de productivité qui se contentent de faire flotter leur UI iPhone sur Vision sont du bruit visible dès le premier jour d’usage du casque. Celles qui font revenir l’utilisateur sont celles qui exploitent la surface spatiale.

Signaux défavorables à Vision :

L’application a fondamentalement la forme d’un panneau et ne gagne rien à la profondeur. Une application de prise de notes, une messagerie, un utilitaire de réglages. visionOS les exécutera ; l’utilisateur n’a aucune raison de les préférer là plutôt que sur iPad. Passez votre chemin.

L’équipe de développement n’a aucun dispositif de test propre à visionOS. visionOS est la plateforme au parc installé le plus réduit et aux pratiques les plus fragiles ; tester une cible Vision sans appareil réel est d’une difficulté singulière, plus encore que dans le cas de watchOS.

Les enjeux de confidentialité et de présence dominent. Les applications qui exposent des données de santé. Les outils professionnels sensibles. Le casque visionOS se partage entre membres du foyer comme l’iPhone ne se partage pas ; une application qui affiche des informations privées y exige une posture différente de celle qu’elle tient 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 surbrillance avec la télécommande, appuie pour sélectionner, et ne voit jamais la moindre interaction tactile. SwiftUI sur tvOS le prend en charge via le modificateur .focusable(...), le property wrapper @FocusState et .focused(...) pour la liaison d’état, mais chaque application TV exige de concevoir le focus de zéro.⁶ Le modèle « toucher et faire défiler » de l’iPhone ne se transpose pas.

Signaux favorables à la TV :

L’application sert à consommer du contenu à distance de télévision. Vidéo en streaming (Apple TV+, Netflix). Diaporamas photo. Jeux familiaux pilotés à la télécommande. L’utilisateur est sur un canapé, l’écran est loin, la saisie est parcimonieuse : la TV est la bonne plateforme.

L’application a un usage « en retrait » que l’iPhone n’offre pas. Des vidéos d’entraînement que l’on suit en direct. Des applications de cuisine que l’on consulte devant les fourneaux. Des histoires du soir que l’on écoute en s’endormant. Aucun de ces cas n’est bien servi par un téléphone calé sur la table basse.

Le modèle d’interaction se prête à une navigation parcimonieuse, pilotée par le focus. Une liste d’éléments que l’utilisateur choisit un à un. Une grille d’options. Un flux de lecture linéaire. Tout ce qui va au-delà — gestes multi-touch, saisie de texte fine, glisser-déposer — ne fonctionne pas sur tvOS et signale que la cible n’est pas la bonne.

Signaux défavorables à la TV :

L’application exige de la saisie de texte. Saisir du texte à la télécommande est l’un des pires modèles de saisie de tout l’écosystème Apple. Si l’application demande davantage qu’un champ de recherche, abandonnez la TV.

La valeur de l’application suppose que l’utilisateur ait les mains libres pour autre chose. Le suivi d’activité physique. La surveillance de la santé. La collaboration en temps réel. La TV est un écran, pas un objet porté.

Le coût de maintenance est trop élevé au regard du parc installé. tvOS a un parc installé restreint face à iOS. Le coût de développement est réel (design du focus, tests distincts, examen App Store pour tvOS). Pour la plupart des applications, le calcul ne justifie pas la place. Une application de méditation ne gagne sa place sur Apple TV qu’avec un vrai mode « laisser à l’écran en faible luminosité pendant que je reste assis sur le canapé » que l’usage récompense vraiment ; sans ce mode, même une application dont le minuteur épouse parfaitement l’usage en retrait de la TV ne mérite pas la facture de maintenance.

La matrice en pratique

La matrice réelle de chaque application du portfolio :

La constante : chaque ligne est une coupe délibérée autant qu’un ajout délibéré. Return atteint six plateformes parce que chacune se justifie par un test de valeur d’usage précis ; les applications restées sur iPhone y restent parce que rien d’autre ne se justifiait. Même chaîne d’outils, produits différents, matrices différentes.

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

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

Un cœur partagé utilise #if os(iOS), #if os(macOS), #if os(watchOS) (et consorts) pour isoler les surfaces propres à chaque plateforme.⁷ La logique métier du domaine (modèles de données, règles métier, synchronisation) compile partout. L’UI propre à chaque plateforme vit derrière des conditionnelles évaluées à la compilation. Le @available(iOS 26.0, macOS 26.0, ...) de SwiftUI couvre les écarts de version d’OS ; les surfaces qui divergent réellement d’une plateforme à l’autre (une barre de menus Mac sans équivalent iPhone, une complication Watch sans équivalent iPad) obtiennent leurs propres fichiers, dans des groupes spécifiques à la cible, derrière des directives #if os(...).

La synchronisation entre appareils passe par un seul substrat, choisi par domaine. NSUbiquitousKeyValueStore pour le petit état de session partagé entre appareils (Return s’en sert pour l’état du minuteur entre appareils). Les fichiers JSON sur iCloud Drive pour les ponts entre processus (Get Bananas s’en sert avec son serveur MCP, sujet de Source unique de vérité). SwiftData pour l’état intra-processus. Panacher les substrats selon les domaines ne pose aucun problème ; en utiliser deux pour un même domaine, c’est le mode de défaillance qui produit la dérive.

Chaque plateforme a ses motifs de refus explicites, documentés application par application. « Nous ne sortirons pas sur TV si l’usage n’a pas de mode en retrait. » « Nous ne sortirons pas sur Vision sans que l’application utilise RealityKit plutôt qu’un panneau. » « Nous ne sortirons pas sur Watch sans type de session. » Ces refus sont des décisions de projet, consignées par application et appliquées avec constance, dans l’esprit de Ce que je refuse d’écrire.

Quand ajouter des plateformes est une erreur

Trois cas où la voie la plus facile est la mauvaise.

L’équipe ajoute une cible parce que la chaîne d’outils rend la chose facile. L’assistant « dupliquer la cible » de Xcode fait d’un ajout Mac ou visionOS une affaire de quatre clics. Ces quatre clics n’incluent ni revue de design, ni audit d’accessibilité, ni création des captures pour l’App Store, ni coordination des sorties, ni tests par plateforme. Les cibles sorties de l’assistant sans que ce travail les accompagne sont cassées dès le premier jour.

L’équipe traite le nombre de cibles comme un signe de statut. « Nous sortons sur cinq plateformes Apple » fait bel effet dans un tweet de lancement. Ce n’est pas le tweet qui tourne sur les appareils des utilisateurs, ce sont les applications. Une application sur deux plateformes qui excelle sur les deux est un meilleur produit qu’une application sur cinq plateformes tirée dans tous les sens.

L’équipe sous-estime la maintenance continue. Chaque plateforme Apple publie chaque année une mise à jour majeure de son système. Une application sur cinq plateformes, c’est cinq jeux de notes de version à absorber, cinq jeux de changements de comportement à tester, cinq jeux de métadonnées App Store à tenir à jour. Le coût se cumule ; les équipes qui sortent sur les cinq sans la capacité de les entretenir livrent des produits qui se dégradent lentement sur trois de ces plateformes.

Ce que cette approche implique pour les applications qui sortent sur iOS 26+

Trois enseignements.

1. Inclure une plateforme relève du produit avant de relever de l’ingénierie. La case à cocher de Xcode, c’est le versant ingénierie ; le test de valeur d’usage, c’est le versant produit. Sans réponse claire à la question « l’utilisateur tire-t-il un vrai bénéfice de l’application sur cette plateforme ? », la cible saute.

2. Chaque plateforme apporte ses obligations propres : classe de taille (iPad), fenêtre, menus et clavier (Mac), contrat d’exécution (Watch), modèle spatial (Vision), moteur de focus (TV). Négliger 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 vrais utilisateurs de la plateforme remarquent.

3. La plupart des applications devraient sortir sur une à trois plateformes. Quatre à six reste rare et ne se mérite que si chaque plateforme apporte réellement de la valeur d’usage. Les applications du portfolio s’étalent de une à six ; le cas des six plateformes (Return) est l’exception ultime, et chaque plateforme supplémentaire y a fait l’objet d’une décision produit distincte, avec son propre test de valeur d’usage.

L’ensemble de la série Écosystème Apple : les App Intents typés pour la surface Apple Intelligence ; les serveurs MCP pour la surface agent ; la question de l’aiguillage entre les deux ; Foundation Models pour les fonctionnalités LLM embarquées dans l’application ; la distinction entre LLM d’exécution et LLM d’outillage ; la synthèse des trois surfaces ; le motif de la source unique de vérité ; Deux serveurs MCP pour l’intégration Xcode ; les points d’accroche pour le développement Apple ; les Live Activities ; le contrat de l’environnement d’exécution watchOS ; les rouages internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les motifs Liquid Glass ; la publication multi-plateformes ; ce que je refuse d’écrire. Le hub se trouve sur la page de la série Écosystème Apple. Pour un contexte plus large sur l’iOS avec des agents IA, consultez le guide Développement iOS avec des agents.

FAQ

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

Demandez-vous si l’utilisateur tire un vrai bénéfice de l’application sur cette plateforme, et non si la chaîne d’outils le permet. La case à cocher de Xcode, c’est le versant technique ; le test de valeur d’usage, c’est le versant produit. Chaque plateforme apporte ses obligations propres (classe de taille, fenêtre et menus, contrat d’exécution, modèle spatial, moteur de focus) et son coût de maintenance propre. Si la réponse est « ça fonctionne là aussi », la bonne décision consiste généralement à abandonner la cible.

Faut-il sortir sur les six plateformes Apple ?

En général, non. La plupart des applications se portent mieux sur une à trois plateformes. Quatre à six reste rare et ne se mérite que si chaque plateforme apporte réellement de la valeur d’usage (Return atteint les six parce que la session mindfulness convient à la Watch, que le minuteur convient à l’iPad et au Mac comme compagnons de bureau, que visionOS convient à un mode immersif et que la TV convient à un usage en retrait sur le canapé). Pour la plupart des applications, le modèle d’interaction de tvOS et les exigences spatiales de visionOS ne conviennent pas, et la bonne décision consiste à abandonner ces cibles.

Quelle est l’erreur la plus courante en ajoutant une cible iPad ?

Traiter l’iPad comme « un iPhone avec plus de pixels ». Une application iPhone en SwiftUI déposée telle quelle sur iPad, sans adaptation aux classes de taille, produit une UI en colonne unique étirée que les utilisateurs d’iPad jugent immédiatement bâclée. La bonne approche consiste à lire @Environment(\.horizontalSizeClass), à adapter la disposition à la toile plus large (deux colonnes via NavigationSplitView quand cela a du sens, sinon une liste unique avec des espacements confortables), et à envisager l’Apple Pencil et les gestes multi-doigts comme une valeur propre à l’iPad.

Pourquoi l’Apple Watch diffère-t-elle autant 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 certains types de sessions (self-care, mindfulness, physical-therapy, alarm pour WKExtendedRuntimeSession, auxquels s’ajoute workout-processing pour HKWorkoutSession) continuent de s’exécuter après la suspension.⁴ Les applications sans type de session net produisent des expériences cassées dès la deuxième utilisation. L’article sur l’environnement d’exécution watchOS du portfolio détaille ce contrat.

Comment fonctionne la synchronisation entre appareils dans cette matrice de plateformes ?

Trois substrats : NSUbiquitousKeyValueStore pour le petit état clé-valeur (paramètres, dernier onglet sélectionné, état du minuteur entre appareils),⁵ les fichiers iCloud Drive pour les ponts entre processus (le modèle Get Bananas + serveur MCP), SwiftData pour l’état intra-processus. Choisissez un seul substrat par domaine ; en mélanger deux pour un même domaine produit de la dérive. L’article sur la source unique de vérité du portfolio parcourt la matrice de décision.

Références