La matriz de plataformas de Apple: qué objetivos merecen qué app

Apple ofrece seis plataformas de cómputo de consumo a las que un desarrollador puede apuntar con una sola base de código en Swift: iPhone, iPad, Mac, Watch, Vision y TV. SwiftUI junto con la cadena de herramientas de iOS 26 hacen que añadir cualquiera de ellas sea una operación de marcar una casilla en Xcode. Marcar la casilla es la trampa. Cada objetivo adicional es una obligación, no una función: cada uno amplía la superficie de diseño, pruebas, accesibilidad, modelo de tiempo de ejecución y mantenimiento continuo. El número correcto de objetivos para una app es menor que el que el framework permite.

Las apps del clúster ejecutan combinaciones distintas. Return se distribuye en seis plataformas (iPhone, iPad, Mac, Watch, Vision, TV). Get Bananas en cuatro (iPhone, iPad, Mac, Watch). Reps y Water están en preventa con varios objetivos compilados que las apps reducirán antes del lanzamiento. Ace Citizenship y Tappy Color se distribuyen cada una solo en iPhone. Mismo desarrollador, misma cadena de herramientas, seis decisiones de plataforma distintas. Las decisiones siguen reglas; las reglas merecen un mapa compartido.

Cada plataforma se gana su inclusión a través del valor específico para el usuario que añade genuinamente, no porque “compila”. La matriz que sobrevive al lanzamiento es lo que queda después de que cada objetivo se justifique a sí mismo o se elimine.

TL;DR

• Seis plataformas, seis obligaciones distintas: iPhone (predeterminada), iPad (adaptación de clase de tamaño), Mac (modismos de ventana/menú/teclado), Watch (contrato de tiempo de ejecución), Vision (modelo mental espacial), TV (motor de foco).
• Cada objetivo adicional añade superficie de pruebas, trabajo de diseño, accesibilidad y coordinación de lanzamientos continua. La casilla “añadir plataforma” de Xcode oculta el costo.
• Las pruebas correctas son pruebas de valor para el usuario, no pruebas técnicas: ¿el usuario se beneficia genuinamente de ejecutar esta app en esa plataforma? Si la respuesta es “también funciona allí”, elimínala.
• La mayoría de las apps deberían distribuirse en una a tres plataformas. De cuatro a seis es poco común y solo se gana el lugar cuando cada plataforma añade genuinamente valor para el usuario que las otras no pueden ofrecer.

El iPhone es la plataforma predeterminada

Toda app de Apple comienza en iPhone o no comienza. El iPhone tiene la mayor base instalada, la superficie de accesibilidad más refinada, la ruta de distribución más sólida a través del App Store y el lenguaje de diseño canónico de SwiftUI. Cada app del clúster que he distribuido se ejecuta en iPhone. Ninguna se ha lanzado con un diseño que no fuera iPhone-first.

La prueba de valor para el usuario en iPhone: ¿abriría un usuario esta app en un teléfono? Para casi cada categoría de consumo, sí. Las apps de salud y fitness viven en el teléfono. Las herramientas de productividad viven en el teléfono. Los juegos viven en el teléfono. Las herramientas de comunicación viven en el teléfono. La predeterminada es iPhone porque el teléfono es donde está el usuario.

La excepción son las herramientas para desarrolladores (Xcode, Terminal) y las herramientas creativas que necesitan espacio (Final Cut, Logic). Esas comienzan en Mac y se ganan una compañera en iPhone solo si hay un traspaso claro (frecuencia cardíaca en Watch durante un entrenamiento del que el teléfono muestra el gráfico, Continuidad de Cámara). Para el software de consumo, iPhone-first no está en debate.

El iPad no es un iPhone con más píxeles

Los binarios universales y las clases de tamaño hicieron posible distribuir una app de iPhone en UIKit en el iPad con puntos de quiebre por clase de tamaño. SwiftUI hizo lo mismo más fácil mediante @Environment(\.horizontalSizeClass) y NavigationSplitView.¹ El costo técnico de “distribuir al iPad” es bajo. El costo de producto es la cuestión de si la app realmente merece el lienzo más grande del iPad.

Tres señales de iPad-sí:

La app lee o crea contenido para el que el usuario quiere más pantalla. Apps de lectura (Books, noticias, cómics, documentos largos). Apps de dibujo/pintura (Procreate). Toma de notas con Apple Pencil (Notability, GoodNotes). Get Bananas se gana su lugar en iPad porque una lista de compras con secciones es más útil en un lienzo más amplio que en uno estrecho; el diseño para iPad adapta la misma lista de secciones al área más grande.

