Alexgub84/publicação-na-loja

O que publicação-na-loja faz?

Este procedimento foi testado pela última vez no Google Play Console real e no App Store Connect em 2026-11-08. Ambas as consolas mudam os ecrãs, nomes de campos e navegação sem aviso prévio — se um passo abaixo não corresponder ao que vê, abra uma issue neste repositório em vez de adivinhar, e envie um PR com a correção se encontrar uma.

0. Decida qual caminho está a percorrer

Situação	Ir para
O aplicativo nunca foi submetido, sem registo em nenhuma consola	§1, depois §2, §3, §4
O aplicativo já está listado, uma nova compilação precisa ser lançada	§5 (o caminho repetido)
Dúvida sobre conta (individual vs organização, transferência, nome do pacote)	§6
O revisor não consegue iniciar sessão, ou o aplicativo foi rejeitado	§7

Regra que se aplica em todo o lado: cada carregamento precisa de notas de lançamento em todos os idiomas listados em que é enviado. Nunca deixe uma caixa "O que há de novo" vazia — uma caixa vazia parece uma compilação não testada para um revisor.

1. Lista de verificação de configuração inicial (ambas as lojas)

Faça por ordem; cada uma desbloqueia a próxima.

1. As contas de desenvolvedor existem e estão verificadas. O aplicativo deve ser publicado a partir da conta que realmente possui o produto — o editor de registo, não uma conta partilhada ou de agência usada em aplicativos não relacionados. A Apple em particular rejeita aplicativos que parecem ter vindo de um modelo comercializado ou serviço de geração de aplicativos quando submetidos sob uma conta que contém muitos produtos não relacionados, e separadamente (diretriz 5.2.1) espera que o proprietário da PI seja o que submete. Veja §6 para a decisão individual vs organização.
2. As páginas legais estão no domínio de produção: uma política de privacidade, termos de uso e uma página de eliminação de conta se o aplicativo permitir registo. Ambas as lojas pedem estes URLs; o formulário de Segurança de Dados do Google liga diretamente a página de eliminação. Obtenha a aprovação do texto legal de quem possui o produto antes de usá-lo numa submissão — é uma decisão de negócio, não técnica.
3. Um ícone de aplicativo real, não predefinido do framework — ambas as lojas rejeitam ou sinalizam um ícone predefinido não alterado como de baixa qualidade. Ativos necessários: o ícone adaptativo/primeiro plano dentro do binário, um ícone do Play de 512×512, um gráfico de funcionalidade do Play de 1024×500 e um ícone da Apple de 1024×1024 no catálogo de ativos (sem transparência — a Apple achata-o, geralmente para preto).
4. Uma conta de demonstração para revisão, se o aplicativo exigir início de sessão. Precisa de: um identificador fixo (telefone, e-mail ou nome de utilizador) com um código único fixo ou palavra-passe que é honrado apenas para esse identificador, um estado de demonstração semeado que o revisor possa realmente exercitar e sem efeitos secundários de saída (sem SMS real, sem cobrança real). Guarde a credencial fora das páginas da consola — nunca como texto simples colado nas notas de Revisão do Aplicativo, onde se torna um registo permanente e amplamente legível. Verifique se o início de sessão funciona com a compilação exata que está a ser submetida, sempre, imediatamente antes de submeter.
5. Um inventário de dados: um documento (no repositório, numa wiki, onde quer que a equipa mantenha especificações) listando cada tipo de dados que o aplicativo coleta, porquê e através de qual SDK. O formulário de Segurança de Dados do Google e o formulário de Privacidade do Aplicativo da Apple são preenchidos A PARTIR deste documento, nunca de memória — e sempre que o aplicativo ganha uma nova permissão ou um novo SDK de análise/diagnóstico, o inventário muda na mesma alteração que adiciona a permissão, e ambos os formulários são refeitos antes da próxima submissão. Uma incompatibilidade entre o que os formulários dizem e o que o binário realmente faz é um motivo de rejeição comum e evitável.
6. Google Play — Criar aplicativo, depois percorrer "Configurar o seu aplicativo" de cima a baixo: URL da política de privacidade, Acesso ao aplicativo (público, ou restrito com a conta de revisão e instruções), declaração de anúncios, questionário de classificação de conteúdo (respondido com verdade a partir do comportamento real do aplicativo), público-alvo e idade, declaração de aplicativos governamentais, declaração de funcionalidades financeiras, declaração de saúde, Segurança de Dados (a partir do inventário), declaração de ID de publicidade. Aceite a Assinatura do Aplicativo Play para que o Google detenha a chave de assinatura do aplicativo e a chave de carregamento permaneça substituível. Preencha a listagem principal da loja (nome, descrições, ícone, gráfico de funcionalidade, pelo menos 2 capturas de ecrã de telemóvel). Depois crie um segmento de teste fechado e um lançamento antes de tocar na produção.
7. Apple — registe o ID do Aplicativo explícito, crie o registo do aplicativo no App Store Connect (nome, SKU, idioma principal), preencha Informações do Aplicativo (categoria, direitos de conteúdo, classificação etária), Privacidade do Aplicativo (a partir do inventário), Preços e disponibilidade, a página de versão (capturas de ecrã, descrição, palavras-chave ≤100 caracteres, URL de suporte, direitos de autor), Informações de Revisão do Aplicativo (instruções de início de sessão se necessário, contacto de revisão, notas) e escolha uma opção de lançamento (lançamento manual é a predefinição mais segura — coloca a decisão de "publicar" num clique separado e deliberado após a aprovação). Para compilações TestFlight, responda à pergunta de conformidade de exportação de cada vez, ou adicione ITSAppUsesNonExemptEncryption=false ao Info.plist uma vez se isso for verdade, para impedir que a pergunta se repita.
8. Submeta ambos cedo. A revisão leva horas a dias em cada loja, e a primeira revisão é geralmente onde os problemas reais surgem — planeie pelo menos uma rejeição e uma ressubmissão, especialmente na Apple.

