A matriz de plataformas Apple: quais alvos merecem qual app

A Apple lança seis plataformas de computação para o consumidor que um desenvolvedor pode atingir com uma única base de código Swift: iPhone, iPad, Mac, Watch, Vision e TV. SwiftUI mais a toolchain do iOS 26 transformam adicionar qualquer uma delas em uma operação de marcar a caixinha no Xcode. A caixinha para marcar é a armadilha. Cada alvo adicional é uma obrigação, não um recurso: cada um expande a área de superfície de design, testes, acessibilidade, modelo de runtime e manutenção contínua. O número certo de alvos para um app é menor que o que o framework permite.

Os apps do cluster rodam em mixes diferentes. Return é lançado em seis plataformas (iPhone, iPad, Mac, Watch, Vision, TV). Get Bananas é lançado em quatro (iPhone, iPad, Mac, Watch). Reps e Water estão em pré-lançamento com múltiplos alvos compilados que os apps vão estreitar antes do lançamento. Ace Citizenship e Tappy Color cada um é lançado apenas no iPhone. Mesmo desenvolvedor, mesma toolchain, seis decisões de plataforma diferentes. As decisões seguem regras; as regras merecem um mapa compartilhado.

O artigo nomeia as regras. Cada plataforma ganha inclusão por meio de valor específico para o usuário que a plataforma genuinamente adiciona, não por meio de “compila”. A matriz que sobrevive ao lançamento é o que resta depois que cada alvo se justifica ou é cortado.

TL;DR

• Seis plataformas, seis obrigações diferentes: iPhone (padrão), iPad (adaptação de size-class), Mac (idiomas de janela/menu/teclado), Watch (contrato de runtime), Vision (modelo mental espacial), TV (motor de foco).
• Cada alvo adicional adiciona superfície de testes, trabalho de design, acessibilidade e coordenação contínua de release. A caixinha “adicionar plataforma” do Xcode esconde o custo.
• Os testes certos são testes de valor para o usuário, não testes técnicos: o usuário genuinamente se beneficia de rodar este app naquela plataforma? Se a resposta é “também funciona lá”, corte.
• A maioria dos apps deve ser lançada em uma a três plataformas. Quatro a seis é incomum e ganha o slot só quando cada plataforma genuinamente adiciona valor para o usuário que as outras não conseguem entregar.

iPhone é o padrão

Todo app Apple começa no iPhone ou não começa. iPhone tem a maior base instalada, a superfície de acessibilidade mais refinada, o caminho de distribuição mais forte através da App Store e a linguagem de design canônica do SwiftUI. Cada app do cluster que lancei roda no iPhone. Nenhum lançou um design não-iPhone-first.

O teste de valor para o usuário no iPhone: o usuário abriria este app em um celular? Para quase toda categoria de consumo, sim. Apps de saúde e fitness vivem no celular. Ferramentas de produtividade vivem no celular. Jogos vivem no celular. Ferramentas de comunicação vivem no celular. O padrão é iPhone porque o celular é onde o usuário está.

A exceção são ferramentas de dev (Xcode, Terminal) e ferramentas criativas que precisam de espaço (Final Cut, Logic). Essas começam no Mac e ganham um companheiro no iPhone só se houver um handoff claro (frequência cardíaca do Watch durante um treino que o celular mostra o gráfico, Camera Continuity). Para software de consumo, iPhone-first não é um debate.

iPad não é um iPhone com mais pixels

O Catalyst tornou possível lançar um app UIKit de iPhone no iPad com breakpoints de size-class. SwiftUI tornou a mesma coisa mais fácil através de @Environment(\.horizontalSizeClass) e NavigationSplitView. O custo técnico de “lançar para iPad” é baixo. O custo de produto é a questão de se o app realmente merece o canvas maior do iPad.

Três sinais de iPad-sim:

