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

Construir a app é a parte que todo mundo planeia. Publicá-lo é a que surpreende, porque é sobretudo trabalho administrativo com regras rígidas e ciclos de resposta assíncronos. Uma recusa que poderia ter evitado em dez minutos custa uma semana de calendário. Este guia percorre as duas lojas na ordem em que 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 programador paga, e as duas demoram para ativar. Comece esta etapa antes de a app estar pronto, não depois. Vai precisar de uma subscrição do Apple Developer Program e de uma conta no Google Play Console.

Uma decisão que vale tomar cedo: registe em nome da sua empresa, não no seu nome pessoal. Mover uma 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 si: a máscara é aplicada pelas lojas. Evite texto pequeno, ilegível em tamanho real.
• As capturas de ecrã. Vários tamanhos de dispositivo, 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 pesquisa 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 a app faz pelo utilizador, 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 as suas respostas e o conteúdo real é o jeito mais certo de ser removido depois do lançamento.

Privacidade: o que faz as apps serem recusados

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

• Uma URL de política de privacidade acessível. Obrigatória nas duas, no ar antes do envio, e descrevendo a sua app a sério 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 si conta como o seu.
• Eliminação de conta. Se o utilizador pode criar conta na app, precisa oferecer uma forma de excluí-la, acessível de dentro da app. É uma das recusas tardias mais comuns.
• Permissão de rastreamento no iOS. Se rastreia utilizadores por apps ou sites de outras empresas, precisa pedir autorização pelo aviso do sistema. Fazer sem este 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 programador 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. Estes dois cobrem a maior parte das surpresas de layout e desempenho.

O envio, passo a passo

• 1. Criar a ficha da app. Reserve o nome e o identificador de bundle ou pacote. Este identificador é definitivo: não muda após a publicação, só é possível publicar uma app nova.
• 2. Enviar um build assinado. A Apple exige um ficheiro assinado enviado a partir do macOS. A Google exige um Android App Bundle e uma chave de subscrição que não pode perder: ative o Play App Signing para que a Google guarde uma cópia.
• 3. Preencher a ficha da loja. Título, descrição, capturas, categoria, contacto 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 usar alguma sensível.
• 5. Dar aos revisores uma conta funcional. Se a 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 utilizadores em vez de todos.

Os motivos de recusa que vai encontrar a sério

Recusas são normais, inclusive para equipas experientes. Quase todas cabem num 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 dispositivo 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 entrega uma WebView, acrescente funções reais do dispositivo e comportamento offline.
• Pagamentos fora da loja. Vender conteúdo digital consumido dentro da app geralmente exige compra integrada. Bens físicos e serviços do mundo real, não.
• Declaração de privacidade incoerente. Declara não coletar nada, mas um SDK de analytics captura um identificador de dispositivo.
• Problemas de metadados. Capturas que já não correspondem à 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 utilizadores ficam.

• Acompanhe a taxa de travamentos por dispositivo. As duas consoles reportam. Acima de cerca de 1% das sessões, a sua classificação e as 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ó na 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 o seu próprio tráfego. A pesquisa da loja não vai descobrir sozinha. O seu site, a sua lista de e-mails e os seus clientes atuais são o canal de lançamento.

Onde a Cadrant entra?

A Cadrant atua no que antecede o envio: colocar uma app real e funcional diante de utilizadores rápido o bastante para si saber o que merece ser publicado. Descreve os seus ecrãs, os seus dados e os seus papéis de utilizador em linguagem simples, itera sobre uma app viva em horas em vez de meses, e a base de dados continua no seu próprio projeto Supabase. Quando o produto se provou com utilizadores reais, entra no processo das lojas com um âmbito estável em vez de adivinhar.

Esta ordem importa. A maioria de quem publica pela primeira vez envia um âmbito 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 programador 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.