La app tiene valor de traspaso con iPhone o Mac. Apple Notes, Recordatorios y Mail se ganan todos sus lugares en iPad porque el usuario espera continuidad. El historial de meditación de Return en iPad se gana su lugar por la misma razón: el usuario empieza en iPhone, mira el iPad mientras corre el temporizador.

La app tiene una capacidad de entrada nativa del iPad. Apple Pencil para bocetos/escritura a mano. Gestos multitáctiles en una superficie más grande. Flujos de trabajo de Stage Manager que se benefician de un diseño basado en mosaicos. Si la capacidad no existe en el iPhone, el objetivo iPad se gana su lugar.

Las señales de iPad-no:

Contenido de una sola columna sin valor extra a escala. La vista principal de un temporizador de meditación es una cuenta y un botón. El iPad hace ambos más grandes; eso no es una función. Un rastreador rápido de hidratación es lo mismo; la pantalla más amplia no cambia lo que el usuario hace durante una sesión de registro de cinco segundos.

Apps que dependen de hardware específico del iPhone (Dynamic Island, ciertos formatos de cámara solo en Pro, la ergonomía de agarre con forma de iPhone). Esas suposiciones de diseño se traducen mal; o reconstruyes el diseño o saltas el objetivo.

Apps donde el usuario ya tiene un mejor destino en Mac. Un editor de código en iPad sin soporte de teclado es una versión mutilada de la app de Mac. Salta el objetivo a menos que el diseño se gane su lugar en el modelo de entrada específico del iPad.

El Mac es ventana, barra de menús e idiomas de teclado

Una app SwiftUI distribuida al Mac mediante el objetivo nativo macOS o “Diseñada para iPad” (Mac Catalyst es la ruta equivalente a UIKit que lleva el código UIKit al Mac) se ejecuta en macOS sin producir una verdadera app para Mac.² Una verdadera app para Mac respeta la semántica de redimensionamiento de ventanas, la barra de menús (el modificador de Scene .commands { } con los constructores CommandMenu y CommandGroup en SwiftUI), los atajos de teclado, el selector de archivos de macOS, arrastrar y soltar con el Finder, y compartir nativo de Mac.³ Saltarse cualquiera de estos produce una experiencia de app-de-iPad-en-una-ventana que los usuarios de Mac notan y juzgan.

Señales de Mac-sí:

El usuario pasa tiempo en la app y se beneficiaría de que sea una verdadera ventana de escritorio. Get Bananas en Mac se gana su lugar porque los usuarios que editan una lista de compras larga en un escritorio se benefician de una verdadera ventana con navegación por teclado. Return en Mac se lo gana porque los usuarios que quieren un temporizador de meditación corriendo en su máquina de trabajo se benefician de una verdadera app en la barra de menús o de una ventana fijada en una esquina específica.

Flujos de trabajo multi-ventana o multi-documento. Un editor de código con paneles divididos. Un editor de fotos con imágenes de referencia lado a lado. Una hoja de cálculo. Ninguno sobrevive en iPad o iPhone en su forma adecuada; Mac es la plataforma correcta.

Interacción dirigida por teclado. Una app SwiftUI en Mac que ignora el teclado es una app para Mac solo de nombre. Cmd+N para nuevo, Cmd+W para cerrar, Tab para recorrer el foco, flechas para selección. El costo es por app: cada objetivo Mac necesita una superficie de teclado meditada.

Señales de Mac-no:

La app es una herramienta pequeña, de una sola tarea, que no se beneficia de una ventana. Un temporizador matutino que el usuario corre una vez al día durante cinco minutos no necesita un objetivo Mac. El usuario puede correrlo en el iPhone junto al Mac.

Apps donde la UI con forma de iPhone fundamentalmente no se traduce. Apps de cámara. Apps compañeras de Apple Watch. Apps donde el modelo de entrada es táctil-primero y el equivalente con teclado/ratón sería peor que tocar el teléfono.

El equipo no puede comprometerse con el mantenimiento continuo específico de Mac. Los lanzamientos en Mac se escrutan de manera diferente a los del iPhone. Los ciclos de actualización de macOS, la firma para Gatekeeper, la notarización, la revisión del App Store específica para Mac, cada uno de estos añade trabajo de ciclo de lanzamiento que el equipo tiene que presupuestar. Si el equipo no lo presupuestará, salta el objetivo.

