A matriz de plataformas Apple: quais alvos merecem qual app

A Apple lança seis plataformas de computação de consumo 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 uma caixinha no Xcode. A caixinha é a armadilha. Cada alvo adicional é uma obrigação, não um recurso: cada um estende 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 do que o framework permite.

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

Cada plataforma conquista a inclusão por meio do valor específico ao usuário que ela genuinamente adiciona, não porque “compila”. A matriz que sobrevive ao envio é o que sobra 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 (focus engine).
• Cada alvo adicional adiciona superfície de testes, trabalho de design, acessibilidade e coordenação contínua de releases. A caixinha “add platform” 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 ao rodar este app naquela plataforma? Se a resposta for “também funciona lá”, corte.
• A maioria dos apps deve entregar em uma a três plataformas. Quatro a seis é incomum e só conquista a vaga quando cada plataforma genuinamente adiciona valor ao usuário que as outras não conseguem entregar.

iPhone é o padrão

Todo app da Apple começa no iPhone ou não começa. O 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. Todo app do cluster que entreguei roda no iPhone. Nenhum entregou um design não-iPhone-first.

O teste de valor para o usuário no iPhone: um 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 é 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 conquistam um companion no iPhone só se houver um handoff claro (heart-rate do Watch durante um treino que o celular mostra o gráfico, Camera Continuity). Para software de consumo, iPhone-first não é debate.

iPad não é um iPhone com mais pixels

Binários universais e size classes tornaram possível entregar um app UIKit do 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 “entregar para iPad” é baixo. O custo de produto é a pergunta de se o app de fato 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 conquista sua vaga no iPad porque uma lista de compras com seções é mais útil em um canvas mais largo do que em um estreito; o design no 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 conquistam vagas no iPad porque o usuário espera continuidade. O histórico de meditação do Return no iPad conquista sua vaga pelo mesmo motivo: 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 com múltiplos dedos em uma superfície maior. Workflows do Stage Manager que se beneficiam de layout baseado em tiles. Se a affordance não existe no iPhone, o alvo iPad conquista 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. O iPad torna ambos maiores; isso não é um recurso. Um tracker de hidratação de quick-log é a mesma coisa; a tela mais larga 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 (Dynamic Island, certos formatos de câmera só do Pro, a ergonomia do grip em formato de iPhone). Essas premissas de design traduzem mal; ou refaça 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 conquiste seu lugar no modelo de input específico do iPad.

Mac é janela, barra de menu e idiomas de teclado

Um app SwiftUI entregue para Mac via o alvo nativo macOS ou “Designed for iPad” (Mac Catalyst é o caminho equivalente UIKit que traz código UIKit para o Mac) 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 (o modificador Scene .commands { } com builders CommandMenu e CommandGroup no SwiftUI), atalhos de teclado, o seletor de arquivos do macOS, drag-and-drop com o Finder e compartilhamento nativo do Mac.³ Pular qualquer um desses produz uma experiência de app-iPad-em-uma-janela que usuários do 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 conquista sua vaga porque usuários editando uma lista de compras longa numa mesa se beneficiam de uma janela de verdade com navegação por teclado. Return no Mac conquista porque usuários que querem um timer de meditação rodando em sua máquina de trabalho se beneficiam de um app de menubar de verdade ou de uma janela fixada num canto específico.

Workflows multi-janela ou multi-documento. 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; o Mac é a plataforma certa.

Interação dirigida por teclado. Um app SwiftUI no Mac que ignora o teclado é um app Mac apenas 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.

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 rodar no iPhone ao lado do Mac.

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

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

Apple Watch é um contrato de runtime

O Watch é a plataforma onde “entregar 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 de sessão específicos (self-care, mindfulness, physical-therapy, alarm para WKExtendedRuntimeSession, mais workout-processing para HKWorkoutSession e underwater-depth para sessões de mergulho) podem rodar após a suspensão.⁴ Um alvo Watch sem uma estratégia 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 de mindfulness). Apps de fitness (HKWorkoutSession com modo de background workout-processing). Alarmes inteligentes (alarm). Apps de fisioterapia e self-care (os tipos de sessão correspondentes). Return entrega no Watch porque meditação mapeia limpinho para mindfulness; o app Watch mantém o timer rodando através da queda do pulso porque o contrato de runtime permite.