2. Construir o pacote de lançamento

Qualquer que seja a cadeia de ferramentas — Flutter, React Native, Expo, ou um projeto nativo Swift/Kotlin — construa a partir de uma cópia limpa do commit exato que está a ser lançado, nunca a partir de um diretório de trabalho com alterações não consolidadas. Edições não consolidadas a vazar para um binário da loja são muito difíceis de notar depois do facto.

• Android: produza um AAB de lançamento assinado (nunca um APK para um carregamento na loja), com um número de compilação (versionCode ou equivalente) estritamente superior ao último enviado. Verifique se o nome do pacote incorporado no bundle corresponde ao que a conta Play de destino possui antes de carregar — um nome de pacote incompatível falha no passo de carregamento.
• iOS: arquive e exporte (ou carregue diretamente para o App Store Connect a partir do passo de arquivo), assinado sob a adesão correta ao Programa de Desenvolvedores Apple (a "equipa" a que os certificados do aplicativo e o registo do aplicativo pertencem), com um número de compilação estritamente superior ao último enviado e o identificador de bundle exato com que o registo do App Store Connect foi criado. A assinatura automática sob a equipa certa evita a maioria dos problemas de certificados.
• Ambos: aponte a compilação para a API/backend de produção, não para uma de teste ou local — verifique se isto está realmente incorporado no binário, não apenas passado como uma flag de compilação que pode silenciosamente cair para uma predefinição. Mantenha o iOS e o Android no mesmo número de compilação/versão onde o produto tem uma string de versão partilhada, para que uma conversa de suporte sobre "versão 2.3" signifique a mesma coisa em ambas as plataformas.

3. Capturas de ecrã

