A checagem de spam 4.3 da Apple é um job em lote de 30 segundos. 22 rejeições provam isso

Resumo: O App Review da Apple rejeitou 11 dos meus apps de iPhone pela Guideline 4.3 Spam. E depois fez de novo. Nas duas vezes, as 11 rejeições chegaram dentro de 30 segundos (30 s em 5 de outubro, 27 s em 12 de outubro), um e-mail a cada 3 segundos, numa ordem que não tem nada a ver com a ordem em que enviei os apps. A segunda rodada veio de 167,7 a 167,9 horas depois do meu reenvio, para todos os apps, sem exceção: um timer de sete dias, preciso em 12 minutos. Abri três recursos no App Review Board em 5 de outubro. 14 dias depois: zero respostas. Hoje rodei o meu próprio "detector de spam" nos 20 repositórios de apps, do jeito que a Apple os viu. Os dois apps mais parecidos que já publiquei estão ambos no ar. A Apple não está analisando apps pela 4.3. Está analisando contas, e não diz isso.

Se você chegou aqui pelo Google querendo saber o que significa "Guideline 4.3 spam": é a regra da Apple contra apps duplicados. A parte (a) proíbe "multiple Bundle IDs of the same app" (vários Bundle IDs do mesmo app), e a parte (b) proíbe apps "indistinguishable from what's already widely available" (indistinguíveis do que já existe em grande quantidade). A rejeição costuma dizer que o seu app "shares a similar binary, metadata, and/or concept" (compartilha binário, metadados e/ou conceito parecidos) com outros apps, com "only minor differences" (só pequenas diferenças). Ela não diz qual app, qual arquivo nem qual tela. A lista curta de soluções está no fim: pare de enviar em lote, responda antes de reenviar e marque uma conversa com o App Review. O resto deste artigo são as provas.

11 apps, 30 segundos, um e-mail a cada 3 segundos

Em 26 de setembro de 2026 enviei 11 apps novos de iPhone, todos criados no Windows com o pipeline sem Mac sobre o qual já escrevi: Odometer (manutenção do carro), Parked (parquímetro), Rooms (inventário da casa para o seguro), Pricebook (preços de mercado), Pawprint (remédios de pets), Chores (quadro de tarefas das crianças), Clockout (gorjetas para quem trabalha com atendimento), Curve (calculadora de notas), Climbbook (registro de boulder), Race Pace (parciais de corrida) e Cutoff (cafeína e sono). As submissões se espalharam por 15,5 horas: a primeira às 7h10 da manhã, horário do Pacífico, a última às 10h42 da noite.

Nove dias depois, em 5 de outubro, todos eles receberam o mesmo e-mail "There's an issue with your submission". Tirei os horários do Gmail hoje de manhã. O primeiro chegou às 5:29:32 da tarde, horário do Leste. O último chegou às 5:30:02 da tarde. Onze apps que resolvem, cada um, um problema diferente, para uma pessoa diferente, com um design diferente, julgados em trinta segundos.

Também conferi se as decisões saíram na ordem de envio, do jeito que um humano trabalhando numa fila produziria. Não saíram. A correlação de postos de Spearman entre "ordem de envio" e "ordem de rejeição" é -0,06 no primeiro lote e 0,06 no segundo. Isso é zero. O Pawprint foi enviado em 4º e rejeitado em 1º. O Odometer foi enviado em 1º e rejeitado em 11º. O que quer que tenha tomado essas decisões, não foi uma pessoa abrindo apps um depois do outro.

Onze apps diferentes, julgados em trinta segundos. Isso não é uma análise. Isso é um loop for.

Segunda rodada: um timer de sete dias, preciso em 12 minutos

Foi aqui que quebrei a única regra da Apple, e assumo isso. A rejeição dizia: se você discorda, responda no App Store Connect e não reenvie. Respondi aos 11, com as nove perguntas do App Review respondidas para cada app. E depois reenviei os 11 mesmo assim, em 10 minutos (das 3h13 às 3h23 da tarde, horário do Pacífico, em 5 de outubro).

