Por que a Apple rejeita capturas de tela da App Store (e como evitar)

A Apple rejeita capturas de tela da App Store quando elas não mostram o app com precisão, com base na seção 2.3 (Metadados precisos) das Diretrizes de Revisão da App Store. Os motivos mais comuns são capturas de tela que não mostram o app em uso (2.3.3), capturas de iPad que são imagens de iPhone esticadas, imagens ou nomes de outras plataformas como o Android (2.3.10), preços na imagem (2.3.7) e recursos que o app não tem de verdade (2.3 e 2.3.1). Uma captura de tela rejeitada geralmente deixa o app com o status Metadados rejeitados, que você corrige no App Store Connect e resolve respondendo ao App Review, sem um novo build.

A seguir estão cada diretriz que afeta capturas de tela, nas palavras da própria Apple, os motivos que mais vemos, os erros de envio que parecem rejeições mas não são e como responder.

Quais diretrizes do App Review tratam de capturas de tela?

Todas ficam na seção 2.3 das Diretrizes de Revisão da App Store, que começa assim: “garanta que todos os metadados do seu app, incluindo as informações de privacidade, a descrição do app, as capturas de tela e as prévias, reflitam com precisão a experiência principal do app.” Os itens numerados que importam para capturas de tela:

A tabela resume para caber; cite o texto exato da diretriz quando responder ao App Review. Os números das diretrizes às vezes mudam, então confira a página atual, e não um post antigo (incluindo este), antes de citar uma.

Os motivos mais comuns de rejeição de capturas de tela

1. A captura de tela não mostra o app em uso (2.3.3)

A diretriz 2.3.3 diz: “As capturas de tela devem mostrar o app em uso, e não apenas a arte do título, a página de login ou a tela de abertura.” Ela também permite “sobreposições de texto e imagem”, então uma captura de tela trabalhada com legenda, fundo e moldura de dispositivo não tem problema. O que é sinalizado é uma captura de tela em que o app em si some ou vira um detalhe: um slogan sobre um degradê, um logo, um formulário de login, um carrossel de onboarding. Mostre interface real e preenchida em todas as capturas de tela, e capriche na primeira, porque ela é a mais vista (falamos sobre o que colocar na primeira captura de tela da App Store em outro post).

2. Capturas de tela de iPad que na verdade são de iPhone (2.3.3)

Esta é uma das rejeições que os desenvolvedores mais relatam nos fóruns da Apple: o espaço do iPad de 13 polegadas é preenchido com uma captura de tela de iPhone esticada, com margens ou colocada numa moldura de iPad. O App Review entende isso como não mostrar o app em uso no iPad. A solução é capturar o app rodando num iPad (ou no simulador do iPad Pro de 13 polegadas) e montar o conjunto de iPad em cima dessas capturas. Se o seu app não é compatível com o iPadOS, você não precisa de um conjunto de iPad.

3. Outras plataformas na imagem (2.3.10)

A diretriz 2.3.10 pede que você não “inclua nomes, ícones ou imagens de outras plataformas móveis ou lojas de apps alternativas no seu app ou nos metadados, a menos que haja uma funcionalidade interativa específica e aprovada.” Nas capturas de tela, isso geralmente significa:

• Uma moldura de celular Android, ou as barras de status e de navegação do Android, muitas vezes por reaproveitar um conjunto do Google Play
• Selos “Disponível no Google Play” ou uma legenda “Disponível para Android”
• Interface específica do Android num app multiplataforma capturado no dispositivo errado

Mantenha conjuntos separados para cada loja. Geradores que exportam os dois a partir de um único projeto facilitam isso; uma convenção de nomes no Figma também.

4. Preços e promessas promocionais (2.3.7)

A diretriz 2.3.7 diz que “metadados como nomes de apps, subtítulos, capturas de tela e prévias não devem incluir preços, termos ou descrições que não sejam específicos do tipo de metadado.” Legendas como “Só $2.99/mês”, “Promoção de lançamento: 50% de desconto” ou uma faixa com o preço do teste gratuito são motivos típicos. Descreva o que o app faz; os preços a App Store já mostra.

5. Recursos que o app não tem (2.3, 2.3.1)

Mockups de recursos que ainda vão sair, um design bem diferente da interface que está sendo lançada ou uma captura de outra versão do app podem ser vistos como enganosos. A diretriz 2.3.1 cita especificamente “promover conteúdo ou serviços que ele não oferece de fato”. Faça as capturas de tela a partir do build que você está enviando.

