Guideline 2.3.10: app rejeitado por causa dos metadados

A guideline 2.3.10, "Accurate Metadata", rejeita um app cuja página ou interface fala de outra plataforma: Android, Google Play, um celular de outra marca numa captura. A sua página fala do seu app nos aparelhos Apple, e de mais nada. Se a menção está na página, você corrige e reenvia o mesmo build. Se está no app, precisa de um build novo.

Duas primas caem pelo mesmo motivo: a 2.3.3, quando as capturas não mostram o app em uso, e a 2.3.7, quando o nome, o subtítulo ou as palavras-chave enganam. Eu mesmo preparo as páginas e as capturas dos meus apps: Solys, TradaZen e Nolera estão na App Store. Este guia se baseia no texto oficial da Apple, lido em 15 de outubro de 2026. As compras dentro do app na página são assunto da 2.3.2, que eu trato à parte. Para a visão geral das rejeições, leia por que a Apple rejeita um app.

O que diz a guideline 2.3.10?

A seção 2.3 das App Review Guidelines parte de uma ideia simples: quem baixa precisa saber o que está levando. Descrição, capturas, prévias e informações de privacidade devem refletir a experiência real do app.

A 2.3.10 especifica: "don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality." Traduzindo: nada de nome, ícone ou imagem de outra plataforma móvel ou de uma loja de apps alternativa, nem no app, nem na página dele. E acrescenta: "Make sure your app metadata is focused on the app itself and its experience." A página fala do app, sem informação fora do assunto.

Três pontos para guardar:

• O app conta tanto quanto a página. Um botão "Disponível no Google Play" dentro do app cai na mesma regra.
• As lojas alternativas também entram. As que existem em alguns países não podem ser citadas, assim como o Android.
• A exceção é estreita. Um app pode nomear outra plataforma se uma função interativa específica, aprovada pela Apple, justificar. Exemplo: um app de transferência de arquivos entre um iPhone e um celular Android pode citar o Android, porque essa é a função dele. Explique isso nas notas da revisão.

A mensagem típica de uma rejeição 2.3.10

O título é "Guideline 2.3.10 - Performance - Accurate Metadata". Numa mensagem publicada nos fóruns da Apple, a Apple escreve: "Referencing third-party platforms in your app or its metadata is not permitted on the App Store unless there is specific interactive functionality." O resto pede para remover qualquer menção do app e da página: descrição, texto promocional, novidades, prévias e capturas. Nesse caso, as capturas vinham de páginas do site do desenvolvedor, e a Apple apontou um aparelho e uma barra de status que não eram de um iPhone.

A página de ajuda da Apple sobre capturas em uso confirma: uma captura que faz referência a outra plataforma, por exemplo na barra de status, é avaliada pela 2.3.10.

Onde se escondem as menções que derrubam pela 2.3.10

• A descrição e o texto promocional. "Também disponível para Android" é a frase mais comum.
• As notas de versão. É a armadilha dos projetos publicados nas duas lojas. Uma nota em comum como "Correção do teclado no Android" acaba na App Store. Se você prepara as duas versões com um único projeto, como em app iOS ou Android, escreva notas separadas.
• As capturas e as prévias. Uma moldura de celular Android, uma barra de status Android, uma captura feita no emulador Android ou no seu site.
• O próprio app. Uma tela de compartilhamento ou de indicação com os dois selos de loja, um link "Avaliar o app" que abre a Play Store, um texto de boas-vindas que fala de Android. Num projeto React Native ou Expo, escolha o link e o selo de acordo com Platform.OS: assim a versão iOS só mostra a App Store.
• Cada idioma. Cada localização tem seus próprios textos e suas próprias capturas, e a Apple avalia as capturas de cada localização. Uma menção esquecida num único idioma pode bastar para rejeitar o envio.

Para procurar, eu rodo uma busca nos textos da página e nos arquivos de tradução do app: rg -i "android|google play|play store". Depois olho cada captura, idioma por idioma, procurando uma barra de status ou uma moldura que não venha de um iPhone.