As segundas rejeições chegaram em 12 de outubro, entre 6:04:46 e 6:05:13 da tarde, horário do Leste. 27 segundos para 11 apps. Mas a parte estranha é a espera. Todos os apps esperaram entre 167,7 e 167,9 horas do reenvio até a rejeição. 168 horas são exatamente sete dias. Onze apps, onze esperas, uma variação de 12 minutos.

Para comparar, a própria página do App Review da Apple diz que ela analisa "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (pelo menos 50% das submissões em menos de 24 horas e 90% em menos de 48). Quando cronometrei as 64 decisões do App Review na minha conta no fim de semana passado, a mediana foi de 73 horas, já pior do que a promessa da Apple. Nada mais na minha conta esperou 168 redondas.

A minha leitura, e é uma leitura, não um vazamento: contas sinalizadas vão para uma fila de espera com um timer de uma semana, e quando o timer dispara, o lote inteiro recebe a mesma rejeição pronta. Um humano pode até apertar o botão. Ninguém está abrindo os apps. Se você tem uma explicação melhor para 11 apps diferentes caindo em 7 dias menos 15 minutos, quero ouvir.

Não sou o único. Mesma semana, o mesmo tratamento de 30 segundos

Fui procurar no X outros desenvolvedores que passaram por isso em outubro de 2026. Bastou uma busca. Estes são posts reais, capturados hoje, sem edição.

Em 5 de outubro, o mesmo dia do meu primeiro lote, @krPorsche918 postou que a Apple rejeitou cinco apps seus "no mesmo minuto, com a mesma frase: Guideline 4.3 Spam". O relato dele tem a melhor frase que alguém já escreveu sobre isso: "Para mim, 14 apps em 13 dias era produtividade. Para a Apple, era um padrão." Na mesma semana, a Apple aprovou todos os 53 in-app events dos apps que ele já tinha no ar.

Em 8 de outubro, @vovalukashov (Luka Shaw) fez a pergunta que todo mundo nas respostas estava pensando: "Parece que a Apple parou de aprovar meus apps novos... É isso que acontece com todo mundo que faz apps pequenos que fazem uma coisa só?" Três apps novos rejeitados em quatro semanas, um deles duas vezes. "As atualizações dos meus apps antigos continuam passando." 62 mil pessoas viram.

E em 12 de outubro, às 6h26 da tarde, horário do Leste, 22 minutos depois de o meu segundo lote de 11 chegar, @martindonadieu (Martin Donadieu, fundador da Capgo) postou a tela do App Store Connect dele: uma parede de selos vermelhos "Rejected" e a legenda "Moved from no review to almost all rejected LOL" (passei de nenhuma análise para quase tudo rejeitado, kkk). 223 mil visualizações. Três dias depois ele postou de novo: rejeitado pela 4.3 pela segunda vez, num app de ingressos 100% local que atendeu um evento de 500 pessoas neste verão e já está no Google Play.

Repare no padrão entre nós quatro. Apps novos morrem. Atualizações passam. A minha própria conta mostra isso: na mesma janela que matou 11 apps novos duas vezes, a Apple aprovou atualizações do Chain e do Minder (12 de outubro) e seis atualizações em 29 de setembro. Todas essas seis atualizações de setembro adicionaram o mesmo padrão de paywall que os apps rejeitados tinham (Pro.swift; Purchases.swift no Chain), com commit na mesma manhã (26 de setembro, entre 9h26 e 9h29 da manhã, horário do Leste). Mesmo código, mesmo dia. Atualizações: aprovadas em cerca de 3 dias. Apps novos: rejeitados duas vezes. O Luka diz que as atualizações dele passam. O Porsche teve 53 in-app events aprovados. Os apps existentes do Martin continuam no ar.