O usuário genuinamente quer o pulso como superfície de input. Um visualizador de heart-rate durante exercício. Um timer que o usuário inicia sem tirar o celular. Uma complication que traz informação à vista de relance. Get Bananas entrega no Watch como uma superfície rápida de checagem de lista pareada com o iPhone como loja canônica; um app de treino como Reps conquista seu alvo Watch pelo mesmo motivo, porque registrar uma série no pulso é mais rápido do que pescar o celular do bolso.

O valor do app companion é real. Alguns apps Watch existem primariamente como displays para dados dirigidos pelo iPhone (por exemplo, um timer de receita onde o iPhone roda o timer e o Watch mostra a contagem restante). Esses conquistam sua vaga só se a sincronização cross-device for construída honestamente (coberto em Single Source of Truth: SwiftData + MCP + iCloud) e a view do Watch fizer trabalho real além de espelhar.

Sinais de Watch-não:

O app não tem um tipo de sessão que possa reivindicar. Um app de leitura no Watch é um app Watch só no nome. O usuário não consegue 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 no Watch é singularmente doloroso: o comportamento do simulador diverge do comportamento em dispositivo real de formas que só aparecem em um Apple Watch real sob condições de queda do pulso. Se o time não tem hardware e disposição para testar nele, o alvo Watch entrega quebrado.

O modelo de dados não cabe nos envelopes de sincronização cross-device. A sincronização cross-device do iPhone para o Watch é tipicamente WatchConnectivity para estado ao vivo e NSUbiquitousKeyValueStore para pequeno estado persistido (Return usa o último para sincronização de histórico de sessão; coberto no post de entrega multi-plataforma). O store tem um cap de 1 MB através de todas as chaves com um máximo de 1024 chaves.⁵ Se o estado de sessão do app não cabe nesse envelope, o alvo Watch precisa de uma arquitetura de sincronização diferente, o que é investimento de engenharia real.

Vision é o modelo mental espacial

O Vision Pro tenta apps a entregar como um painel plano flutuando em espaço 3D. Esse painel é uma janela SwiftUI, e SwiftUI no visionOS torna entregá-lo 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 no ambiente em vez de no painel.

Sinais de Vision-sim:

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

Hand-tracking é o modelo de input certo. Pinçar para agarrar, escala com duas mãos, desenhar no ar. visionOS dá uma affordance de input que nenhuma outra plataforma tem; os apps que conquistam sua vaga no visionOS se apoiam nela.