Apenas capturas reais — a diretriz 2.3.3 da Apple rejeita explicitamente mockups e composições de marketing apresentadas como capturas de ecrã. O padrão fiável é um teste de UI automatizado que executa o aplicativo real, inicia sessão com a conta de revisão contra um backend real (não simulado), navega para cada ecrã e captura o quadro — nunca uma foto de telemóvel segurado à mão de um simulador.

Tamanhos de dispositivo típicos a cobrir (verifique os requisitos atuais da loja antes de confiar nestes, eles mudam): um iPhone grande moderno (o requisito "maior" atual da Apple), um iPad se o aplicativo suportar iPad, e um telemóvel e/ou tablet Android representativo para o Play. A Apple deriva tamanhos de iPhone mais pequenos do conjunto maior automaticamente na maioria dos casos.

Escolha um conjunto pequeno (5-8 imagens) que conte a história do produto por ordem: uma vista de lista ou início, um ecrã estrutural principal, uma vista de unidade/detalhe individual, o fluxo de trabalho principal em progresso, um estado concluído/sucesso e definições se relevante. Evite ecrãs de início de sessão vazios e estados vazios — eles não dizem nada sobre o que o aplicativo faz.

Armadilhas conhecidas, independentes da cadeia de ferramentas:

• Uma compilação de depuração mostra frequentemente uma faixa ou marca de água de depuração visível — desligue-a antes de capturar.
• Uma sessão de simulador ou emulador pode manter um início de sessão anterior entre reinstalações; termine a sessão explicitamente dentro do teste, ou limpe o estado do simulador/emulador primeiro.
• Re-navegar para o ecrã "mesmo" com parâmetros diferentes às vezes não renderiza um ecrã com estado de forma limpa; navegue através de um ecrã pai entre capturas.
• Executar duas sessões de captura do mesmo diretório de projeto ao mesmo tempo tende a colidir em artefactos de compilação gerados; use cópias de trabalho separadas se estiver a executar em paralelo.

4. Fluxo de atualização (aplicativo já listado)

Veja §5 para a lista de verificação de lançamento repetido dedicada. A versão curta: uma nova compilação obtém um número de compilação estritamente superior ao último enviado, o diff do inventário de dados desde o último lançamento decide se os formulários de privacidade precisam de atualização, as notas de lançamento nunca são ignoradas e a conta de demonstração de revisão é reverificada no ambiente exato para o qual o novo binário aponta antes de cada submissão.

5. O caminho repetido — um lançamento quando o aplicativo já está online

Um lançamento = uma passagem por esta lista, de cima a baixo.

Pré-condições (pare se alguma destas falhar)

• O código que está a ser enviado está realmente implantado em produção, com quaisquer migrações de base de dados já aplicadas — uma implantação e uma migração não são o mesmo passo, e implantar antes de migrar (ou não migrar de todo) produz uma compilação que fala com um backend que não está pronto para ela.
• A conta de demonstração de revisão inicia sessão contra a produção e atinge o estado de demonstração que um revisor precisaria de ver.
• O diff do inventário de dados desde a última compilação enviada é verificado. Qualquer nova linha significa que os formulários de privacidade mudam ANTES de submeter, não depois de uma rejeição apontar isso.
• O slot de versão da Apple está livre. Se uma versão anterior estiver em "Lançamento do Desenvolvedor Pendente" ou ainda em revisão, o App Store Connect não lhe permitirá criar a próxima linha de versão de todo. Lance ou cancele a pendente primeiro — não há opção "segure esta, submeta a compilação mais recente em vez disso".
• A string de versão e o número de compilação estão decididos: número de compilação = último enviado + 1 em cada plataforma; a string de versão apenas aumenta para uma alteração que um utilizador notaria realmente.

Notas de lançamento

Escreva-as a partir do que realmente foi enviado (as alterações consolidadas desde o último lançamento), apenas itens visíveis para o utilizador, aproximadamente 4-8 marcadores, em todos os idiomas que a listagem suporta — verifique o que a listagem realmente tem antes de assumir que precisa de múltiplos idiomas; uma listagem com apenas um idioma configurado rejeitará um campo de notas de lançamento para um idioma que não tem. Na Apple, adicionar um idioma completamente novo a uma listagem é o seu próprio projeto (nome, subtítulo, descrição, palavras-chave e o seu próprio conjunto de capturas de ecrã) — nunca assuma que é apenas uma alteração de caixa de texto.