Então é aqui que discordo do Luka. A conclusão dele foi "acho que é um sinal para focar nos que já estão na App Store". Esse é exatamente o comportamento que esse filtro está ensinando a todo desenvolvedor pequeno, e é a lição errada. O filtro não está dizendo que o seu app novo é ruim. Está dizendo que a sua conta está lançando rápido demais para o conforto da Apple. São problemas diferentes, com soluções diferentes.

A Apple estava certa? Rodei um detector de spam nos meus próprios apps

Pergunta justa: talvez os meus apps sejam mesmo clones. Sou um desenvolvedor com 20 apps de iPhone em 30 dias, feitos com agentes de programação com IA, todos saídos do mesmo pipeline. Se alguém merece uma 4.3, talvez seja eu. Então hoje à tarde eu testei isso, em vez de ficar discutindo.

O experimento: para cada um dos meus 20 repositórios locais de apps, pegar o commit do git que a Apple de fato viu (para os 8 apps no ar, o último commit antes da primeira aprovação; para os 11 rejeitados, o último commit antes do reenvio de 5 de outubro). Depois comparar cada par de apps, 190 pares, em cinco coisas que um filtro 4.3 poderia plausivelmente examinar:

• Sobreposição da árvore de arquivos: similaridade de Jaccard dos caminhos de arquivos rastreados (caminhos em comum divididos por todos os caminhos). Esse é o "esqueleto".
• Arquivos idênticos: arquivos iguais byte a byte depois de trocar o nome do próprio app.
• Sobreposição de linhas Swift: fração das linhas distintas e não triviais de código Swift que os dois apps têm em comum.
• Sobreposição do texto da loja: sobreposição de frases de três palavras na descrição da App Store.
• Distância entre capturas de tela: o par mais próximo de capturas da loja entre os dois apps, por average hash de 256 bits (menor significa mais parecido).

Primeiro o resultado honesto, porque ele não me favorece: os 11 rejeitados realmente compartilham um esqueleto. A sobreposição mediana da árvore de arquivos deles é 0,76, contra 0,56 dos apps no ar. Eles têm em comum uma mediana de 14 arquivos idênticos por par, contra 5, e cerca de três vezes mais linhas Swift (0,067 contra 0,021). Clockout e Odometer têm árvores de arquivos literalmente idênticas: os mesmos sete arquivos Swift, com os mesmos nomes, nas mesmas pastas. Se o filtro da Apple olha a estrutura do projeto dentro do binário, o meu lote rejeitado acende.

Agora a parte que a Apple deveria explicar. O par de apps mais parecido entre todos os 190 é Baseline Ledger e Fairway Ledger, o meu diário de tênis e o meu diário de golfe. Eles compartilham um terço das linhas Swift (0,333), 20 arquivos idênticos, uma árvore de 0,90, a descrição de loja mais parecida e as capturas de tela mais próximas de qualquer par. Os dois foram aprovados, com dois dias de diferença, em 22 e 24 de setembro. Os dois estão no ar hoje. Chain e Quiver compartilham uma árvore de 0,968. Os dois no ar.

E as coisas que um revisor humano realmente olha, a página da loja e as capturas de tela, não separam os dois grupos de jeito nenhum. Sobreposição do texto da loja: 0,010 nos pares rejeitados, 0,009 nos pares no ar. Distância entre capturas: 76 contra 82. Uma pessoa rolando as páginas da loja não conseguiria dizer que os apps rejeitados eram "mais parecidos". Só uma máquina comparando os bundles conseguiria.

O único arquivo que todo app rejeitado tinha

A impressão digital que separa os grupos de forma limpa não é uma pontuação de similaridade. É um arquivo. Os 11 apps rejeitados tinham Sources/Pro.swift na primeira submissão. Nenhum dos 8 apps no ar tinha esse arquivo na primeira aprovação. O Pro.swift é um paywall em StoreKit 2: o app é grátis, e uma compra única de $4,99 libera a versão completa. Aqui está o começo do arquivo do Odometer, no commit que a Apple analisou:

// Sources/Pro.swift (odometer repo, commit af40d3658)
/// Odometer Pro: one non-consumable. Keeping one car on schedule is free forever; Pro is the
/// whole garage and the paperwork.
@MainActor
@Observable
final class Pro {
    static let productID = "com.mattbusel.odometer.pro"
    /// The first build that has Pro in it. Anything earlier had every feature.
    static let firstFreemiumBuild = 2

    enum Reason: String, Identifiable { case costs, garage, history, export, settings; var id: String { rawValue } }

    private(set) var unlocked: Bool
    private(set) var grandfathered = false
    private(set) var product: Product?

    var price: String { product?.displayPrice ?? "$4.99" }

    func ask(_ why: Reason) { if !unlocked { paywall = why } }
    ...
}

Os arquivos não são cópias uns dos outros (nenhum par de apps rejeitados tem um Pro.swift idêntico; cada um tem o próprio produto, o próprio nível grátis e os próprios motivos para o upgrade). Mas o formato é o mesmo: um non-consumable, uma classe Pro, uma tela de paywall. Os apps no ar foram aprovados sem isso e só viraram freemium depois, por meio de atualizações enviadas em 26 de setembro, o mesmo dia dos 11 apps novos. Essas atualizações passaram tranquilamente em 29 de setembro.

Eis o que eu acho que está realmente acontecendo, e a Apple nunca vai dizer isso em voz alta. Um app novinho e grátis com desbloqueio de $4,99, vindo de uma conta que solta 11 deles num dia, é exatamente a silhueta de uma fazenda de templates. O texto da 4.3 e a regra irmã dela, a 4.2.6, foram escritos pensando em "commercialized template or app generation services" (serviços comerciais de templates ou de geração de apps). Em 2026, com qualquer agente de programação capaz de cuspir um app por dia, a fazenda de templates e o dev solo com Claude Code parecem iguais vistos de fora. O filtro da Apple julga a silhueta, e o humano que assina embaixo nunca abre o app. Correlação, não prova: 19 apps é uma amostra pequena. Mas é uma divisão mais limpa do que qualquer coisa no texto da guideline.

O que mandei de volta, e o que voltou: nada

A rejeição 4.3 vem com nove perguntas: o que o app faz, para quem é, em que ele se diferencia, como você o testou, se ele compartilha código com os seus outros apps, e assim por diante. Respondi a todas, app por app, com honestidade. Inclusive as partes que provavelmente me prejudicaram, como este trecho da resposta do Odometer, em que expliquei que não há framework compartilhado e que só dois arquivos seguem um padrão que reaproveito:

"No shared framework or asset pack. Every screen, model, illustration and text is specific to Odometer. Two files follow a pattern I reuse: the StoreKit 2 purchase handling for its one non-consumable (the paywall's text, free/Pro split and look are specific to the app), and a test-only driver that steps through the app's screens to record the walkthrough video and is inactive in normal use."

Depois abri recursos no App Review Board pelo formulário da Apple, que aceita no máximo 5 apps e 2.000 caracteres por motivo, então foram três formulários (5 + 5 + 1). O argumento era simples: os 11 foram rejeitados em um minuto, com texto idêntico palavra por palavra, então nenhuma análise individual aconteceu, e pedi que um humano abrisse cada app.

Isso foi em 5 de outubro. Hoje de manhã procurei na minha caixa de entrada qualquer coisa da Apple desde então. Há e-mails de cobrança do Apple Ads, um anúncio de pré-venda do iPhone Duo e um aviso de que as App Review Guidelines foram revisadas em 16 de outubro. Não há nenhum e-mail do App Review nem do App Review Board desde o segundo lote, em 12 de outubro, e absolutamente nada sobre os recursos. 13,8 dias e contando.

