Diretriz 4.3(a) Design Spam: como resolver, com 4.3(b) e 4.2.6 explicadas para apps de template e IA (2026)

Uma rejeição pela Diretriz 4.3(a) Design Spam é uma das mensagens do App Review mais difíceis de resolver, porque raramente diz com qual app o seu se parece. Ela atinge apps de template, clientes white-label e apps gerados por IA com muito mais frequência do que os outros. Este guia separa a 4.3(a) da 4.3(b) e da 4.2.6, mostra como outros desenvolvedores passaram pela rejeição e traz um modelo de resposta e um checklist para concluir antes de reenviar. Para outros tipos de rejeição, veja o guia de rejeições diretriz por diretriz.

O que significa a Diretriz 4.3(a) Design Spam?

A Diretriz 4.3(a) significa que a Apple acha que seu envio é basicamente o mesmo app que outro já enviado: ou vários bundle IDs de um mesmo app, ou uma quase cópia do app de outra pessoa. A solução é consolidar os duplicados ou tornar a experiência principal claramente diferente.

Em novembro de 2026, as App Review Guidelines dizem: "Não crie vários Bundle IDs do mesmo app (por exemplo, enviar um app de mapa separado para cada cidade do mundo em vez de um único mapa mundial que permita aos usuários pesquisar qualquer cidade)." A alternativa sugerida pela Apple é: "considere enviar um único app e oferecer as variações por meio de compra dentro do app." A 4.3(a) tem o ícone de chave, então também se aplica à notarização de apps iOS e iPadOS distribuídos fora da App Store.

O texto de rejeição que os desenvolvedores costumam receber é: "Guideline 4.3(a) - Design - Spam. We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences." (em tradução livre: notamos que seu app compartilha binário, metadados e/ou conceito semelhantes a apps enviados à App Store por outros desenvolvedores, com apenas pequenas diferenças). Há três gatilhos nessa frase (binário, metadados, conceito), e qualquer um deles pode causar a rejeição.

Qual a diferença entre a 4.3(a), a 4.3(b) e a 4.2.6?

A 4.3(a) trata de duplicados, a 4.3(b) trata de apps que não acrescentam nada a uma categoria já lotada e a 4.2.6 trata de apps feitos com template e enviados pela conta errada. Cada uma exige uma solução diferente, então confira primeiro o número exato da diretriz na sua rejeição.

O texto atual da 4.3(b) também avisa que a Apple "pode remover esses apps da App Store daqui em diante se não forem atualizados, melhorados ou não atraírem clientes", e que categorias de baixo esforço, como jogos de bebida e apps de pum, podem levar à remoção do Apple Developer Program se enviadas repetidamente. Para as outras regras que a Apple revisou recentemente, veja nossas mudanças nas App Review Guidelines de outubro de 2026.

Por que apps de template e gerados por IA são marcados como spam?

Apps de template e gerados por IA são marcados porque muitos compartilham o mesmo código inicial, os mesmos layouts de tela e textos de loja parecidos, o que bate com os três gatilhos: binário, metadados e conceito. Ser dono do código não isenta o app se o resultado parece com centenas de outros.

Criadores de apps com IA costumam gerar o mesmo onboarding, a mesma tab bar e o mesmo conjunto genérico de recursos ("acompanhe hábitos, receba insights de IA"), e a descrição gerada para a App Store muitas vezes também é igual. Se você publicou por um desses criadores, confira quem aparece como vendedor. A 4.2.6 diz que serviços de template "não devem enviar apps em nome de seus clientes", então o app deve sair pela conta de desenvolvedor do dono do conteúdo. Nosso guia de publicação do Base44 e nosso guia de publicação do Lovable cobrem o que continua sendo responsabilidade sua depois da exportação.

O que outros desenvolvedores fizeram para resolver uma rejeição 4.3(a)?

Casos relatados publicamente mostram que mudanças só visuais raramente funcionam. Consolidar apps duplicados e escrever uma resposta específica sobre o que torna o app diferente funciona melhor.

• Juntando com um app existente (GitHub). Uma equipe que publicava um app de VoIP baseado no Linphone relatou na issue #936 do linphone-iphone que um novo conjunto de ícones e um novo esquema de cores não resolveram a 4.3(a). Eles concluíram que o conflito era outro app baseado no Linphone na mesma conta. Colocaram as mudanças nesse app existente como atualização, e ele passou "quase de imediato".
• Explicando o que é único (Godot Forum). Um desenvolvedor de jogos no Godot Forum suspeitou que o binário compartilhado da engine estava batendo com outros jogos feitos em Godot. Reduzir o build e explicar que usava Godot foram ambos rejeitados. Uma resposta "listando os pontos principais que, na minha opinião, tornavam meu jogo divertido e único em relação a outros jogos do mesmo gênero" conseguiu a aprovação.
• Capturas de tela não bastaram (Apple Developer Forums). Em um tópico dos Apple Developer Forums, um desenvolvedor contou que um representante da Apple apontou as capturas de tela, e que "metadados" pode significar nome, subtítulo, palavras-chave ou capturas de tela. Capturas de tela totalmente novas ainda receberam a mesma rejeição, em uma atualização de um app com 2–3 anos de idade.

