Do conceito em SwiftUI à App Store em semanas

Há um tipo específico de atraso que afeta projetos iOS: o recurso que deveria ser lançado “em algumas semanas” e que ainda está em desenvolvimento três meses depois porque o escopo continuou se expandindo e o processo de submissão acabou tendo mais etapas do que o esperado. Na realidade, lançar um aplicativo SwiftUI rapidamente não é uma questão de velocidade — é uma questão de decidir cedo o que o aplicativo não vai fazer, e então não questionar essa decisão quando a tentação de adicionar mais um recurso aparecer.

Lançamos vários aplicativos SwiftUI em prazos curtos. O processo é repetível, mas requer disciplina quanto ao escopo, um entendimento claro do pipeline de submissão da Apple e a disposição de lançar algo bom, mas não completo. Veja como isso funciona na prática.

A decisão de escopo acontece antes do primeiro commit

O trabalho mais importante em um ciclo de lançamento iOS rápido acontece antes de qualquer código ser escrito. A questão não é “o que este aplicativo deve fazer” mas “qual é o único problema que este aplicativo resolve para o usuário na versão um?” Todo recurso que não está diretamente conectado a esse problema é material para a versão dois.

Isso é mais difícil do que parece porque quase tudo parece relevante quando você está projetando a partir de princípios básicos. Notificações parecem importantes. Recursos sociais parecem importantes. Painéis detalhados de análise de dados parecem importantes. Mas na realidade, os usuários não podem avaliar nenhum desses recursos até que tenham usado a função central do aplicativo e a tenham achado valiosa. Um aplicativo que faz uma coisa bem e é lançado em quatro semanas gera feedback mais útil do que um aplicativo que faz seis coisas de forma aceitável e é lançado em quatro meses.

A ferramenta prática para isso é uma lista de duas colunas escrita antes do início do desenvolvimento: o que está no MVP e o que é explicitamente adiado. A lista de recursos adiados não é uma lista de tarefas pendentes — é um mecanismo que impõe disciplina. Para cada recurso proposto durante o desenvolvimento, é preciso avaliar se ele deve ir para a lista de recursos adiados em vez do sprint atual. A maioria deles deveria.

As primeiras duas semanas: apenas as telas principais

Um aplicativo SwiftUI com um único propósito claro normalmente precisa de três a cinco telas para funcionar: um fluxo de introdução ao app, uma ou duas telas para as interações principais, e uma tela de configurações ou conta. Nas primeiras duas semanas, essas telas devem estar funcionalmente completas — elas permitem que os usuários façam o que precisam fazer, com dados reais, na ordem correta. Não precisam estar refinadas. As animações podem ser padrão do sistema. A tipografia pode ser o que o sistema fornecer. Os estados de erro podem ser alertas de texto simples.

As decisões arquitetônicas que importam nessa fase são as que são difíceis de mudar depois: o modelo de navegação (NavigationStack, TabView ou um coordenador personalizado), a abordagem de gerenciamento de estado (usar @Observable do framework Observation ou ficar com ObservableObject), e a estratégia de persistência de dados (SwiftData, Core Data, UserDefaults para estado simples). Tomar essas decisões explicitamente e cedo — em vez de deixá-las se acumular organicamente — evita a situação na terceira semana em que metade do aplicativo usa um modelo de navegação e a outra metade usa outro.

Para aplicativos integrados a um backend Supabase, o fluxo de autenticação merece atenção particular nessa fase. As diretrizes de revisão de apps da Apple tratam essas questões como dois requisitos separados: aplicativos que permitem criar contas devem permitir que os usuários excluam a conta dentro do aplicativo (diretriz 5.1.1(v)), e aplicativos que usam login de terceiros ou social, como Google Sign-In, para a conta principal também devem oferecer uma opção de login equivalente com foco em privacidade, que na prática costuma ser o Sign in with Apple (diretriz 4.8). Se o seu aplicativo usa apenas seu próprio sistema de autenticação por e-mail/senha via Supabase, o Sign in with Apple não é obrigatório, mas o fluxo de exclusão de conta precisa estar no MVP — não porque os usuários o usarão no primeiro dia, mas porque a revisão de apps rejeitará o aplicativo sem ele. Se adicionar um login social, planeje a opção de login equivalente ao mesmo tempo.

Terceira e quarta semanas: refinamento e TestFlight

A terceira semana é quando o aplicativo começa a parecer um produto real. É aqui que você aborda estados de carregamento (não apenas “mostrar um indicador de atividade”, mas “mostrar um indicador que faz a espera parecer apropriada”), estados vazios (o que o aplicativo mostra quando ainda não há dados) e estados de erro (o que acontece quando uma chamada de rede falha). Esses estados não são mero refinamento — são a experiência para novos usuários, que chegam sem dados e ocasionalmente têm problemas de rede.

A distribuição pelo TestFlight deve começar na terceira semana, não na quarta. A razão é que o primeiro build que você enviar terá problemas que você não antecipou. O App Store Connect valida o binário antes de disponibilizá-lo para teste e detecta problemas — permissões (entitlements) ausentes, combinações de perfil de provisionamento incorretas, chaves Info.plist obrigatórias mas ausentes — que o build local do Xcode não detecta. Encontrar esses problemas na terceira semana lhe dá tempo para corrigi-los antes da submissão real. Encontrá-los na véspera do lançamento não.