Essa revisão de 16 de outubro é um pequeno insulto à parte. A Apple reescreveu sete trechos das diretrizes (regras novas sobre materiais criativos e funções ocultas, links de pagamento, segurança infantil). A Guideline 4.3 não foi um deles. No meio de uma onda pública de rejeições 4.3 em lote, a regra continuou idêntica, palavra por palavra.

Os próprios números da Apple dizem que você não é especial

A Apple publica todo ano um App Store Transparency Report. A edição de 2025 contabiliza 9.100.620 submissões analisadas e 2.093.244 rejeitadas, cerca de 23%. A seção Design, que inclui spam e imitações, responde por 415.532 rejeições. O post de maio de 2026 no newsroom da Apple diz que ela rejeitou mais de 371.000 submissões por copiar outros apps, spam ou enganar usuários.

Agora olhe a linha que ninguém cita. O mesmo relatório contabiliza 26.305 recursos contra remoções de apps e 423 restaurações. Isso é 1,6%. Lá em 2021, o diretor sênior do App Review da Apple disse num documento judicial que a equipe tinha mais de 500 revisores humanos e que menos de 1% das rejeições recebe recurso. Faça a conta você mesmo: 9,1 milhões de submissões por ano dão umas 25.000 por dia. 371.000 rejeições do tipo spam dão cerca de 1.000 por dia. Ninguém abre 1.000 apps por dia com cuidado. O lote de 30 segundos não é uma falha nesse sistema. Ele é o sistema.

Opiniões polêmicas, em ordem

1. A 4.3 virou um imposto sobre volume para desenvolvedores solo. Ela não pega clones. Os meus dois apps mais parecidos estão no ar. Ela pega contas que lançam mais do que a Apple acha que uma pessoa deveria lançar. Na era da programação com IA, isso é todo dev indie que seja minimamente bom.
2. O App Review Board é um buraco negro para rejeições em lote. A minha aposta: esses 11 recursos não recebem resposta humana antes de novembro, e se um dia receberem, vai ser um parágrafo padrão para os 11.
3. A Apple nunca vai publicar números da 4.3 por conta própria. O relatório de transparência lista "4.3.0 Spam" só para remoções (418 apps), nunca para rejeições, porque uma contagem por guideline mostraria quanto da luta contra o "spam" é, na verdade, um freio em desenvolvedores novos.
4. Atualizações passam porque atualizações já dão dinheiro à Apple. Uma atualização de um app no ar é uma quantidade conhecida, com histórico de pagamentos. Um app novo é um custo. Todas as contas deste artigo tiveram atualizações aprovadas nas mesmas semanas em que os apps novos foram mortos. Isso não é coincidência, é modelo de negócio.
5. O Google vai comer esse mercado. O app do Martin estava no Google Play uma semana antes de a Apple rejeitá-lo pela segunda vez. Quando o primeiro lançamento do dev indie migrar para o Android, o discurso de "qualidade" da Apple vai ficar bem mais baixinho.

Como sobreviver a uma rejeição por spam da Guideline 4.3

Isto é o que eu faria diferente, com base nos dados acima e nas próprias páginas da Apple. É o conselho que agora eu mesmo sigo.

1. Nunca envie apps novos em lote. Um ou dois apps novos por conta por semana. Os "14 apps em 13 dias" do Porsche e os meus "11 num dia" receberam a mesma resposta. Atualizações de apps no ar podem ir tão rápido quanto você quiser.
2. Responda, e não reenvie. A rejeição diz isso, e eu ignorei. Os meus reenvios caíram num timer de sete dias e morreram em 27 segundos. Responda às nove perguntas no App Store Connect e espere.
3. Lance apps novos sem o paywall e adicione IAP numa atualização. 0 dos meus 8 apps aprovados tinham paywall na primeira aprovação; 11 de 11 apps rejeitados tinham. Amostra pequena, mas é a única divisão limpa que encontrei, e as atualizações freemium passaram todas as vezes.
4. Se os seus apps são variações, junte-os. A 4.3(a) literalmente manda você lançar um app só e vender as variações como compras dentro do app. Se um revisor conseguir descrever dois dos seus apps com uma frase só, ele vai fazer isso.
5. Marque uma conversa com o App Review. A Apple oferece horários de 30 minutos via Webex com o App Review para discutir as diretrizes. Quase ninguém fala disso. É o único canal em que um humano tem de olhar para você. É o meu próximo passo.
6. Recorra com detalhes concretos, um recurso por submissão. A página de recursos da Apple pede "specific reasons why you believe your app complies" (motivos específicos pelos quais você acredita que o app cumpre as regras). Horários de uma rejeição em lote são específicos. Até agora não bastaram, então combine isso com o item 5.