O app lê ou cria conteúdo para o qual o usuário quer mais tela. Apps de leitura (Books, notícias, quadrinhos, documentos longos). Apps de desenho/pintura (Procreate). Anotações com Apple Pencil (Notability, GoodNotes). Get Bananas ganha seu slot no iPad porque uma lista de compras com seções é mais útil em um canvas largo que em um estreito; o design do iPad adapta a mesma lista de seções para a área maior.

O app tem valor de handoff com iPhone ou Mac. Apple Notes, Reminders e Mail todos ganham slots no iPad porque o usuário espera continuidade. O histórico de meditação do Return no iPad ganha seu slot pela mesma razão: o usuário começa no iPhone, dá uma olhada no iPad enquanto o timer roda.

O app tem uma affordance de input nativa do iPad. Apple Pencil para esboço/escrita à mão. Gestos de múltiplos dedos em uma superfície maior. Fluxos de Stage Manager que se beneficiam de layout baseado em tiles. Se a affordance não existe no iPhone, o alvo do iPad ganha seu lugar.

Os sinais de iPad-não:

Conteúdo de coluna única sem valor extra em escala. A view principal de um timer de meditação é uma contagem e um botão. iPad torna ambos maiores; isso não é um recurso. Um rastreador de hidratação de log rápido é o mesmo; a tela maior não muda o que o usuário faz durante uma sessão de log de cinco segundos.

Apps que dependem de hardware específico do iPhone (Lock Screen, Dynamic Island, ProMotion em configurações específicas exclusivas do iPhone, certos formatos de câmera). Essas suposições de design traduzem mal; ou reconstrua o design ou pule o alvo.

Apps onde o usuário já tem um destino melhor no Mac. Um editor de código no iPad sem suporte a teclado é uma versão capada do app Mac. Pule o alvo a menos que o design ganhe seu lugar no modelo de input específico do iPad.

Mac é janela, barra de menu e idiomas de teclado

Um app SwiftUI lançado para Mac via Mac Catalyst ou “Designed for iPad” roda no macOS sem produzir um app Mac de verdade. Um app Mac de verdade honra a semântica de redimensionamento de janela, a barra de menu (Commands(content:) no SwiftUI), atalhos de teclado, o file picker do macOS, drag-and-drop com o Finder e compartilhamento nativo do Mac. Pular qualquer um desses produz uma experiência de iPad-app-numa-janela que usuários de Mac percebem e julgam.

Sinais de Mac-sim:

O usuário passa tempo no app e se beneficiaria dele ser uma janela de desktop de verdade. Get Bananas no Mac ganha seu slot porque usuários editando uma longa lista de compras numa mesa se beneficiam de uma janela de verdade com navegação por teclado. Return no Mac ganha porque usuários que querem um timer de meditação rodando na máquina de trabalho se beneficiam de um app menubar de verdade ou de uma janela fixada num canto específico.

Fluxos de múltiplas janelas ou múltiplos documentos. Um editor de código com painéis divididos. Um editor de fotos com imagens de referência lado a lado. Uma planilha. Nenhum desses sobrevive no iPad ou iPhone na sua forma adequada; Mac é a plataforma certa.

Interação dirigida por teclado. Um app SwiftUI no Mac que ignora o teclado é um app Mac só no nome. Cmd+N para novo, Cmd+W para fechar, Tab para travessia de foco, setas para seleção. O custo é por app: cada alvo Mac precisa de uma superfície de teclado pensada com cuidado.

Sinais de Mac-não:

O app é uma ferramenta pequena, de tarefa única, que não se beneficia de uma janela. Um timer matinal que o usuário roda uma vez por dia por cinco minutos não precisa de um alvo Mac. O usuário pode rodá-lo no iPhone ao lado do Mac.

Apps onde a UI no formato de iPhone fundamentalmente não traduz. Apps de câmera. Apps companheiros do Apple Watch. Apps onde o modelo de input é touch-first e o equivalente teclado/mouse seria pior que tocar no celular.