O feedback do TestFlight nessa fase é mais útil para identificar dificuldades de navegação e falta de indicações de como interagir com a interface, não para pedidos de recursos. Pergunte aos testadores: “Houve alguma coisa que você tentou fazer e não conseguiu descobrir como fazer?” em vez de “Quais recursos você gostaria de ver?” A segunda pergunta gerará uma lista que adicionaria meses ao cronograma.

O processo de envio à App Store

O processo de submissão na App Store tem mais etapas do que os iniciantes esperam, e cada etapa tem o potencial de bloquear o lançamento. Trabalhar nelas com antecedência — em vez de iniciá-las quando o aplicativo está com o código concluído — evita que a semana final se torne uma correria.

As capturas de tela são obrigatórias antes da submissão e devem corresponder a uma das dimensões em pixels aceitas para cada tamanho de tela. Em outubro de 2026, o App Store Connect exige capturas de iPhone para a categoria de telas de 6,9 polegadas (por exemplo, iPhone 16 Pro Max), ou para a de 6,5 polegadas (por exemplo, iPhone 14 Plus) se você não fornecer as de 6,9 polegadas, além de capturas de iPad de 13 polegadas (por exemplo, iPad Pro (M4) ou iPad Pro de 12,9 polegadas (6ª geração)) se o aplicativo funcionar no iPad. Gerá-las no simulador é simples, mas demorado se você deixar para o último dia. Uma configuração simples do Fastlane snapshot pode automatizar isso.

A seção de privacidade do app no App Store Connect requer que você declare todos os tipos de dados que seu aplicativo coleta, para que eles são usados e se estão vinculados à identidade do usuário. Isso não é metadado opcional — a submissão falha se estiver incompleto. Se o seu aplicativo usa Supabase com autenticação, você coleta no mínimo endereços de e-mail e identificadores de usuário, ambos exigindo declaração. SDKs de terceiros e ferramentas de análise de dados somam-se a essa lista. Mapear com precisão sua coleta de dados antes da submissão evita ter que atualizar esses detalhes após o lançamento.

A Apple informa que normalmente analisa 50% das submissões em menos de 24 horas e 90% em menos de 48 horas; é possível solicitar uma revisão acelerada em circunstâncias excepcionais, como a correção de um bug crítico ou um lançamento vinculado a um evento. A revisão é feita por uma pessoa que avalia o aplicativo à luz das diretrizes da Apple. As razões mais comuns de rejeição na primeira submissão são: funcionalidade de conta ausente (exclusão de conta dentro do aplicativo ou uma opção de login equivalente junto com o login social), credenciais de uma conta de demonstração não fornecidas para aplicativos com login, e travamentos em casos extremos que os testadores não encontraram, mas os revisores encontraram.

O que cortar e como cortar

A parte mais difícil de um ciclo de lançamento rápido é fazer os cortes parecerem intencionais em vez de apressados. Os usuários conseguem distinguir entre um aplicativo que é deliberadamente simples e um que está inacabado. A diferença está principalmente em quão completo é o que foi incluído — cada tela que existe deve estar completa — em vez do número de telas que existem.

Cortes práticos que raramente prejudicam um primeiro lançamento: notificações push (complexas de configurar corretamente, e os usuários precisam confiar no aplicativo antes que as notificações sejam bem-vindas), recursos sociais (seguir, compartilhar, rankings — úteis em escala, uma distração no lançamento), configurações avançadas de personalização (a maioria dos usuários nunca muda os padrões) e qualquer recurso que requer uma infraestrutura de backend significativa de que o MVP ainda não precisa.

Cortes práticos que prejudicam um primeiro lançamento: tratamento de erros (um aplicativo que trava quando uma conexão de rede excede o tempo limite frustra os usuários permanentemente), estados de carregamento (um aplicativo que congela sem feedback visual parece quebrado) e funções básicas de gerenciamento de conta (os usuários precisam ser capazes de redefinir sua senha e excluir sua conta, mesmo no MVP).

Após o lançamento: as primeiras duas semanas são as mais importantes

As primeiras duas semanas após o lançamento são o período em que as avaliações da App Store são mais frágeis. Um conjunto inicial de avaliações de uma estrela por causa de um travamento que não apareceu nos testes é desproporcionalmente prejudicial à avaliação de longo prazo do aplicativo. O Instruments e o organizador de travamentos do Xcode devem ser verificados diariamente na primeira semana. Uma versão de correção que resolva qualquer travamento crítico deve ser submetida dentro de 24 horas da identificação — a revisão de apps oferece um caminho acelerado para correções de travamento.

O impulso de lançar imediatamente os recursos adiados após o lançamento deve ser contido por pelo menos duas semanas. Entender como os usuários realmente interagem com a experiência central antes de adicionar complexidade é mais valioso do que demonstrar ritmo de entrega. Os recursos da versão dois na lista de recursos adiados serão melhor projetados após duas semanas de observação de padrões de uso real do que teriam sido se construídos em paralelo com o lançamento.