O app lida com superfícies específicas do espacial (equivalentes de 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 de 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 motivo para usá-los no visionOS em vez do iPad. Pule.

O time de desenvolvimento não tem testes específicos para visionOS. visionOS é a plataforma com a menor base instalada e os padrões mais frágeis; testar um alvo Vision sem um dispositivo real é singularmente difícil, mais ainda 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 um jeito que o iPhone não é; um app que traz informação privada à tona precisa de uma postura diferente lá do que no iPhone.

Apple TV é a focus engine

Apps de TV são dirigidos pela focus engine 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 binding de estado, 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 a uma distância de assistir TV. Streaming de vídeo (Apple TV+, Netflix). Slideshows de fotos. Apps de jogos 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 café.

O modelo de interação cabe em navegação esparsa, dirigida por foco. Uma lista de itens que o usuário escolhe um de cada vez. Um grid de opções. Um fluxo de reprodução linear. Qualquer coisa mais complexa, gestos multi-touch, entrada de texto granular, 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 de qualquer plataforma Apple. Se o app precisa de qualquer coisa além de uma caixa de busca, pule a TV.

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

O custo de manutenção é muito alto 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 conta não justifica a vaga. Um app de meditação conquista uma vaga na Apple TV apenas com um modo “deixe na tela em brilho baixo enquanto eu sento no sofá” de verdade que o caso de uso de fato recompense; sem esse modo, mesmo um app cujo timer mapeia limpinho 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 através de um teste específico de valor para o usuário; os apps só-iPhone permanecem lá 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 mantêm apps multi-plataforma de colapsarem sob seu próprio peso:

Um core compartilhado usa #if os(iOS), #if os(macOS), #if os(watchOS) (e amigos) para isolar 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 diferenças de versão de OS; superfícies que genuinamente divergem entre plataformas (uma barra de menu Mac que não tem equivalente no iPhone, uma complication do Watch que não tem equivalente no iPad) ficam em seus próprios arquivos em grupos específicos do alvo atrás de gates #if os(...).

Sincronização cross-device passa por um substrato, escolhido por domínio. NSUbiquitousKeyValueStore para pequeno estado em nível de sessão entre dispositivos (Return usa para estado de timer cross-device). Arquivos do iCloud Drive JSON para pontes cross-process (Get Bananas usa com seu servidor MCP, coberto em Single Source of Truth). SwiftData para estado in-process. Misturar 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 explícitos de recusa documentados por app. “Não vamos entregar para TV a menos que o caso de uso tenha um modo lean-back.” “Não vamos entregar para Vision a menos que o app use RealityKit, não um painel.” “Não vamos entregar 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 screenshot da App Store, coordenação contínua de release ou teste por plataforma. Alvos entregues do wizard sem esse trabalho indo junto entregam quebrados no dia um.

O time trata contagem de alvos como sinal de status. “Entregamos em cinco plataformas Apple” soa impressionante num tweet de launch. O tweet de launch não roda em dispositivos de usuário; os apps rodam. Um app de duas plataformas que acerta ambas é um produto melhor do que um app de cinco plataformas que está esticado.

O time subestima manutenção contínua. Cada plataforma Apple lança updates importantes 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 acumula; times que entregam para todas as cinco sem a banda para mantê-las produzem produtos lentamente decadentes em três dessas plataformas.

O que esse padrão significa para apps entregando no iOS 26+

Três pontos a levar.

1. Inclusão de plataforma é uma decisão de produto antes de ser uma 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), focus engine (TV). Pular as obrigações produz um app-iPad-no-Mac, um app-celular-no-Vision, um app-iPhone-no-Watch, todas falhas visíveis que os usuários reais da plataforma percebem.

3. A maioria dos apps deve entregar em uma a três plataformas. Quatro a seis é incomum e conquistado apenas 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) é o ponto final raro, e cada plataforma adicional ali foi uma decisão de produto separada com seu próprio teste de valor para o usuário.

O cluster completo do Apple Ecosystem: App Intents tipados para a superfície da Apple Intelligence; servidores MCP para a superfície de agentes; a questão de roteamento entre eles; Foundation Models para recursos in-app de LLM on-device; a distinção runtime vs tooling LLM; a síntese das três superfícies; o single source of truth pattern; Two MCP Servers para a integração com Xcode; hooks para desenvolvimento Apple; Live Activities; o contrato do runtime watchOS; internals do SwiftUI; o modelo mental espacial do RealityKit; disciplina de schema do SwiftData; padrões Liquid Glass; envio multi-plataforma; sobre o que me recuso a escrever. O hub está na Apple Ecosystem Series. Para contexto mais amplo de iOS-com-agentes-AI, veja o iOS Agent Development guide.

FAQ

Como decido 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, focus engine) e custo de manutenção específico. Se a resposta for “também funciona lá”, a escolha certa geralmente é pular o alvo.

Devo entregar para todas as seis plataformas Apple?

Geralmente não. A maioria dos apps se beneficia de uma a três plataformas. Quatro a seis é incomum e conquistado apenas quando cada plataforma genuinamente adiciona valor para o usuário (Return alcança todas as seis porque a sessão de mindfulness cabe no Watch, o timer cabe no iPad e Mac como companions de mesa, visionOS cabe num modo imersivo, e TV cabe num 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 cabem, e a escolha certa é pular esses alvos.

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

Tratar iPad como “iPhone com mais pixels”. Um app SwiftUI iPhone solto no iPad sem adaptação de size class produz uma UI de coluna única esticada que usuários do 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 multi-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 de sessão específicos (self-care, mindfulness, physical-therapy, alarm para WKExtendedRuntimeSession, mais workout-processing para HKWorkoutSession) 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 watchOS do cluster cobre o contrato em detalhe.

Como funciona a sincronização cross-device através da matriz de plataformas?

Três substratos: NSUbiquitousKeyValueStore para pequeno estado chave-valor (configurações, última-aba-selecionada, estado de timer cross-device),⁵ arquivos do iCloud Drive para pontes cross-process (o padrão Get Bananas + servidor MCP), SwiftData para estado in-process. 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.

References