O time não consegue se comprometer com manutenção contínua específica do Mac. Releases de Mac são escrutinados de forma diferente que releases de iPhone. Ciclos de update do macOS, assinatura para o Gatekeeper, notarização, a revisão da App Store especificamente para Mac, cada um desses adiciona trabalho de ciclo de release que o time tem que orçar. Se o time não vai orçar, pule o alvo.

Apple Watch é um contrato de runtime

O Watch é a plataforma onde “lançar para ele” é uma instrução ativamente enganosa. O modelo de runtime do Watch, coberto em detalhe em O runtime do watchOS é um contrato, não uma background task, é fundamentalmente diferente do iOS: o pulso cai, o sistema suspende o app, e apenas tipos específicos de sessão (mindfulness, workout-processing, alarm, etc.) podem rodar após a suspensão. Um alvo Watch sem uma história de runtime está quebrado no segundo uso.

Sinais de Watch-sim:

O app tem um formato de sessão que o modelo de runtime do watchOS reconhece. Timers de meditação (sessão mindfulness). Apps de fitness (workout-processing). Despertadores (alarm). Navegação (o tipo de sessão de navegação). Return é lançado no Watch porque meditação mapeia limpa para mindfulness; o app Watch mantém o timer rodando através do wrist-drop porque o contrato de runtime permite.

O usuário genuinamente quer o pulso como superfície de input. Um visualizador de frequência cardíaca durante exercício. Um timer que o usuário inicia sem tirar o celular. Uma complication que apresenta informação a um relance. Get Bananas é lançado no Watch como uma superfície rápida de checagem de lista emparelhada com o store canônico do iPhone; um app de treino como Reps ganha seu alvo Watch pela mesma razão, porque logar uma série no pulso é mais rápido que pescar o celular do bolso.

O valor do app companheiro é real. Alguns apps Watch existem primariamente como displays para dados dirigidos pelo iPhone (ex: um timer de receita onde o iPhone roda o timer e o Watch mostra a contagem restante). Esses ganham seu slot só se a sincronização entre dispositivos for construída honestamente (coberto em Single Source of Truth: SwiftData + MCP + iCloud) e a view do Watch faz trabalho real além de espelhar.

Sinais de Watch-não:

O app não tem nenhum tipo de sessão que possa reivindicar. Um app de leitura no Watch é um app Watch só no nome. O usuário não pode ler um livro no pulso; o modelo de runtime não estende a sessão. Pule.

O time não consegue se comprometer com debugging específico do watchOS. Debugging de Watch é unicamente doloroso: o comportamento do simulador diverge do comportamento do dispositivo real de formas que só aparecem em um Apple Watch real sob condições de wrist-drop. Se o time não tem hardware e disposição para testar nele, o alvo Watch é lançado quebrado.

O modelo de dados não cabe num envelope de sincronização entre dispositivos de 1MB. Sincronização entre dispositivos de iPhone para Watch normalmente passa por NSUbiquitousKeyValueStore (coberto no post de lançamento multiplataforma). O store tem 1MB total + 1MB por valor + 1024 chaves. Se o estado de sessão do app não cabe nesse envelope, o alvo Watch precisa de uma arquitetura de sync diferente, o que é investimento real de engenharia.

Vision é o modelo mental espacial

O Vision Pro tenta os apps a serem lançados como um painel achatado pairando no espaço 3D. Esse painel é uma janela SwiftUI, e SwiftUI no visionOS torna seu lançamento uma operação de um clique. O painel é um iPad pior. O valor real da plataforma vem do modelo mental espacial, coberto em RealityKit e o modelo mental espacial, onde o conteúdo vive na sala em vez de no painel.

Sinais de Vision-sim:

O app tem conteúdo 3D que se beneficia de estar na sala. Uma escultura virtual em torno da qual o usuário pode caminhar. Uma trena que se apoia em uma parede real. Um coach de treino que projeta dicas de forma sobre uma imagem espelhada do corpo do usuário. A maioria dos apps do cluster que aparecem no visionOS o faz via compatibilidade “Designed for iPad” em vez de um alvo nativo do visionOS; essa compatibilidade está bem para o usuário mas não torna o app uma experiência nativa do Vision. O post sobre o modelo mental espacial do RealityKit argumenta que ganhar a plataforma significa mais que rodar nela.

