Publicar na App Store e no Google Play: o checklist completo 2026

Construir o app é a parte que todo mundo planeja. Publicá-lo é a que surpreende, porque é sobretudo trabalho administrativo com regras rígidas e ciclos de resposta assíncronos. Uma recusa que você poderia ter evitado em dez minutos custa uma semana de calendário. Este guia percorre as duas lojas na ordem em que você realmente precisa: contas, materiais, declarações, envio, revisão e o que fazer no dia seguinte ao lançamento.

Antes de tudo: as duas contas

As duas lojas exigem uma conta de desenvolvedor paga, e as duas demoram para ativar. Comece esta etapa antes de o app estar pronto, não depois.

Uma decisão que vale tomar cedo: registre em nome da sua empresa, não no seu nome pessoal. Mover um app entre contas depois é possível, mas trabalhoso, e um nome de pessoa física exibido publicamente na ficha soa amador para clientes corporativos.

Os materiais que vão pedir

As duas lojas pedem praticamente o mesmo material, com tamanhos diferentes e diferente tolerância a improviso. Prepare tudo de uma vez em vez de descobrir cada exigência no meio do envio.

• O ícone. Um quadrado em alta resolução, sem transparência e sem cantos arredondados feitos por você: a máscara é aplicada pelas lojas. Evite texto pequeno, ilegível em tamanho real.
• As capturas de tela. Vários tamanhos de aparelho, incluindo pelo menos um telefone grande. São a maior alavanca da taxa de instalação: anote-as com um benefício curto em vez de subir capturas cruas.
• Título e subtítulo. Curtos, e indexados pela busca da loja. Coloque no título a palavra-chave que as pessoas digitam, não uma frase de marca criativa.
• A descrição. Só as duas primeiras linhas são realmente lidas. Comece pelo que o app faz pelo usuário, não pela história da sua empresa.
• Imagem de destaque (Google Play). Um banner largo exibido em vários lugares. Mantenha o texto essencial longe das bordas, que são cortadas.
• Questionário de classificação etária. Responda com honestidade. Uma incoerência entre suas respostas e o conteúdo real é o jeito mais certo de ser removido depois do lançamento.

Privacidade: o que faz os apps serem recusados

As duas lojas exigem hoje um inventário explícito e estruturado dos dados que você coleta e para quê. A Apple chama de rótulos de privacidade; o Google, de seção Segurança de dados. São formulários distintos, com vocabulário distinto, e ambos precisam corresponder ao que seu app realmente faz.

• Uma URL de política de privacidade acessível. Obrigatória nas duas, no ar antes do envio, e descrevendo o seu app de verdade em vez de um modelo genérico.
• Um inventário de dados exato. Liste cada categoria coletada, inclusive pelos seus SDKs de analytics ou de relatório de falhas. O que bibliotecas de terceiros coletam por você conta como seu.
• Exclusão de conta. Se o usuário pode criar conta no app, você precisa oferecer uma forma de excluí-la, acessível de dentro do app. É uma das recusas tardias mais comuns.
• Permissão de rastreamento no iOS. Se você rastreia usuários por apps ou sites de outras empresas, precisa pedir autorização pelo aviso do sistema. Fazer sem esse aviso leva à remoção.

Trilhas de teste: nunca envie direto para produção

As duas lojas oferecem um caminho de pré-produção, gratuito nos dois casos. Use: um bug encontrado por dez testadores não custa nada, e o mesmo bug encontrado por um revisor custa um ciclo de revisão.

• TestFlight (Apple). Distribuição quase imediata para testadores internos, ou para testadores externos após uma revisão mais leve. Os builds expiram em 90 dias.
• Testes internos, fechados e abertos (Google). O teste interno é quase instantâneo. Um teste fechado com um grupo pequeno merece pelo menos uma semana antes da produção, e contas de desenvolvedor pessoais novas podem ser obrigadas a realizá-lo.

Qualquer que seja a trilha, teste no mínimo num Android pequeno e antigo e num iPhone recente. Esses dois cobrem a maior parte das surpresas de layout e desempenho.

O envio, passo a passo