O ponto em comum: mudanças cosméticas (ícones, cores, capturas de tela) falharam nos três casos. O que funcionou foi remover o duplicado da conta ou dar ao revisor motivos concretos, no nível de recursos, de por que o app é diferente.

Como resolver uma rejeição 4.3(a) passo a passo?

Para resolver uma rejeição 4.3(a), primeiro encontre o duplicado, depois faça mudanças reais no produto e, em seguida, responda ao App Review com detalhes específicos antes de reenviar. Reenviar o mesmo build com um ícone novo é a forma mais comum de ser rejeitado de novo.

1. Leia o número exato da diretriz na seção App Review do App Store Connect. Se for 4.2.6 ou 4.3(b), siga a linha correspondente da tabela acima.
2. Liste todos os apps da sua conta, publicados ou removidos, que compartilham código, template, conceito ou design com o app rejeitado. Se encontrar algum, junte-os em um único app com variações internas ou publique as mudanças como atualização do app que já está no ar.
3. Pesquise na App Store as palavras-chave da sua categoria e anote os primeiros resultados. Escreva o que seu app faz que nenhum deles faz.
4. Mude pelo menos um fluxo principal (fonte de dados, recurso principal, modelo de interação), não só o tema.
5. Reescreva nome, subtítulo, palavras-chave, descrição e capturas de tela para que descrevam seus recursos específicos e não sobre nenhum texto genérico de template.
6. Responda no App Store Connect usando o modelo abaixo. A página do App Review da Apple também oferece reuniões de 30 minutos pelo Webex se você quiser tirar dúvidas sobre as diretrizes diretamente com um revisor.
7. Se você acredita que o revisor entendeu mal o app, faça uma apelação ao App Review Board. A Apple pede que você "envie apenas uma apelação por envio que não passou na revisão" e que responda primeiro aos pedidos de informação.

O que a resposta ao App Review deve dizer?

Uma boa resposta cita os recursos específicos que tornam o app diferente, confirma que não há apps duplicados na sua conta e indica ao revisor onde cada diferença pode ser vista. Seja breve, objetivo e educado. Como a comunicação com o App Review normalmente é em inglês, o modelo abaixo está em inglês.

Hello App Review,

Thank you for the feedback on Guideline 4.3(a). We have reviewed our account
and confirm [App Name] is our only app in this category. [We removed /
merged "Old App" into this app in version X.Y.]

What [App Name] does that similar apps do not:
1. [Feature] - e.g. syncs with the user's school timetable via [API];
   see Home > Schedule.
2. [Feature] - e.g. offline lesson plans authored by our team, not
   generated or scraped; see Library.
3. [Feature] - e.g. teacher-to-parent messaging; see the demo account.

This version also changes [core flow] and replaces all metadata and
screenshots to reflect these features.

Demo account: [username] / [password]

We are happy to provide more detail or join a call.

Thank you,
[Name]

Se algum recurso exige login, forneça ao revisor credenciais que funcionem. Nosso guia de conta demo para a revisão da App Store mostra como configurar uma.

O que um checklist de diferenciação deve cobrir antes de reenviar?

Um checklist de diferenciação deve cobrir sua conta, seu binário, seus metadados e seu conceito, os quatro pontos que a 4.3 analisa. Marque todos os itens antes de clicar em Submit for Review de novo.

• Conta: nenhum outro app, publicado ou removido, compartilha o mesmo template, conceito ou design.
• Conta: o app é enviado pela conta de desenvolvedor do próprio dono do conteúdo (4.2.6).
• Binário: telas de exemplo do template, dados de demonstração e marcas provisórias foram removidos.
• Binário: existe pelo menos um recurso principal que os primeiros resultados da categoria não têm.
• Metadados: nome, subtítulo e palavras-chave descrevem seu valor específico, não a categoria em geral.
• Metadados: as capturas de tela mostram seus recursos diferenciais nos dois primeiros quadros.
• Conceito: você consegue dizer em uma frase por que um usuário escolheria este app em vez dos cinco primeiros resultados.
• Notas para a revisão: as diferenças e uma conta demo estão listadas, para que o revisor não precise procurá-las.

Se você já foi rejeitado pela 4.3 mais de uma vez e não sabe o que mudar, nosso serviço de envio para a App Store prepara a revisão e trabalha com você o feedback da rejeição, por $599 cobrindo as duas lojas (as taxas de conta de desenvolvedor são à parte).