2.3.3: capturas que mostram o app em uso

O texto oficial: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen." As capturas precisam mostrar o app funcionando, não só o logo, a tela de login ou a tela de abertura. Textos e imagens sobrepostos são permitidos.

A página de ajuda da Apple dá uma regra em números. Para cada tipo de aparelho, mais da metade das capturas precisa mostrar o app em uso. Com três capturas, duas precisam mostrar. Com quatro, três. As outras podem apresentar os benefícios com visuais de marketing. Nas capturas em uso, os textos adicionados não podem esconder a interface.

Isso combina com uma página que vende: um título curto em cima de uma tela real continua sendo uma captura em uso. Os tamanhos e a quantidade de capturas, até dez por tamanho de aparelho, estão nas especificações das capturas.

2.3.7: nome, subtítulo e palavras-chave honestos

A 2.3.7 exige um nome único e palavras-chave que descrevam o app, sem encher os metadados de "trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system". Nada de marcas registradas, nomes de apps conhecidos, preços ou frases fora do assunto para enganar a busca.

O que ela impõe na prática:

• O nome cabe em 30 caracteres. O subtítulo também, segundo as informações do app do App Store Connect.
• O subtítulo não cita outros apps e não promete nada que não dá para verificar.
• O nome, o subtítulo, as capturas e as prévias não mostram preço.
• As palavras-chave não contêm nome de app nem nome de empresa de terceiros. A ajuda sobre as informações de versão diz: "Names of other apps or companies aren't allowed."

A palavra "grátis" é uma armadilha. Numa rejeição 2.3.7 publicada nos fóruns da Apple, a Apple explica que menções a serviços gratuitos ou em promoção contam como referência a preço.

Dizer que uma função exige assinatura é esperado, mostrar o preço dela numa captura não é. A primeira exigência vem da 2.3.2, a segunda da 2.3.7. A Apple resume as dicas de nome, subtítulo e palavras-chave na página dedicada à página do produto. O método para escolher suas palavras está em palavras-chave da App Store, e a página completa em ASO App Store.

Rejeitado ou aceito: a tabela regra por regra

As versões rejeitadas são exemplos criados. A linha do nome aceito traz o nome real do Solys na App Store francesa, em outubro de 2026.

Regra	Rejeitado (exemplo)	Aceito
2.3.10	"Disponível para iPhone e Android"	"Disponível para iPhone e iPad"
2.3.10	Nota "Bug corrigido no Android"	"Correção da exibição do teclado"
2.3.10	Captura numa moldura de celular Android	Captura do simulador do iPhone
2.3.10	Selos App Store e Google Play no app	Só o selo da App Store no iPhone
2.3.3	Logo, login, abertura, depois 2 telas	Pelo menos 3 telas de uso em 5
2.3.3	Texto de marketing em tela cheia, sem o app	Título curto em cima de uma tela real
2.3.3	Mockup de uma função que ainda não foi lançada	Tela real da versão enviada
2.3.7	Nome "Despertador Alarme Sono Pro Grátis"	"Solys : Limiter temps d'écran"
2.3.7	Subtítulo "Melhor que [app concorrente]"	Subtítulo que diz o benefício
2.3.7	Palavras-chave com nomes de apps rivais	Palavras de uso: despertador, manhã, rotina
2.3.7	"Grátis" ou "-50%" numa captura	Nenhum preço nem promoção nas capturas

Um caso real, fora da 2.3.10: um nome de terceiro na descrição

No Nolera, meu app de guarda-roupa, a descrição citava a OpenAI, o serviço de IA usado para o provador. A Apple rejeitou o envio citando a seção 5, "Legal", por causa da disponibilidade na China. A solução adotada foi tirar a China dos países onde o app é oferecido.

Não foi uma rejeição 2.3.10, mas vem do mesmo lugar: um nome de serviço de terceiros na página nunca é neutro. Antes de escrever um, pergunte se ele ajuda a pessoa a escolher o seu app. Na maioria das vezes, descrever o que a função faz já basta.

