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

Apple lanza 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 extiende la superficie de diseño, pruebas, accesibilidad, modelo 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 cluster ejecutan mezclas distintas. Return se publica en seis plataformas (iPhone, iPad, Mac, Watch, Vision, TV). Get Bananas se publica 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 publican cada una solo en iPhone. El mismo desarrollador, la misma cadena de herramientas, seis decisiones de plataforma distintas. Las decisiones siguen reglas; las reglas merecen un mapa compartido.

El artículo nombra las reglas. Cada plataforma se gana su inclusión a través de un valor específico para el usuario que la plataforma realmente aporta, no porque “compila”. La matriz que sobrevive al lanzamiento es la que queda después de que cada objetivo se justifica a sí mismo o se elimina.

TL;DR

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

El iPhone es el predeterminado

Toda app de Apple comienza en iPhone o no comienza. 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 cluster que he publicado se ejecuta en iPhone. Ninguna ha lanzado un diseño que no priorice el iPhone.

La prueba de valor para el usuario en iPhone: ¿abriría un usuario esta app en un teléfono? Para casi toda 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. El predeterminado es iPhone porque el teléfono es donde está el usuario.

La excepción son las herramientas de desarrollo (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 del Watch durante un entrenamiento que el teléfono muestra en la gráfica, Continuidad de la Cámara). Para el software de consumo, iPhone primero no es un debate.

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

Catalyst hizo posible publicar una app UIKit de iPhone en 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 “publicar en iPad” es bajo. El costo de producto es la pregunta de si la app realmente merece el lienzo más grande del iPad.

Tres señales de “sí al iPad”:

La app lee o crea contenido para el que el usuario quiere más pantalla. Apps de lectura (libros, noticias, cómics, documentos largos). Apps de dibujo/pintura (Procreate). Toma de notas con el 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 amplio que en uno estrecho; el diseño para iPad adapta la misma lista por secciones al área más grande.

La app tiene valor de traspaso con iPhone o Mac. Apple Notes, Recordatorios y Mail se ganan su lugar 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 y mira de reojo el iPad mientras corre el temporizador.

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

Las señales de “no al iPad”:

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

Apps que dependen de hardware específico del iPhone (Pantalla Bloqueada, Dynamic Island, ProMotion en configuraciones específicas exclusivas del iPhone, ciertos formatos de cámara). Esos supuestos de diseño se trasladan mal; o se rediseña la app o se omite 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. Omite 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ú y modismos de teclado

Una app SwiftUI publicada en Mac vía Mac Catalyst o “Diseñada para iPad” se ejecuta en macOS sin producir una verdadera app de Mac. Una verdadera app de Mac respeta la semántica de redimensionamiento de ventanas, la barra de menú (Commands(content:) en SwiftUI), los atajos de teclado, el selector de archivos de macOS, arrastrar y soltar con el Finder, y el sistema de compartir nativo de Mac. Omitir cualquiera de esos produce una experiencia de app-de-iPad-en-una-ventana que los usuarios de Mac notan y juzgan.

Señales de “sí al Mac”:

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 ventana real 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 de barra de menú o una ventana fijada en una esquina específica.

Flujos de trabajo de múltiples ventanas o documentos. 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 de estos sobrevive en iPad o iPhone en su forma adecuada; el Mac es la plataforma correcta.

Interacción guiada por teclado. Una app SwiftUI en Mac que ignora el teclado es una app de 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 de Mac necesita una superficie de teclado bien pensada.

Señales de “no al Mac”:

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

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

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

El Apple Watch es un contrato de ejecución

El Watch es la plataforma donde “publicar en él” es una instrucción activamente engañosa. El modelo de ejecución del Watch, cubierto en detalle en El runtime de watchOS es un contrato, no una tarea en segundo plano, es fundamentalmente distinto al de iOS: la muñeca cae, el sistema suspende la app, y solo tipos específicos de sesión (mindfulness, workout-processing, alarm, etc.) pueden ejecutarse después de la suspensión. Un objetivo de Watch sin una historia de runtime está roto en el segundo uso.

Señales de “sí al Watch”:

La app tiene una forma de sesión que el modelo de runtime de watchOS reconoce. Temporizadores de meditación (sesión de mindfulness). Apps de fitness (workout-processing). Despertadores (alarm). Navegación (el tipo de sesión de navegación). Return se publica en Watch porque la meditación se mapea limpiamente a mindfulness; la app de Watch mantiene el temporizador corriendo a través de la caída de muñeca porque el contrato de runtime 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 publica en Watch como una superficie rápida de marcado de listas emparejada con la tienda canónica del iPhone; una app de entrenamiento como Reps se gana su objetivo de 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 como app complementaria es real. Algunas apps de Watch existen principalmente como pantallas para datos guiados por el iPhone (por ejemplo, un temporizador de receta donde el iPhone ejecuta el temporizador y el Watch muestra el conteo restante). Esas se ganan su lugar solo si la sincronización entre dispositivos está construida honestamente (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 “no al Watch”:

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

El equipo no puede comprometerse a la depuración específica de watchOS. La depuración del Watch es excepcionalmente dolorosa: el comportamiento del simulador diverge del comportamiento del dispositivo real de maneras que solo afloran 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 de Watch se publica roto.

El modelo de datos no cabe en un sobre de sincronización entre dispositivos de 1MB. La sincronización entre dispositivos de iPhone a Watch usualmente pasa por NSUbiquitousKeyValueStore (cubierto en el artículo sobre publicación multiplataforma). El almacén tiene 1MB total + 1MB por valor + 1024 claves. Si el estado de sesión de la app no cabe en ese sobre, el objetivo de Watch necesita una arquitectura de sincronización distinta, lo cual es una inversión de ingeniería real.

Vision es el modelo mental espacial

El Vision Pro tienta a las apps a publicarse como un panel plano flotando en el espacio 3D. Ese panel es una ventana de SwiftUI, y SwiftUI en visionOS hace que publicarlo 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 “sí a Vision”:

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 coach de entrenamiento que proyecta señales de forma sobre una imagen espejo del cuerpo del usuario. La mayoría de las apps del cluster que aparecen en visionOS lo hacen vía compatibilidad con “Diseñada para iPad” en lugar de un objetivo nativo de visionOS; esa compatibilidad está bien para el usuario pero no convierte a la app en una experiencia nativa de Vision. El artículo 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, escalar a dos manos, dibujar en el aire. visionOS ofrece una posibilidad de entrada que ninguna otra plataforma tiene; las apps que se ganan su lugar en visionOS se apoyan en ello.

La app maneja superficies específicas espaciales (equivalentes a Pantalla Bloqueada, 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 regrese son las que explotan la superficie espacial.

Señales de “no a Vision”:

La app tiene fundamentalmente forma de panel y no se beneficia para nada de la profundidad. Una app de toma 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. Omite.

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 de Vision sin un dispositivo real es excepcionalmente difícil, más aún que el caso de watchOS.

Dominan las preocupaciones de privacidad y presencia. Apps de divulgación de salud. Herramientas sensibles del lugar de trabajo. El dispositivo visionOS se comparte entre miembros del hogar de una forma en que el iPhone no; una app que muestra información privada necesita una postura distinta ahí que en iPhone.

El Apple TV es el motor de enfoque

Las apps de TV están guiadas por el motor de enfoque del Siri Remote: el usuario mueve un resaltado de enfoque con el control, 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 enfoque desde cero. El modelo de tocar-y-deslizar del iPhone no se traduce.

Señales de “sí a TV”:

La app es para consumir contenido a la distancia de ver TV. Video en streaming (Apple TV+, Netflix). Presentaciones de fotos. Apps de juegos familiares que el usuario controla con el control. 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 “recostado” que el iPhone no tiene. Videos de entrenamiento que el usuario sigue. Apps de cocina que el usuario consulta mientras está en la estufa. Cuentos para dormir que el usuario escucha mientras se duerme. Ninguno de estos se atiende bien con un teléfono apoyado en la mesa de centro.

El modelo de interacción se ajusta a una navegación escasa y guiada por enfoque. Una lista de elementos que el usuario elige uno a la vez. Una cuadrícula de opciones. Un flujo de reproducción lineal. 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 “no a TV”:

La app necesita entrada de texto. La entrada de texto en TV a través del control 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, omite 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. La 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 enfoque, pruebas separadas, revisión del App Store para tvOS). Para la mayoría de las apps, las cuentas no justifican el lugar. Una app de meditación se gana un lugar en Apple TV solo con un modo real “déjala en pantalla en bajo brillo mientras me siento en el sofá” que el caso de uso realmente recompense; sin ese modo, incluso una app cuyo temporizador se mapea limpiamente al patrón recostado de TV no merece la factura de mantenimiento.

La matriz en la práctica

La matriz real de cada app del cluster:

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

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 apunta a #if canImport(SwiftUI) && canImport(<platform>) para superficies específicas de plataforma. La lógica del dominio central (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 la mayoría de los casos; las superficies que genuinamente divergen (una barra de menú 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.

La sincronización entre dispositivos pasa por un único sustrato, elegido por dominio. NSUbiquitousKeyValueStore para estado pequeño a 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 dentro del proceso. Mezclar los sustratos por dominio está bien; usar dos sustratos para el mismo dominio es el modo de falla que produce deriva.

Cada plataforma tiene patrones explícitos de rechazo documentados por app. “No publicaremos en TV a menos que el caso de uso tenga un modo recostado.” “No publicaremos en Vision a menos que la app use RealityKit, no un panel.” “No publicaremos en Watch sin un tipo de sesión.” Los rechazos son decisiones de proyecto capturadas por app y aplicadas de manera consistente, 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 equivocado.

El equipo añade un objetivo porque la cadena de herramientas lo facilita. El asistente “duplicar objetivo” de Xcode hace que añadir un objetivo de 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 publicados desde el asistente sin que ese trabajo se publique con ellos están rotos desde el primer día.

El equipo trata el conteo de objetivos como una señal de estatus. “Publicamos en cinco plataformas de 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 mejor producto que una app de cinco plataformas que está estirada.

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

Qué significa este patrón para apps que se publican 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 la ingeniería; la prueba de valor para el usuario es el lado del producto. Sin una respuesta clara a “¿el usuario se beneficia genuinamente al 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 runtime (Watch), modelo espacial (Vision), motor de enfoque (TV). Omitir las obligaciones produce una app-de-iPad-en-Mac, una app-de-teléfono-en-Vision, una app-de-iPhone-en-Watch, todas fallas visibles que los usuarios reales de la plataforma notan.

3. La mayoría de las apps deberían publicarse en una a tres plataformas. De cuatro a seis es poco común y se gana solo cuando cada plataforma aporta genuinamente valor al usuario. Las apps del cluster van de una a seis; el caso de seis plataformas (Return) es la excepción que confirma la regla, y cada plataforma adicional fue una decisión de producto separada con su propia prueba de valor para el usuario.

El cluster completo del Ecosistema Apple: App Intents tipados para la superficie de Apple Intelligence; servidores MCP para la superficie de agentes; la pregunta de enrutamiento entre ellos; Foundation Models para funciones LLM en el dispositivo dentro de la app; la distinción runtime 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 de Xcode; hooks para desarrollo en Apple; Live Activities; el contrato del runtime de watchOS; internas de SwiftUI; el modelo mental espacial de RealityKit; disciplina de esquema de SwiftData; patrones de Liquid Glass; publicación multiplataforma; sobre lo que me niego a escribir. El hub está en la Serie del Ecosistema Apple. Para un contexto más amplio de 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 de Apple?

Pregúntate si el usuario se beneficia genuinamente al 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 del producto. Cada plataforma trae obligaciones específicas (clase de tamaño, ventana/menú, contrato de runtime, modelo espacial, motor de enfoque) y un costo específico de mantenimiento. Si la respuesta es “también funciona ahí”, la decisión correcta suele ser omitir el objetivo.

¿Debería publicar en las seis plataformas de Apple?

Usualmente no. La mayoría de las apps se benefician de una a tres plataformas. De cuatro a seis es poco común y se gana solo cuando cada plataforma aporta genuinamente valor para el usuario (Return alcanza las seis porque la sesión de mindfulness encaja en el Watch, el temporizador encaja en iPad y Mac como compañeros de escritorio, visionOS encaja en un modo inmersivo, y TV encaja en un caso de uso recostado en el 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 omitir esos objetivos.

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

Tratar el iPad como “iPhone con más píxeles”. Una app SwiftUI de iPhone arrojada al iPad sin adaptación de clase de tamaño produce una UI estirada de una sola columna 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 vía NavigationSplitView, de lo contrario una sola lista con espaciado cómodo) y considerar el Apple Pencil y las posibilidades multidedo como valor específico del iPad.

¿Por qué el Apple Watch es tan distinto a 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 (mindfulness, workout-processing, alarm, etc.) pueden ejecutarse después de la suspensión. Las apps sin un tipo de sesión limpio producen experiencias rotas en el segundo uso. El artículo del runtime de watchOS del cluster 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 estado clave-valor pequeño (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 dentro del proceso. Elige un sustrato por dominio; mezclar dos para el mismo dominio produce deriva. El artículo sobre fuente única de verdad del cluster recorre la matriz de decisión.