6. Recursos pagos sem nenhum sinal de que são pagos (2.3.2)

A diretriz 2.3.2 pede que a “descrição do app, as capturas de tela e as prévias indiquem claramente se algum item em destaque, nível, assinatura etc. exige compras adicionais.” Se a sua captura de tela principal mostra um recurso Pro, um pequeno rótulo “Pro” ou “Premium” na interface ou na legenda, mais um texto claro na descrição, evita a dúvida.

7. Dados reais, conteúdo licenciado e interface inacabada

A diretriz 2.3.9 pede informações de conta fictícias em vez dos dados de uma pessoa real e deixa você responsável pelos direitos de tudo o que aparece. Fotos de celebridades, escudos de times ou pôsteres de filmes num feed de demonstração são um risco, a menos que você tenha os direitos. Além disso, a diretriz 2.1 pede que os envios sejam versões finais, sem texto provisório e outros conteúdos temporários, então menus de debug, “Lorem ipsum” e faixas de ambiente de teste também não devem aparecer nas capturas de tela. O nosso guia de capturas de tela limpas no simulador e no emulador mostra como preparar dados de demonstração e uma barra de status arrumada.

Erros de envio que não são rejeições

Alguns problemas com capturas de tela nem chegam ao App Review, porque o App Store Connect recusa o arquivo no envio. São mais rápidos de corrigir, mas travam do mesmo jeito.

As especificações de capturas de tela da Apple listam todos os tamanhos aceitos por grupo de dispositivos, e a nossa referência de tamanhos de capturas de tela reúne os mais comuns numa só tabela.

Como responder a uma rejeição de capturas de tela

1. Leia a mensagem no App Store Connect

Os detalhes da rejeição aparecem na seção App Review da página do seu app no App Store Connect (muitos desenvolvedores ainda chamam de Resolution Center, o nome antigo). A Apple inclui o número da diretriz e geralmente uma observação sobre quais capturas de tela e qual tamanho de dispositivo causaram o problema. Leia com atenção: “as suas capturas de tela de iPad de 13 polegadas” e “as suas capturas de tela de iPhone” pedem correções diferentes.

2. Corrija os metadados, não o build

Para o status Metadados rejeitados, a referência de status da Apple diz: “Leia a mensagem do App Review, edite os metadados para resolver o problema e responda à mensagem do App Review.” Substitua as capturas de tela sinalizadas em todas as localizações que as têm; corrigir só em inglês não resolve um problema que também existe no seu conjunto em alemão. Confira também os tamanhos redimensionados no Media Manager.

3. Responda de forma curta e específica

Diga o que mudou e onde. Algo assim:

Thanks for the review. We've replaced the 13-inch iPad screenshots
in all 6 localizations with captures of the app running on iPad Pro
(13-inch). The previous images were scaled iPhone screenshots.
The build is unchanged.

4. Se discordar, explique ou recorra

Se você acha que o revisor interpretou mal a captura de tela (por exemplo, um recurso que ele não encontrou fica atrás de um login), responda com os passos para chegar até ele e inclua os dados de uma conta de demonstração nas Informações da revisão do app. Se isso não resolver, a página do App Review da Apple descreve como recorrer ao App Review Board: dê motivos específicos de por que o app cumpre as diretrizes, envie um recurso por envio rejeitado e responda antes a qualquer pergunta pendente. A Apple também oferece conversas de 30 minutos com o App Review para tirar dúvidas sobre as diretrizes antes do envio.

Um checklist antes de enviar

• Toda captura de tela mostra interface real e preenchida do app, do build que você está enviando
• As capturas de tela de iPad são capturas reais de iPad, ou não existem porque o app não é compatível com o iPadOS
• Nada de molduras Android, interface do sistema Android, selos do Google Play ou nomes de outras plataformas
• Nada de preços, descontos ou preço de teste gratuito nas imagens
• Os recursos pagos aparecem como pagos em algum lugar da página
• As imagens são adequadas para o público 4+ e você tem os direitos sobre elas
• Os dados de demonstração são fictícios; nada de texto provisório ou interface de debug
• Tamanhos exatos em pixels aceitos, PNG ou JPEG, sem transparência, até 10 por tamanho
• Correções aplicadas em todas as localizações, não só no idioma principal

Para problemas de design que não vão causar rejeição mas vão custar instalações, veja erros comuns em capturas de tela de apps, e para o processo completo, do build ao envio, como fazer capturas de tela para a App Store.