Se você quer o pipeline com que esses 20 apps foram criados e publicados (a partir de um PC com Windows, sem Mac), o guia completo de iOS no Windows cobre isso, e quanto custou criar 20 apps reais traz o lado financeiro.

Os números até agora

• Rejeitados pela 4.3, duas vezes: 11 apps (22 rejeições), 5 e 12 de outubro de 2026
• Tempo para rejeitar 11 apps: 30 segundos (5 de out.), 27 segundos (12 de out.)
• Ordem de envio vs ordem de rejeição: Spearman -0,06 e 0,06 (nenhuma relação)
• Espera na segunda rodada: de 167,7 a 167,9 horas para os 11 (a Apple diz 90% em até 48 h)
• Recursos abertos: 3 formulários cobrindo 11 apps, 5 de outubro. Respostas: 0 depois de 13,8 dias (caixa de entrada conferida à 1h10 da tarde, ET, 19 de outubro)
• No ar na App Store dos EUA hoje: 8 apps (consulta ao iTunes, 1h12 da tarde, ET, 19 de outubro), sem mudança desde 17 de outubro
• Par mais parecido entre os 190: Baseline Ledger + Fairway Ledger, 33% de linhas Swift em comum. Os dois no ar.
• Paywall na primeira submissão: 11 de 11 apps rejeitados, 0 de 8 apps aprovados

Os dados, e como rodar de novo

Horários das decisões: os 22 e-mails "There's an issue with your submission" do remetente do App Review da Apple, puxados do Gmail com as linhas "Submitted:" (Pacific Daylight Time) em 17 de outubro e conferidos de novo em 19 de outubro à 1h10 da tarde, horário do Leste, em busca de algo mais novo (nada). Impressões digitais: fingerprint.py executado à 1h19 da tarde, horário do Leste, em 19 de outubro, sobre 20 repositórios locais, cada um no commit anterior à submissão decisiva (git rev-list -1 --before=...), lendo os arquivos com git show, PNGs excluídos das comparações de arquivos, o nome do próprio app trocado por um marcador antes do hash. Status de publicação: a consulta à iTunes Search API para a minha conta de desenvolvedor, 1h12 da tarde, horário do Leste. Os posts de @krPorsche918, @vovalukashov e @martindonadieu foram capturados do X por volta da 1h15 da tarde, horário do Leste, em 19 de outubro, reais e sem edição.

Então, @martindonadieu, @vovalukashov, @krPorsche918: confiram os seus próprios e-mails de rejeição. Os de vocês chegaram com segundos de diferença entre si, e os reenvios esperaram exatamente uma semana? Se mais três contas mostrarem o mesmo timer de 168 horas, isso deixa de ser teoria minha. Todo o resto: o App Review Board da Apple já respondeu de verdade a um recurso seu contra a 4.3, e quanto tempo levou? Deixe os seus números nos comentários.

Está criando apps de iPhone sem Mac e quer o pipeline configurado no seu próprio repositório (assinatura, capturas de tela, submissão via fastlane e as notas de análise que uso agora)? O No-Mac iOS Pipeline custa $299, com o primeiro build no TestFlight em 5 dias úteis.