O checklist de envio de apps: todos os ativos para as duas lojas (2026)

Você já construiu o app. Agora as duas lojas querem uma pilha de ativos e respostas antes de deixar passar, e as duas pilhas são diferentes. Este é o superconjunto: todos os ativos e campos que a App Store Connect e o Google Play Console pedem, agrupados por loja, com as regras de build de 2026 que bloqueiam um upload antes mesmo de a revisão começar.

Já temos um checklist só de capturas de tela (link no final). Este aqui é a lista mais ampla — capturas de tela são um único item aqui, ao lado de ícones, feature graphics, texto da ficha, formulários de privacidade, classificações etárias e os requisitos de build que travam o próprio upload.

Requisitos e prazos mudam. Trate qualquer regra datada abaixo como um ponteiro para confirmar na documentação oficial da loja no dia do envio, não como um fato fixo.

Passo 0: as duas contas de desenvolvedor

Você não consegue enviar nada sem uma conta em cada loja, e os preços seguem modelos diferentes:

• Apple Developer Program — US$ 99 por ano (cobrado na moeda local). É uma assinatura recorrente. Se deixar vencer, seus apps saem da App Store até você renovar.
• Google Play Console — US$ 25, pago uma única vez no cadastro. Pagamento único, não reembolsável, sem renovação.
• Verificação de identidade nos dois casos. Contas pessoais e de organização passam por verificação. Contas de organização no Google precisam de um número D-U-N-S; a Apple verifica a entidade legal para inscrição de organização. Reserve alguns dias para isso antes de planejar o lançamento.

Apple: o que a App Store Connect pede

O build:

• Binário do app construído com um SDK atual. Desde abril de 2025, apps iOS e iPadOS precisam ser construídos com o iOS 18 SDK (Xcode 16) ou mais recente para fazer upload. A Apple anunciou que, a partir de 28 de abril de 2026, os uploads vão precisar do iOS 26 SDK ou mais recente — confirme qual SDK está em vigor na sua data de envio.
• Ícone do app dentro do build. A Apple extrai o ícone do catálogo de assets do app; não há upload separado de ícone na App Store Connect. Um ícone ausente ou malformado falha na validação do upload.
• Bundle ID único, assinatura válida e respostas de conformidade de exportação. As perguntas sobre criptografia/exportação aparecem no upload — a maioria dos apps responde com uma isenção padrão, mas você precisa responder.

Ativos visuais:

• Capturas de tela para o iPhone de 6.9". Pelo menos uma, até dez. Tamanhos aceitos incluem 1320 × 2868, 1290 × 2796 e 1260 × 2736 (retrato). A Apple redimensiona esse conjunto automaticamente para iPhones menores, então o conjunto de 6.5" só é necessário se você pular totalmente o de 6.9".
• Capturas de tela de iPad se o app suportar iPad. O conjunto de 13" é 2064 × 2752 ou 2048 × 2732 (retrato). Obrigatório quando o app roda em iPad.
• Vídeo App Preview opcional por tamanho de dispositivo, de 15 a 30 segundos.

Texto da ficha:

• Nome do app (até 30 caracteres) e subtítulo (até 30).
• Palavras-chave — um único campo de 100 caracteres separado por vírgulas, que nunca aparece para o usuário, mas influencia a busca.
• Descrição (até 4.000 caracteres) e texto promocional (até 170, editável sem um novo build).
• URL de suporte, e uma URL de marketing se você quiser.

Jurídico, privacidade e classificação:

• URL da política de privacidade. Obrigatória para todo app.
• Respostas de App Privacy — o "rótulo nutricional". Você declara quais dados seu app e seus SDKs de terceiros coletam e como são usados. Essas respostas são obrigatórias para enviar e aparecem como o rótulo de privacidade na página do seu produto.
• Classificação etária. Respondida por meio de um questionário. A Apple passou para um sistema de classificação etária mais granular (com faixas 13+, 16+ e 18+) que aparece em dispositivos com iOS 26 ou mais recente, então revise suas respostas se você classificou um app pela última vez no esquema antigo.
• Categoria principal (e secundária opcional), além de um caminho de exclusão de conta dentro do app, se o app suportar criação de conta.

Google: o que o Play Console pede

O build:

• Um Android App Bundle (.aab), não um APK, para apps novos.
• Nível da API alvo. Apps novos e atualizações precisam atualmente ter como alvo o Android 15 (API nível 35) ou superior. O Google já disse que, a partir de 31 de agosto de 2026, apps novos e atualizações precisarão ter como alvo o Android 16 (API nível 36) — verifique o nível em vigor no momento do envio.
• Build de release assinado, normalmente via Play App Signing.

Ativos visuais:

• Ícone do app — 512 × 512 px, PNG de 32 bits, com menos de 1 MB.
• Feature graphic — 1024 × 500 px, JPEG ou PNG de 24 bits sem alfa. É um ativo obrigatório na ficha do Play, sem equivalente na Apple, e é o banner exibido no topo da sua ficha.
• Pelo menos 2 capturas de tela de celular (até 8). JPEG ou PNG de 24 bits, cada lado entre 320 e 3.840 px, proporção 16:9 ou 9:16. Capturas de tela de tablet e outros formatos são opcionais, a menos que você mire nesses dispositivos.
• Vídeo promocional opcional como URL do YouTube.

Texto da ficha:

• Nome do app (até 30 caracteres).
• Descrição curta (até 80) — a primeira linha que o usuário lê.
• Descrição completa (até 4.000).

Jurídico, privacidade e classificação:

• URL da política de privacidade. Obrigatória.
• Formulário de segurança de dados. O equivalente do Google ao rótulo de privacidade da Apple — você declara quais dados coleta, compartilha e como são tratados. Obrigatório antes de publicar, e precisa corresponder ao comportamento real do app.
• Questionário de classificação de conteúdo (IARC). Gera classificações etárias específicas por região a partir das suas respostas.
• Categoria do app, além de declarações de público-alvo e anúncios. Se parte do público for de crianças, requisitos adicionais se aplicam.

As regras de 2026 que rejeitam um build antes da revisão

Não são sobre polimento — elas bloqueiam o upload ou o lançamento diretamente, então vale a pena confirmar primeiro:

• O SDK mínimo da Apple. Os uploads precisam do iOS 18 SDK (Xcode 16) desde abril de 2025, com o iOS 26 SDK se tornando o piso por volta de 28 de abril de 2026, segundo o anúncio da Apple. Construa com um SDK antigo e a App Store Connect rejeita o binário no upload.
• O nível de API alvo do Google. Apps novos e atualizações têm hoje como alvo o Android 15 (API 35), mudando para o Android 16 (API 36) a partir de 31 de agosto de 2026, conforme o cronograma anunciado pelo Google. Um nível alvo muito baixo bloqueia o lançamento.
• O portão de teste fechado do Google para contas pessoais. Contas de desenvolvedor pessoais criadas após 13 de novembro de 2023 precisam rodar um teste fechado com pelo menos 12 testadores inscritos por 14 dias consecutivos antes de poderem solicitar acesso de produção. (O Google reduziu esse número de 20 testadores no fim de 2024.) Contas de organização verificadas são isentas. Esse é o que mais surpreende desenvolvedores solo — adiciona no mínimo duas semanas entre "o app está pronto" e "o app está no ar", então comece o teste fechado cedo.

O pré-voo compartilhado (as duas lojas)

Algumas verificações valem para os dois lados e são fáceis de pular na pressa de lançar:

• Legendas de captura de tela no idioma de cada localidade. Legendas em inglês numa ficha em alemão ou japonês são sinalizadas. O idioma da legenda e a localidade da ficha precisam coincidir.
• Ativos e texto condizem com o app. Se uma captura de tela ou descrição mostra um recurso, o app publicado precisa realmente tê-lo. As duas lojas rejeitam metadados que exageram o app.
• Nenhum preço ou URL fora da loja embutido nas capturas de tela. Preços pertencem à página da loja, não à arte; overlays do tipo "visite nosso site" atraem rejeições.
• Declarações de privacidade condizem com a realidade. O rótulo de privacidade da Apple e o formulário de segurança de dados do Google precisam refletir o que seu código e SDKs realmente fazem.
• Uma conta de teste funcional, se o app estiver atrás de login, entregue ao revisor nas notas de revisão.

Onde o Mokbi entra

A maior parte deste checklist é responsabilidade sua — a conta, o build, as respostas de privacidade, as classificações. O Mokbi cobre os ativos visuais e de texto, que é a parte que mais consome horas quando você faz isso à mão para duas lojas e vários idiomas.

• Os ativos visuais. Ele produz as capturas de tela para as duas lojas nos tamanhos exigidos, e a feature graphic do Play, a partir de um único projeto — então você não fica recortando a mesma arte para cada classe de dispositivo.
• O texto da ficha. Ele redige seu nome, subtítulo, descrição e descrição curta, depois traduz toda a ficha para 50 idiomas para que cada localidade seja lançada com legendas e textos condizentes.
• Publicar a ficha finalizada. O Mokbi envia os ativos finalizados e o texto da loja por você: direto para o Google Play pela Play Developer API, e preparado na App Store Connect como uma versão pronta para você enviar. A Apple exige aquela etapa final de Submit e revisão de você — isso é uma regra da Apple, não um limite do Mokbi.

O objetivo não é substituir o checklist — é tirar dele as colunas de ativos e tradução, para que o resto seja uma tarde mais curta.

O que ler a seguir

• Requisitos da ficha do Google Play, ativo por ativo
• O que você pode mudar sem uma nova versão
• O checklist só de capturas de tela antes de enviar

Abrir o editor →