Hand-tracking é o modelo de input certo. Pinçar para pegar, escala com duas mãos, desenhar no ar. visionOS dá uma affordance de input que nenhuma outra plataforma tem; os apps que ganham seu slot no visionOS se inclinam nela.

O app lida com superfícies específicas espaciais (equivalentes da Lock Screen, espaços imersivos, ornaments). Apps de produtividade que apenas flutuam sua UI de iPhone no Vision são ruído visível no primeiro dia do usuário com o dispositivo. Os apps que fazem o usuário continuar voltando são os que exploram a superfície espacial.

Sinais de Vision-não:

O app é fundamentalmente em formato de painel e não se beneficia em nada da profundidade. Um app de anotações, um app de chat, um utilitário de configurações. visionOS vai rodá-los; o usuário não tem razão para usá-los no visionOS em vez do iPad. Pule.

O time de desenvolvimento não tem testes específicos do visionOS. visionOS é a plataforma com a menor base instalada e os padrões mais frágeis; testar um alvo Vision sem um dispositivo real é unicamente difícil, mais que o caso do watchOS.

Preocupações de privacidade e presença dominam. Apps de divulgação de saúde. Ferramentas sensíveis de local de trabalho. O dispositivo visionOS é compartilhado entre membros da casa de uma forma que o iPhone não é; um app que apresenta informação privada precisa de uma postura diferente lá que no iPhone.

Apple TV é o motor de foco

Apps de TV são dirigidos pelo motor de foco do Siri Remote: o usuário move um destaque de foco com o controle, pressiona para selecionar, e nunca vê uma interação de toque. SwiftUI no tvOS suporta isso através do modificador .focusable(...), do property wrapper @FocusState e de .focused(...) para state binding, mas todo app de TV precisa de um design de foco do zero. O modelo tap-and-scroll do iPhone não traduz.

Sinais de TV-sim:

O app é para consumo de conteúdo na distância de assistir TV. Streaming de vídeo (Apple TV+, Netflix). Slideshows de fotos. Apps de jogos em família que o usuário controla com o controle. O usuário está num sofá, a tela está longe, o input é esparso, TV é a plataforma certa.

O app tem um caso de uso “lean back” que o iPhone não tem. Vídeos de treino que o usuário acompanha. Apps de culinária que o usuário consulta enquanto está no fogão. Histórias para dormir que o usuário escuta enquanto dorme. Nenhum desses é bem servido por um celular apoiado na mesa de centro.

O modelo de interação se encaixa em navegação esparsa, dirigida por foco. Uma lista de itens que o usuário escolhe um de cada vez. Uma grade de opções. Um fluxo linear de playback. Qualquer coisa mais complexa que isso, gestos multi-touch, entrada de texto detalhada, drag-and-drop, não funciona no tvOS e significa que o alvo está errado.

Sinais de TV-não:

O app precisa de entrada de texto. Entrada de texto na TV através do controle é um dos piores modelos de input em qualquer plataforma Apple. Se o app precisa de qualquer coisa além de uma caixa de busca, pule TV.

O valor do app depende das mãos do usuário estarem livres para outras tarefas. Rastreamento de fitness. Monitoramento de saúde. Colaboração em tempo real. A TV é uma tela, não um wearable.

O custo de manutenção é alto demais para a base instalada. tvOS tem uma base instalada pequena relativa ao iOS. O custo de desenvolvimento é real (design de foco, testes separados, revisão da App Store para tvOS). Para a maioria dos apps, a matemática não justifica o slot. Um app de meditação ganha um slot na Apple TV só com um modo “deixe na tela em baixo brilho enquanto sento no sofá” de verdade que o caso de uso realmente recompense; sem esse modo, mesmo um app cujo timer mapeia limpo para o padrão lean-back da TV não merece a conta de manutenção.

A matriz na prática