• 1. Criar a ficha do app. Reserve o nome e o identificador de bundle ou pacote. Esse identificador é definitivo: não muda após a publicação, só é possível publicar um app novo.
• 2. Enviar um build assinado. A Apple exige um arquivo assinado enviado a partir do macOS. O Google exige um Android App Bundle e uma chave de assinatura que você não pode perder: ative o Play App Signing para que o Google guarde uma cópia.
• 3. Preencher a ficha da loja. Título, descrição, capturas, categoria, contato e URL de suporte.
• 4. Completar as declarações. Privacidade, segurança de dados, classificação etária, publicidade, conformidade de exportação e o questionário de permissões se você usar alguma sensível.
• 5. Dar aos revisores uma conta funcional. Se o app tem login, forneça credenciais de teste e, se preciso, uma nota curta explicando como chegar à funcionalidade principal. Esquecer isso é a causa número um de recusas inúteis.
• 6. Enviar e definir a estratégia de lançamento. Escolha publicação manual se quiser coordenar uma data, e use lançamento gradual no Google Play para que um build defeituoso atinja 5% dos usuários em vez de todos.

Os motivos de recusa que você vai encontrar de verdade

Recusas são normais, inclusive para equipes experientes. Quase todas cabem em um punhado de categorias.

• O revisor não conseguiu entrar. Credenciais de demonstração ausentes ou expiradas, ou um login que exige um código enviado ao seu telefone.
• Links quebrados ou travamentos. Uma URL de suporte fora do ar ou um crash na versão do aparelho do revisor. Teste todos os links da ficha antes de enviar.
• «Funcionalidade insuficiente». A Apple recusa apps que são apenas um site embrulhado sem valor nativo. Se você entrega uma WebView, acrescente funções reais do aparelho e comportamento offline.
• Pagamentos fora da loja. Vender conteúdo digital consumido dentro do app geralmente exige compra integrada. Bens físicos e serviços do mundo real, não.
• Declaração de privacidade incoerente. Você declara não coletar nada, mas um SDK de analytics captura um identificador de aparelho.
• Problemas de metadados. Capturas que já não correspondem ao app, nomes de concorrentes na descrição, ou um texto provisório que ficou lá.

Ao ser recusado, leia o número exato da diretriz citada, corrija apenas aquilo e responda no centro de resolução com uma explicação curta e factual. Discutir raramente ajuda; uma resposta precisa quase sempre ajuda.

Depois do lançamento: os primeiros trinta dias

Estar no ar é o começo do trabalho, não o fim. O primeiro mês determina como as lojas classificam você e se os primeiros usuários ficam.

• Acompanhe a taxa de travamentos por aparelho. As duas consoles reportam. Acima de cerca de 1% das sessões, sua classificação e suas avaliações sofrem.
• Responda a cada avaliação, rápido. Respostas públicas mudam visivelmente como a ficha é lida, e uma reclamação resolvida costuma virar uma nota melhor.
• Itere na ficha, não só no app. Trocar a primeira captura ou o subtítulo move a taxa de instalação mais do que uma funcionalidade nova.
• Publique uma atualização pequena a cada poucas semanas. Atualidade é sinal de classificação, e um ritmo constante torna os prazos de revisão previsíveis.
• Traga seu próprio tráfego. A busca da loja não vai descobrir você sozinha. Seu site, sua lista de e-mails e seus clientes atuais são o canal de lançamento.

Onde a Cadrant entra

A Cadrant atua no que antecede o envio: colocar um app real e funcional diante de usuários rápido o bastante para você saber o que merece ser publicado. Você descreve suas telas, seus dados e seus papéis de usuário em linguagem simples, itera sobre um app vivo em horas em vez de meses, e o banco de dados continua no seu próprio projeto Supabase. Quando o produto se provou com usuários reais, você entra no processo das lojas com um escopo estável em vez de adivinhar.

Essa ordem importa. A maioria de quem publica pela primeira vez envia um escopo que ninguém testou e depois gasta os ciclos de revisão corrigindo problemas de produto em vez de problemas de loja.

Resumindo

Publicar é um projeto administrativo com dependência de código. Abra as duas contas de desenvolvedor cedo, prepare ícone, capturas, descrição, política de privacidade e declarações de dados numa única passada, rode uma trilha de teste real antes da produção e dê aos revisores uma conta funcional com instruções claras. Feito isso, a revisão costuma ser a parte fácil.