Apple Watch es un contrato de tiempo de ejecución

El Watch es la plataforma donde “distribuye en él” es una instrucción activamente engañosa. El modelo de tiempo de ejecución del Watch, cubierto en detalle en El tiempo de ejecución de watchOS es un contrato, no una tarea en segundo plano, es fundamentalmente diferente del de iOS: la muñeca cae, el sistema suspende la app, y solo tipos específicos de sesión (self-care, mindfulness, physical-therapy, alarm para WKExtendedRuntimeSession, más workout-processing para HKWorkoutSession y underwater-depth para sesiones de buceo) pueden correr después de la suspensión.⁴ Un objetivo Watch sin una historia de tiempo de ejecución está roto en el segundo uso.

Señales de Watch-sí:

La app tiene una forma de sesión que el modelo de tiempo de ejecución de watchOS reconoce. Temporizadores de meditación (sesión de mindfulness). Apps de fitness (HKWorkoutSession con el modo de fondo workout-processing). Alarmas inteligentes (alarm). Apps de fisioterapia y autocuidado (los tipos de sesión correspondientes). Return se distribuye en Watch porque la meditación se mapea limpiamente a mindfulness; la app del Watch mantiene el temporizador corriendo durante la caída de la muñeca porque el contrato de tiempo de ejecución lo permite.

El usuario realmente quiere la muñeca como superficie de entrada. Un visor de frecuencia cardíaca durante el ejercicio. Un temporizador que el usuario inicia sin sacar el teléfono. Una complicación que muestra información de un vistazo. Get Bananas se distribuye en Watch como una superficie rápida de revisión de listas emparejada con la tienda canónica del iPhone; una app de entrenamiento como Reps se gana su objetivo Watch por la misma razón, porque registrar una serie en la muñeca es más rápido que pescar el teléfono del bolsillo.

El valor de app-compañera es real. Algunas apps Watch existen principalmente como pantallas para datos manejados por iPhone (por ejemplo, un temporizador de receta donde el iPhone corre el temporizador y el Watch muestra la cuenta restante). Esas se ganan su lugar solo si la sincronización entre dispositivos está construida con honestidad (cubierto en Fuente única de verdad: SwiftData + MCP + iCloud) y la vista del Watch hace trabajo real más allá de reflejar.

Señales de Watch-no:

La app no tiene un tipo de sesión que pueda reclamar. Una app de lectura en el Watch es una app Watch solo de nombre. El usuario no puede leer un libro en una muñeca; el modelo de tiempo de ejecución no extiende la sesión. Salta.

El equipo no puede comprometerse con la depuración específica de watchOS. La depuración del Watch es singularmente dolorosa: el comportamiento del simulador diverge del comportamiento del dispositivo real de maneras que solo aparecen en un Apple Watch real bajo condiciones de caída de muñeca. Si el equipo no tiene hardware y disposición para probar en él, el objetivo Watch sale roto.

El modelo de datos no encaja en los sobres de sincronización entre dispositivos. La sincronización entre dispositivos del iPhone al Watch suele ser WatchConnectivity para estado en vivo y NSUbiquitousKeyValueStore para pequeño estado persistido (Return usa este último para sincronización de historial de sesiones; cubierto en el post de distribución multiplataforma). El almacén tiene un tope de 1 MB en todas las claves con un máximo de 1024 claves.⁵ Si el estado de sesión de la app no cabe en ese sobre, el objetivo Watch necesita una arquitectura de sincronización diferente, lo cual es una inversión real de ingeniería.

Vision es el modelo mental espacial

Vision Pro tienta a las apps a distribuirse como un panel plano flotando en un espacio 3D. Ese panel es una ventana SwiftUI, y SwiftUI en visionOS hace que distribuirla sea una operación de un clic. El panel es un iPad peor. El verdadero valor de la plataforma viene del modelo mental espacial, cubierto en RealityKit y el modelo mental espacial, donde el contenido vive en la habitación en lugar de en el panel.

Señales de Vision-sí:

La app tiene contenido 3D que se beneficia de estar en la habitación. Una escultura virtual alrededor de la cual el usuario puede caminar. Una cinta métrica que se posa sobre una pared real. Un entrenador de ejercicios que proyecta señales de forma sobre una imagen espejo del cuerpo del usuario. La mayoría de las apps del clúster que aparecen en visionOS lo hacen mediante compatibilidad “Diseñada para iPad” en lugar de un objetivo nativo visionOS; esa compatibilidad está bien para el usuario, pero no convierte a la app en una experiencia nativa de Vision. El post sobre el modelo mental espacial de RealityKit argumenta que ganarse la plataforma significa más que ejecutarse en ella.

El seguimiento de manos es el modelo de entrada correcto. Pellizcar para agarrar, escalado a dos manos, dibujar en el aire. visionOS da una capacidad de entrada que ninguna otra plataforma tiene; las apps que se ganan su lugar en visionOS se inclinan hacia ella.

La app maneja superficies específicas espaciales (equivalentes a pantalla de bloqueo, espacios inmersivos, ornamentos). Las apps de productividad que solo flotan su UI de iPhone en Vision son ruido visible en el primer día del usuario con el dispositivo. Las apps que hacen que el usuario siga regresando son las que explotan la superficie espacial.

Señales de Vision-no:

La app es fundamentalmente con forma de panel y no se beneficia en absoluto de la profundidad. Una app de notas, una app de chat, una utilidad de configuración. visionOS las ejecutará; el usuario no tiene razón para usarlas en visionOS en lugar del iPad. Salta.

El equipo de desarrollo no tiene pruebas específicas de visionOS. visionOS es la plataforma con la base instalada más pequeña y los patrones más frágiles; probar un objetivo Vision sin un dispositivo real es singularmente difícil, más que el caso de watchOS.

Las preocupaciones de privacidad y presencia dominan. Apps de divulgación de salud. Herramientas sensibles del lugar de trabajo. El dispositivo visionOS se comparte entre miembros del hogar de una manera que el iPhone no; una app que muestra información privada necesita una postura diferente allí que en el iPhone.

Apple TV es el motor de foco

Las apps para TV son manejadas por el motor de foco del Siri Remote: el usuario mueve un resaltado de foco con el control remoto, presiona para seleccionar y nunca ve una interacción táctil. SwiftUI en tvOS soporta esto a través del modificador .focusable(...), el property wrapper @FocusState y .focused(...) para el enlace de estado, pero cada app de TV necesita un diseño de foco desde cero.⁶ El modelo de tocar-y-desplazarse del iPhone no se traduce.

Señales de TV-sí:

La app es para consumo de contenido a distancia de ver TV. Streaming de video (Apple TV+, Netflix). Presentaciones de fotos. Apps de juegos familiares que el usuario controla con el control remoto. El usuario está en un sofá, la pantalla está lejos, la entrada es escasa, TV es la plataforma correcta.

La app tiene un caso de uso de “recostado” que el iPhone no tiene. Videos de ejercicio que el usuario sigue. Apps de cocina que el usuario consulta mientras está en la estufa. Cuentos para dormir que el usuario escucha mientras duerme. A ninguno se le sirve bien con un teléfono apoyado en la mesa de café.

El modelo de interacción encaja con la navegación escasa, dirigida por foco. Una lista de elementos que el usuario elige uno a la vez. Una cuadrícula de opciones. Un flujo lineal de reproducción. Cualquier cosa más compleja que eso, gestos multitáctiles, entrada de texto detallada, arrastrar y soltar, no funciona en tvOS y significa que el objetivo es incorrecto.

Señales de TV-no:

La app necesita entrada de texto. La entrada de texto en TV mediante el control remoto es uno de los peores modelos de entrada en cualquier plataforma de Apple. Si la app necesita algo más que una caja de búsqueda, salta TV.

El valor de la app depende de que las manos del usuario estén libres para otras tareas. Seguimiento de fitness. Monitoreo de salud. Colaboración en tiempo real. El TV es una pantalla, no un dispositivo vestible.

El costo de mantenimiento es demasiado alto para la base instalada. tvOS tiene una base instalada pequeña en relación con iOS. El costo de desarrollo es real (diseño de foco, pruebas separadas, revisión del App Store para tvOS). Para la mayoría de las apps, la matemática no justifica el lugar. Una app de meditación se gana un lugar en Apple TV solo con un verdadero modo “déjala en la pantalla con brillo bajo mientras estoy sentado en el sofá” que el caso de uso realmente recompense; sin ese modo, incluso una app cuyo temporizador se mapea limpiamente al patrón de recostarse del TV no merece la factura de mantenimiento.