A matriz real de cada app do cluster:

O padrão: cada linha é um corte deliberado tanto quanto uma adição deliberada. Return alcança seis plataformas porque cada uma é justificada por meio de um teste específico de valor para o usuário; os apps só de iPhone ficam ali porque nada mais é. Mesma toolchain, produtos diferentes, matrizes diferentes.

Três decisões de arquitetura que tornam a matriz sustentável

Três padrões que evitam que apps multiplataforma colapsem sob seu próprio peso:

Um core compartilhado mira #if canImport(SwiftUI) && canImport(<plataforma>) para superfícies específicas de plataforma. A lógica de domínio do core (modelos de dados, regras de negócio, sync) compila em todo lugar. UI específica de plataforma vive atrás de condicionais de tempo de compilação. @available(iOS 26.0, macOS 26.0, ...) do SwiftUI cobre a maioria dos casos; superfícies que genuinamente divergem (uma barra de menu Mac que não tem equivalente no iPhone, uma complication do Watch que não tem equivalente no iPad) ganham seus próprios arquivos em grupos específicos do alvo.

Sincronização entre dispositivos passa por um substrato, escolhido por domínio. NSUbiquitousKeyValueStore para estado pequeno em nível de sessão entre dispositivos (Return usa isso para estado de timer entre dispositivos). Arquivos no iCloud Drive JSON para pontes entre processos (Get Bananas usa isso com seu servidor MCP, coberto em Single Source of Truth). SwiftData para estado em-processo. Misturar os substratos por domínio está bem; usar dois substratos para o mesmo domínio é o modo de falha que produz drift.

Cada plataforma tem padrões de recusa explícitos documentados por app. “Não vamos lançar para TV a menos que o caso de uso tenha um modo lean-back.” “Não vamos lançar para Vision a menos que o app use RealityKit, não um painel.” “Não vamos lançar para Watch sem um tipo de sessão.” As recusas são decisões de projeto capturadas por app e aplicadas consistentemente, no espírito de Sobre o que me recuso a escrever.

Quando adicionar plataformas é errado

Três casos onde o caminho mais fácil é o errado.

O time adiciona um alvo porque a toolchain torna fácil. O wizard “duplicate target” do Xcode torna adicionar um alvo Mac ou visionOS uma operação de quatro cliques. Os quatro cliques não incluem revisão de design, auditoria de acessibilidade, criação de screenshots para a App Store, coordenação contínua de release ou testes por plataforma. Alvos lançados pelo wizard sem esse trabalho lançando junto estão quebrados no dia um.

O time trata contagem de alvos como um sinal de status. “Lançamos em cinco plataformas Apple” soa impressionante num tweet de lançamento. O tweet de lançamento não roda nos dispositivos dos usuários; os apps rodam. Um app de duas plataformas que acerta as duas é um produto melhor que um app de cinco plataformas que está esticado.

O time subestima a manutenção contínua. Cada plataforma Apple lança grandes atualizações de OS anualmente. Um app de cinco plataformas tem cinco conjuntos de release notes para reagir, cinco conjuntos de mudanças de comportamento para testar, cinco conjuntos de metadados da App Store para manter atuais. O custo se compõe; times que lançam para todas as cinco sem largura de banda para mantê-las produzem produtos lentamente degradantes em três daquelas plataformas.

O que esse padrão significa para apps lançando no iOS 26+

Três conclusões.

1. Inclusão de plataforma é uma decisão de produto antes de ser de engenharia. A caixinha do Xcode é o lado de engenharia; o teste de valor para o usuário é o lado de produto. Sem uma resposta clara para “o usuário genuinamente se beneficia de rodar este app naquela plataforma”, o alvo é cortado.

2. Cada plataforma traz obrigações específicas: size class (iPad), janela/menu/teclado (Mac), contrato de runtime (Watch), modelo espacial (Vision), motor de foco (TV). Pular as obrigações produz um iPad-app-no-Mac, um app-de-celular-no-Vision, um app-de-iPhone-no-Watch, todos falhas visíveis que os usuários reais da plataforma percebem.

