Guideline 2.3.3: capturas recusadas pela Apple, como refazer
Por Mehdi Azizi
Publicado em , 8 min
Guideline 2.3.3: mais da metade das suas capturas precisa mostrar a tela real do app em uso. O que passa, o que é recusado e a correção sem novo build.
Uma recusa "Guideline 2.3.3 - Performance - Accurate Metadata" quer dizer que a Apple acha que suas capturas de tela não mostram o app sendo usado. A regra tem número: para cada tipo de aparelho, mais da metade das capturas precisa mostrar a tela real do app em uso. A recusa é sobre a página do app, não sobre o binário: você troca as capturas e reenvia o mesmo build.
Passei por isso em 27 de outubro de 2026 com o Vigie, meu app de acompanhamento de ASO. Minhas capturas mostravam cards de interface redesenhados em volta de um mascote, sem celular. A Apple recusou. Este guia mostra a mensagem que recebi, o que a Apple chama de "app in use", o que passa e o que não passa, e depois o checklist que eu sigo desde então. As regras citadas vêm das páginas oficiais da Apple, relidas em 3 de novembro de 2026.
A mensagem da Apple, palavra por palavra
A mensagem começa com o título da regra e depois nomeia o tamanho de aparelho em questão. No caso do Vigie, a frase que trazia a recusa era esta:
The 6.7-inch iPhone screenshots do not show the actual app in use.
Outras recusas 2.3.3 detalham o que o reviewer espera. Esta foi publicada nos fóruns da Apple em outubro de 2024 por um desenvolvedor cujos espaços de iPad mostravam uma moldura de iPhone. Aqui está o trecho que lista as exigências, palavra por palavra:
Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.
- Marketing or promotional materials that do not reflect the UI
of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
features and functionality.
- Confirm that the app looks and behaves identically in all
languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
correct device, unless they are included to demonstrate that
the app can be used on multiple Apple platforms. For example,
iPhone screenshots should be taken on iPhone, not on iPad.
Em português: uma arte publicitária que não mostra a interface do app não tem lugar entre as capturas. A maioria precisa mostrar as funções principais. E cada captura mostra o aparelho certo: captura de iPhone se tira no iPhone, não no iPad, a não ser para mostrar que o app funciona em várias plataformas da Apple.
O que a Apple chama de "app in use"
O texto da guideline 2.3.3 é curto: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen." As capturas precisam mostrar o app em uso, não só o logo, a tela de login ou a tela de abertura. O mesmo texto permite textos e imagens sobrepostos.
A página de ajuda do App Review sobre a 2.3.3 explica como é feito o julgamento. A Apple avalia a série de cada tipo de aparelho, e só aprova se mais da metade das capturas mostrar o app em uso. Cada idioma é julgado separadamente. A página também lista o que evitar:
- capturas que mostram só uma tela de login ou uma tela de abertura;
- uma interface que não corresponde à real, ou uma arte publicitária enganosa;
- decorações que escondem o app, ou só o hardware, sem interface por trás.
Resumindo, "em uso" quer dizer: a interface real do seu build, com conteúdo, fazendo aquilo para o qual as pessoas baixam o app. Um título curto acima de uma tela real continua sendo uma captura em uso.
Quantas capturas precisam mostrar o app
A Apple dá dois exemplos: com três capturas, duas precisam mostrar o app. Com quatro, três. O resto sai da mesma regra, mais da metade.
| Capturas enviadas | Mínimo em uso | Artes de marketing possíveis |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 8 | 5 | 3 |
| 10 | 6 | 4 |
A conta é feita por tipo de aparelho e por idioma. Uma única captura por aparelho basta, se ela mostrar o app em uso. Segundo as especificações das capturas, a Apple exige pelo menos uma captura para o iPhone com Dynamic Island de tela média, e aceita até 10 por tamanho. Se a sua interface é a mesma em todos os tamanhos e em todos os idiomas, a maior resolução exigida basta: o App Store Connect reduz para os tamanhos menores. As dimensões exatas estão em o tamanho das capturas da App Store.
O que passa, o que não passa
| Captura | Veredito | O que decide |
|---|---|---|
| Tela real do app, título curto acima | Passa | Texto sobreposto é permitido pela 2.3.3 |
| Tela real dentro de um iPhone | Passa | A interface real, no aparelho certo |
| Só logo, tela de abertura ou login | Recusada | Citado palavra por palavra pela regra |
| Arte de marketing sem interface | Tolerada em minoria | Só se a maioria mostrar o app |
| Cards de interface redesenhados, sem o app | Recusada | Minha recusa de 27 de outubro de 2026 |
| Tela de mockup que não existe no build | Recusada | Interface que não corresponde à real |
| Celular vazio ou cenário sem interface por trás | Recusada | Listado no que evitar |
| Captura de iPhone nos espaços de iPad | Recusada | Aparelho errado, segundo a recusa do fórum |
| Imagem que se estende por duas capturas | Passa | Permitido, desde que o app continue visível |
| Barra de status de outra plataforma | Recusada, pela 2.3.10 | A Apple remete à guideline 2.3.10 |
A Apple não exige moldura de celular. Uma captura em tela cheia do app basta. A moldura tem uma vantagem: deixa óbvio, à primeira vista, que a imagem é o app.
Meu caso: Vigie recusado em 27 de outubro de 2026
Para a versão 1.1 do Vigie, eu tinha seguido uma tendência dos estúdios de capturas: um painel contínuo, um mascote e cards de interface flutuando no lugar de um celular inteiro. Os cards foram redesenhados para a ocasião, com apps fictícios. Ficou bonito. Não era o app.
O reviewer escreveu que as capturas do iPhone de 6,7 polegadas não mostravam o app em uso. Não contestei: ele tinha razão. Refiz a série inteira com uma regra simples:
- Cada painel mostra um iPhone com uma captura nativa do simulador, colada pixel a pixel, sem retocar a interface.
- Um card ampliado só aparece junto com o celular, nunca no lugar dele, e é recortado dessa mesma captura.
- O cenário fica em volta, nunca por cima da tela.
Essa recusa não pedia nenhum build novo. Troquei as capturas e reenviei a mesma versão na mesma noite. Depois troquei de build para corrigir um título no app, sem relação com as capturas. O Vigie 1.1 estava à venda em 29 de outubro com essa série.
Um card redesenhado, mesmo fiel, não é o app. O reviewer quer ver a tela que o usuário vai ter nas mãos.
Corrigir sem novo build
- Leia a mensagem inteira. Ela diz qual tamanho de aparelho está em questão, às vezes qual idioma. Todas as séries afetadas precisam mudar, não só a primeira.
- Refaça as capturas a partir do build enviado. Simulador ou aparelho, com conteúdo real. Mais da metade em uso, para cada aparelho e cada idioma.
- Troque as capturas no App Store Connect. Segundo a ajuda sobre gerenciamento de recursos visuais, isso é possível quando o app está em um destes status: Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected ou Developer Rejected.
- Reenvie, de acordo com o status exibido. Para Metadata Rejected, a tabela de status diz: leia a mensagem, corrija os metadados e depois responda à mensagem do App Review. Se o envio mostrar Unresolved Issues, siga o procedimento da Apple: em Apps, View App Review Issues & Messages, depois Resolve, Edit no item recusado, Add for Review e, por fim, Resubmit to App Review.
- Não mexa mais nas capturas depois do envio. Segundo a mesma tabela de status, em Waiting for Review você não pode nem enviar nem modificar capturas.
Cada item recusado só pode ser modificado uma vez antes do reenvio: confira sua nova série antes de clicar. A resposta que eu escreveria ao reviewer, em inglês:
Hello App Review team,
Thank you for your feedback regarding Guideline 2.3.3.
We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].
The build is unchanged.
Best regards,
[Your name]
O tom e o formato de uma boa resposta estão detalhados em responder ao App Review.
O checklist antes de enviar suas capturas
- Mais da metade das capturas de cada tipo de aparelho mostra a tela real, com conteúdo.
- A mesma regra vale em cada idioma, não só em inglês.
- Nenhuma captura mostra só o logo, a tela de abertura ou o login.
- A interface mostrada existe no build enviado, idêntica.
- Os títulos e o cenário deixam a interface legível.
- As capturas de iPhone são tiradas no iPhone, as de iPad no iPad.
- Nenhum vestígio de outra plataforma, nem na barra de status.
- Se o seu app tem modo escuro, uma captura mostra esse modo: a página de ajuda da Apple recomenda isso.
- Os arquivos estão em JPEG ou PNG, sem transparência.
A Apple também lembra, na sua página sobre a página do produto, que as primeiras capturas podem aparecer nos resultados de busca. Para mim, uma captura que mostra claramente o app sendo usado vende mais do que um slogan. Os outros motivos de recusa da página do app estão em por que a Apple recusa um app.
Capturas que passam de primeira
O App Store Screenshots Kit reúne meus modelos e a skill que cria suas capturas a partir das telas reais do seu app, nos tamanhos pedidos pela Apple. Se a sua página acabou de ser recusada, o Review Kit traz meu checklist antes do envio, minhas recusas corrigidas e os modelos de resposta ao reviewer. O passo a passo completo está na página app recusado pela Apple.
Se você está preparando seu primeiro lançamento, faça seu diagnóstico gratuito: ele coloca as etapas na ordem certa e te envia meu checklist anti-recusa da Apple.
Perguntas frequentes
O que significa "Guideline 2.3.3 - Performance - Accurate Metadata"?
É o título da recusa para capturas que não mostram o app em uso. A Apple considera que capturas demais são artes de marketing, telas de abertura ou interfaces que não são as do app. A mensagem muitas vezes indica o tamanho de aparelho em questão.
Preciso de um novo build depois de uma recusa 2.3.3?
Não. A recusa é sobre a página da App Store. Você troca as capturas no App Store Connect e depois reenvia a mesma versão respondendo à mensagem do App Review.
Quantas capturas precisam mostrar o app em uso?
Mais da metade, para cada tipo de aparelho e em cada idioma. Com três capturas, duas precisam mostrar o app. Com quatro, três. Uma única captura basta se ela mostrar o app em uso.
Posso colocar texto de marketing nas capturas da App Store?
Pode. A guideline 2.3.3 permite textos e imagens sobrepostos. Eles não podem esconder a interface, e a maioria das capturas ainda precisa mostrar o app em uso.
Preciso de uma moldura de iPhone em volta das capturas?
Não, a Apple não exige: uma captura em tela cheia do app passa. A moldura ajuda quem vê a entender que a imagem é o app. Ela precisa ser do aparelho certo: nunca uma moldura de iPhone numa captura destinada ao iPad.
Posso modificar as capturas enquanto o app espera a review?
Não. No status Waiting for Review, o App Store Connect não deixa enviar nem modificar capturas. Para trocá-las, retire o envio da revisão ou espere a decisão.