La matriz en la práctica

La matriz real de cada app del clúster:

El patrón: cada fila es un recorte deliberado tanto como una adición deliberada. Return alcanza seis plataformas porque cada una se justifica mediante una prueba específica de valor para el usuario; las apps solo de iPhone se quedan ahí porque nada más lo es. Misma cadena de herramientas, productos diferentes, matrices diferentes.

Tres decisiones de arquitectura que hacen sostenible la matriz

Tres patrones que evitan que las apps multiplataforma colapsen bajo su propio peso:

Un núcleo compartido usa #if os(iOS), #if os(macOS), #if os(watchOS) (y compañía) para limitar superficies específicas de plataforma.⁷ La lógica de dominio principal (modelos de datos, reglas de negocio, sincronización) compila en todas partes. La UI específica de plataforma vive detrás de condicionales en tiempo de compilación. @available(iOS 26.0, macOS 26.0, ...) de SwiftUI cubre las diferencias de versión del sistema operativo; las superficies que genuinamente divergen entre plataformas (una barra de menús de Mac que no tiene equivalente en iPhone, una complicación de Watch que no tiene equivalente en iPad) obtienen sus propios archivos en grupos específicos del objetivo detrás de las puertas #if os(...).

La sincronización entre dispositivos pasa por un único sustrato, elegido por dominio. NSUbiquitousKeyValueStore para pequeño estado de nivel de sesión entre dispositivos (Return usa esto para el estado del temporizador entre dispositivos). Archivos de iCloud Drive JSON para puentes entre procesos (Get Bananas usa esto con su servidor MCP, cubierto en Fuente única de verdad). SwiftData para estado en proceso. Mezclar los sustratos por dominio está bien; usar dos sustratos para el mismo dominio es el modo de falla que produce desviación.

Cada plataforma tiene patrones explícitos de rechazo documentados por app. “No distribuiremos a TV a menos que el caso de uso tenga un modo recostado.” “No distribuiremos a Vision a menos que la app use RealityKit, no un panel.” “No distribuiremos a Watch sin un tipo de sesión.” Los rechazos son decisiones de proyecto capturadas por app y aplicadas consistentemente, en el espíritu de Sobre lo que me niego a escribir.

Cuándo añadir plataformas es incorrecto

Tres casos donde el camino más fácil es el incorrecto.

El equipo añade un objetivo porque la cadena de herramientas lo hace fácil. El asistente “duplicar objetivo” de Xcode hace que añadir un objetivo Mac o visionOS sea una operación de cuatro clics. Los cuatro clics no incluyen revisión de diseño, auditoría de accesibilidad, creación de capturas de pantalla del App Store, coordinación continua de lanzamientos o pruebas por plataforma. Los objetivos distribuidos desde el asistente sin ese trabajo distribuyéndose con ellos están rotos desde el primer día.

El equipo trata el conteo de objetivos como una señal de estatus. “Distribuimos en cinco plataformas Apple” suena impresionante en un tweet de lanzamiento. El tweet de lanzamiento no se ejecuta en los dispositivos del usuario; las apps sí. Una app de dos plataformas que clava ambas es un mejor producto que una app de cinco plataformas que está estirada.

El equipo subestima el mantenimiento continuo. Cada plataforma de Apple lanza actualizaciones mayores del SO anualmente. Una app de cinco plataformas tiene cinco conjuntos de notas de lanzamiento a los que reaccionar, cinco conjuntos de cambios de comportamiento que probar, cinco conjuntos de metadatos del App Store que mantener actualizados. El costo se acumula; los equipos que distribuyen a las cinco sin el ancho de banda para mantenerlas producen productos en lenta decadencia en tres de esas plataformas.

Lo que este patrón significa para apps que se distribuyen en iOS 26+

Tres conclusiones.

1. La inclusión de plataforma es una decisión de producto antes que de ingeniería. La casilla de Xcode es el lado de ingeniería; la prueba de valor para el usuario es el lado de producto. Sin una respuesta clara a “¿el usuario se beneficia genuinamente de ejecutar esta app en esa plataforma?”, el objetivo se elimina.

2. Cada plataforma trae obligaciones específicas: clase de tamaño (iPad), ventana/menú/teclado (Mac), contrato de tiempo de ejecución (Watch), modelo espacial (Vision), motor de foco (TV). Saltarse las obligaciones produce una app-de-iPad-en-Mac, una app-de-teléfono-en-Vision, una app-de-iPhone-en-Watch, todos fracasos visibles que los usuarios reales de la plataforma notan.