3. A maioria dos apps deve lançar em uma a três plataformas. Quatro a seis é incomum e ganho só quando cada plataforma genuinamente adiciona valor para o usuário. Os apps do cluster vão de uma a seis; o caso de seis plataformas (Return) é a exceção que prova a regra, e cada plataforma adicional foi uma decisão de produto separada com seu próprio teste de valor para o usuário.

O cluster Apple Ecosystem completo: App Intents tipados para a superfície de Apple Intelligence; servidores MCP para a superfície de agente; a questão de roteamento entre eles; Foundation Models para recursos LLM on-device dentro do app; a distinção entre LLM de runtime vs tooling; a síntese das três superfícies; o padrão de single source of truth; Dois Servidores MCP para a integração com o Xcode; hooks para desenvolvimento Apple; Live Activities; o contrato de runtime do watchOS; internals do SwiftUI; o modelo mental espacial do RealityKit; disciplina de schema do SwiftData; padrões do Liquid Glass; lançamento multiplataforma; sobre o que me recuso a escrever. O hub está na Série Apple Ecosystem. Para contexto mais amplo de iOS-com-AI-agents, veja o guia de Desenvolvimento de Agentes iOS.

FAQ

Como decidir se devo adicionar um alvo de plataforma Apple?

Pergunte se o usuário genuinamente se beneficia de rodar o app naquela plataforma, não se a toolchain permite. A caixinha do Xcode é o lado técnico; o teste de valor para o usuário é o lado de produto. Cada plataforma traz obrigações específicas (size class, janela/menu, contrato de runtime, modelo espacial, motor de foco) e custo de manutenção específico. Se a resposta é “também funciona lá”, a chamada certa geralmente é pular o alvo.

Devo lançar nas seis plataformas Apple?

Geralmente não. A maioria dos apps se beneficia de uma a três plataformas. Quatro a seis é incomum e ganho só quando cada plataforma genuinamente adiciona valor para o usuário (Return alcança todas as seis porque sessão mindfulness se encaixa no Watch, o timer se encaixa no iPad e Mac como companheiros de mesa, visionOS se encaixa em um modo imersivo, e TV se encaixa em um caso de uso de sofá lean-back). Para a maioria dos apps, o modelo de interação do tvOS e os requisitos espaciais do visionOS não se encaixam, e a chamada certa é pular esses alvos.

Qual é o erro mais comum ao adicionar um alvo iPad?

Tratar iPad como “iPhone com mais pixels”. Um app SwiftUI de iPhone jogado no iPad sem adaptação de size-class produz uma UI esticada de coluna única que usuários de iPad imediatamente julgam como meio-esforço. O padrão certo é ler @Environment(\.horizontalSizeClass), adaptar o layout para o canvas maior (duas colunas onde fizer sentido via NavigationSplitView, caso contrário uma única lista com espaçamento confortável) e considerar Apple Pencil e affordances de múltiplos dedos como valor específico do iPad.

Por que o Apple Watch é tão diferente das outras plataformas?

watchOS não tem o modelo de execução em background do iOS. O pulso cai, o sistema suspende o app, e apenas tipos específicos de sessão (mindfulness, workout-processing, alarm, etc.) podem rodar após a suspensão. Apps sem um tipo de sessão limpo produzem experiências quebradas-no-segundo-uso. O post sobre o runtime do watchOS do cluster cobre o contrato em detalhe.

Como funciona a sincronização entre dispositivos pela matriz de plataformas?

Três substratos: NSUbiquitousKeyValueStore para estado pequeno chave-valor (configurações, última-aba-selecionada, estado de timer entre dispositivos), arquivos no iCloud Drive para pontes entre processos (o padrão Get Bananas + servidor MCP), SwiftData para estado em-processo. Escolha um substrato por domínio; misturar dois para o mesmo domínio produz drift. O post sobre single source of truth do cluster percorre a matriz de decisão.