Corrigir e reenviar

1. Leia a lista da Apple. A mensagem diz onde viu a menção: descrição, capturas, app. Some a isso a sua própria busca, idioma por idioma.
2. Corrija tudo, não só o exemplo citado. Uma segunda menção encontrada na rodada seguinte custa um ciclo de revisão inteiro.
3. Só a página: mesmo build. Você altera no App Store Connect, responde ao App Review e reenvia. Os detalhes estão em prazo de aprovação da App Store.
4. Menção no app: build novo. O revisor testa o binário enviado.
5. Função interativa de verdade: explique. Diga na resposta o que o app faz com a outra plataforma, e onde testar.

O modelo de resposta que eu usaria, em inglês, para adaptar:

Hello,

Thank you for your review.

We removed every reference to other platforms:
- Description and promotional text: [what changed].
- What's New: [what changed].
- Screenshots: replaced with captures from iPhone,
  in all [number] localizations.

No change was needed in the app binary.

Best regards,

Só escreva a última linha se ela for verdade.

O checklist 2.3 antes do envio

• Nenhuma palavra "Android", "Google Play" ou "Play Store" na página, em nenhum idioma.
• Notas de versão escritas para iOS, não copiadas da versão Android.
• Capturas feitas no iPhone ou iPad, sem moldura nem barra de status de outra marca.
• Mais da metade das capturas de cada aparelho mostra o app em uso.
• Nenhum mockup de função ausente da versão enviada.
• Nome e subtítulo sem preço, sem nome de app concorrente, sem promessa inverificável.
• Palavras-chave sem marca de terceiros nem nome de empresa.
• Nenhum "grátis" nem porcentagem de desconto nas capturas.
• No app, links e selos de loja adaptados à plataforma.

Uma página que passa na revisão de primeira

O Apple Review Kit reúne meu checklist antes do envio e skills do Claude Code que revisam seu projeto, seu paywall e sua página. Para capturas que vendem sem violar a 2.3.3, o App Store Screenshots Kit cria seus visuais a partir das telas reais do seu app, nos tamanhos exigidos pela Apple. Para um olhar humano, reserve uma hora comigo. O passo a passo completo depois de uma rejeição está na página app rejeitado pela Apple.

Se você está preparando seu primeiro lançamento, faça seu diagnóstico gratuito: ele coloca as etapas em ordem e te envia meu checklist anti-rejeição da Apple. A página inicial mostra como criar um aplicativo mobile pensando na página da loja desde o começo.

Perguntas frequentes

O que significa "Guideline 2.3.10 - Performance - Accurate Metadata"?

É o título da rejeição por menção a outra plataforma. A Apple encontrou, na sua página ou no seu app, um nome, um ícone ou uma imagem do Android, do Google Play ou de outra loja de apps. A correção: remover cada menção, em cada idioma.

Posso escrever que meu app também existe para Android?

Não na página nem na versão iOS do app. A única exceção é uma função interativa real com a outra plataforma, que você explica nas notas da revisão. Para dizer que seu app existe em outro lugar, use seu site.

Quantas capturas precisam mostrar o app em uso?

Mais da metade, para cada tipo de aparelho. Com três capturas, duas mostram o app em uso. Com quatro, três. As outras podem apresentar seus benefícios com visuais de marketing.

Preciso de um build novo depois de uma rejeição 2.3.10?

Não, se a menção está só na página: você corrige no App Store Connect e reenvia o mesmo build. Se a menção está no app, como um selo do Google Play numa tela de compartilhamento, precisa de um build novo.

Posso citar um app concorrente nas palavras-chave?

Não. A ajuda do App Store Connect proíbe nomes de outros apps e empresas nas palavras-chave, e a 2.3.7 rejeita marcas registradas usadas para enganar a busca. Aposte nas palavras que o seu público digita para descrever a necessidade dele.