3. La mayoría de las apps deberían distribuirse en una a tres plataformas. De cuatro a seis es poco común y solo se gana cuando cada plataforma añade genuinamente valor para el usuario. Las apps del clúster abarcan de una a seis; el caso de seis plataformas (Return) es el extremo raro, y cada plataforma adicional allí fue una decisión de producto separada con su propia prueba de valor para el usuario.

El clúster completo del Ecosistema Apple: App Intents tipados para la superficie de Apple Intelligence; servidores MCP para la superficie del agente; la pregunta de enrutamiento entre ellos; Foundation Models para funciones LLM en el dispositivo dentro de la app; la distinción tiempo de ejecución vs herramientas LLM; la síntesis de las tres superficies; el patrón de fuente única de verdad; Dos servidores MCP para la integración con Xcode; hooks para el desarrollo en Apple; Live Activities; el contrato de tiempo de ejecución de watchOS; internos de SwiftUI; el modelo mental espacial de RealityKit; disciplina de esquema de SwiftData; patrones de Liquid Glass; distribución multiplataforma; sobre lo que me niego a escribir. El hub está en Serie del Ecosistema Apple. Para un contexto más amplio sobre iOS-con-agentes-de-IA, consulta la guía de Desarrollo de Agentes en iOS.

FAQ

¿Cómo decido si añadir un objetivo de plataforma Apple?

Pregúntate si el usuario se beneficia genuinamente de ejecutar la app en esa plataforma, no si la cadena de herramientas lo permite. La casilla de Xcode es el lado técnico; la prueba de valor para el usuario es el lado de producto. Cada plataforma trae obligaciones específicas (clase de tamaño, ventana/menú, contrato de tiempo de ejecución, modelo espacial, motor de foco) y costos de mantenimiento específicos. Si la respuesta es “también funciona allí”, la decisión correcta suele ser saltarse el objetivo.

¿Debería distribuir en las seis plataformas Apple?

Generalmente no. La mayoría de las apps se benefician de una a tres plataformas. De cuatro a seis es poco común y solo se gana cuando cada plataforma añade genuinamente valor para el usuario (Return alcanza las seis porque la sesión de mindfulness encaja con Watch, el temporizador encaja con iPad y Mac como compañeras de escritorio, visionOS encaja con un modo inmersivo, y TV encaja con un caso de uso recostado en sofá). Para la mayoría de las apps, el modelo de interacción de tvOS y los requisitos espaciales de visionOS no encajan, y la decisión correcta es saltarse esos objetivos.

¿Cuál es el error más común al añadir un objetivo iPad?

Tratar el iPad como “un iPhone con más píxeles.” Una app SwiftUI de iPhone soltada en el iPad sin adaptación de clase de tamaño produce una UI de una sola columna estirada que los usuarios de iPad inmediatamente juzgan como medio esfuerzo. El patrón correcto es leer @Environment(\.horizontalSizeClass), adaptar el diseño al lienzo más grande (dos columnas donde tenga sentido mediante NavigationSplitView, de lo contrario una sola lista con espaciado cómodo) y considerar el Apple Pencil y las capacidades multitáctiles como valor específico del iPad.

¿Por qué el Apple Watch es tan diferente de las otras plataformas?

watchOS no tiene el modelo de ejecución en segundo plano de iOS. La muñeca cae, el sistema suspende la app, y solo tipos específicos de sesión (self-care, mindfulness, physical-therapy, alarm para WKExtendedRuntimeSession, más workout-processing para HKWorkoutSession) pueden correr después de la suspensión.⁴ Las apps sin un tipo de sesión limpio producen experiencias rotas-en-segundo-uso. El post sobre el tiempo de ejecución de watchOS del clúster cubre el contrato en detalle.

¿Cómo funciona la sincronización entre dispositivos a través de la matriz de plataformas?

Tres sustratos: NSUbiquitousKeyValueStore para pequeño estado clave-valor (configuración, última pestaña seleccionada, estado del temporizador entre dispositivos),⁵ archivos de iCloud Drive para puentes entre procesos (el patrón Get Bananas + servidor MCP), SwiftData para estado en proceso. Elige un sustrato por dominio; mezclar dos para el mismo dominio produce desviación. El post sobre fuente única de verdad del clúster recorre la matriz de decisión.

Referencias