Capturas de ecrã

Apenas as refaça se os ecrãs realmente mudaram de uma forma que um comprador notaria. Caso contrário, deixe o conjunto existente em paz. Se substituir, substitua o conjunto inteiro na mesma ordem de antes em vez de anexar — a maioria das consolas limita o número de capturas de ecrã por listagem, então a substituição parcial arrisca atingir esse limite.

Consolas

Google Play: se o inventário mudou, atualize o formulário de Segurança de Dados primeiro. Depois: o segmento de teste ou produção relevante → criar um novo lançamento → carregar o AAB → notas de lançamento em todos os idiomas configurados → revisar o lançamento → iniciar o rollout (trate "iniciar rollout" como uma ação deliberada e confirmada — é o clique irreversível no fluxo do Play). Um rollout de produção pode ser escalonado por percentagem e pausado se algo parecer errado após alguns por cento.

Apple App Store Connect: anexe a nova compilação ao TestFlight primeiro (conformidade de exportação, "o que testar"), depois edite a página de versão existente (se a string de versão não mudou e a versão anterior ainda não foi lançada) ou crie uma nova versão (apenas possível quando nenhuma versão está atualmente estacionada em "Preparar para Submissão" — veja a pré-condição acima). Re-verifique se as Informações de Revisão do Aplicativo ainda estão precisas, re-verifique a Privacidade do Aplicativo se o inventário mudou, selecione a nova compilação, preencha "O que há de novo" e submeta para revisão. Trate "submeter para revisão" da mesma forma que o clique de rollout do Play — uma ação deliberada e confirmada, não algo para disparar automaticamente.

Manutenção de registos

Qualquer manutenção de registos que a equipa já tenha para lançamentos (um changelog, uma issue de lançamento, uma folha de cálculo) deve ter: os números de versão e compilação enviados, horários de carregamento, qual segmento/estado, quem confirmou o rollout ou submissão e o resultado da revisão uma vez conhecido. Aumente o ficheiro de versão do próprio projeto para corresponder ao que foi realmente enviado — uma incompatibilidade aqui é exatamente como o próximo lançamento reutiliza acidentalmente um número de compilação.

Nunca estacione uma versão preparada

Uma versão a estacionar em "Preparar para Submissão" no App Store Connect detém o único slot de versão disponível — nenhuma nova versão pode ser criada por baixo dela. Portanto: decida o destino de uma versão preparada na mesma sessão em que é preparada. Ou submeta-a, ou ainda não crie a linha.

Se uma compilação mais recente estiver pronta enquanto uma versão preparada mais antiga ainda estiver estacionada, não elimine a linha estacionada e não submeta a compilação desatualizada apenas para limpar o slot. Enquanto uma versão está em "Preparar para Submissão", a sua string de versão ainda é um campo editável — avance-a no lugar: mude a string de versão para a nova, anexe a nova compilação, substitua "O que há de novo". As capturas de ecrã, notas de revisão e respostas de privacidade transitam, então nada preparado é desperdiçado.

Uma compilação de teste (TestFlight) e uma submissão pública são decisões independentes — o segmento de teste interno do TestFlight em particular não precisa de revisão e de nenhuma linha de versão de todo, então "os testadores precisam de uma compilação hoje" nunca é uma razão para uma submissão pública ter de esperar, e uma submissão pública pendente nunca é uma razão para os testadores terem de esperar também.

6. Contas, transferências, nomes de pacotes

• Uma conta de desenvolvedor do Google Play pessoal criada após o corte da política (13 de novembro de 2023 à data desta redação — verifique a política atual) deve completar um teste fechado com um mínimo de...

[truncado para tradução]