Guideline 5.6: o paywall que faz a Apple recusar seu app

A guideline 5.6 é o código de conduta do desenvolvedor. Para um paywall, a Apple a cita com uma frase padrão: o app "attempts to manipulate customers into making unwanted In-App Purchases". Traduzindo: um botão do seu fluxo de compra não faz o que promete, ou uma oferta volta sem que o usuário tenha pedido. A correção cabe em uma regra: cada botão faz o que diz, e só o usuário escolhe o momento de ver uma oferta de novo.

Levei essa recusa na TradaZen, meu app de treino de trading, cujo lançamento eu conto neste estudo de caso. Aqui vão a regra, o que encontrei no meu paywall, os padrões a evitar e a minha resposta à Apple. Para a regra vizinha sobre pedidos de avaliação, leia o guia da guideline 5.6.3.

O que diz a guideline 5.6?

A 5.6, "Developer Code of Conduct", fica na seção 5 "Legal" das App Review Guidelines. O primeiro parágrafo fala de respeito: com os clientes, nas respostas às avaliações e nas conversas com a Apple. O segundo mira diretamente as compras.

O texto atual estabelece o princípio: "Customer trust is a cornerstone of the App ecosystem." Depois lista o que um app nunca deve fazer: se aproveitar dos usuários, aplicar golpes, "trick them into making unwanted purchases", forçá-los a compartilhar dados desnecessários, "raise prices in a tricky manner", cobrar por algo que não é entregue, ou qualquer outra prática manipuladora, dentro ou fora do app.

Em bom português: você não pode conseguir uma compra na base da malandragem. O texto não traz uma lista de botões proibidos. Ele julga o efeito: o usuário pagou porque quis, ou porque a tela o enganou?

A 5.6 também reúne quatro sub-regras:

Sub-regra	O que ela cobre
5.6.1 App Store Reviews	Avaliações e pedidos de nota
5.6.2 Developer Identity	Informações corretas sobre você
5.6.3 Discovery Fraud	Fraude de visibilidade
5.6.4 App Quality	Reclamações, reembolsos

A punição está escrita na regra: "Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program." Ou seja, comportamentos manipuladores repetidos levam à exclusão do programa de desenvolvedor. É uma regra geral, e um bom motivo para corrigir todo o fluxo de compra logo na primeira recusa.

A mensagem de recusa 5.6 para um paywall

A mensagem costuma repetir a mesma frase: "The app attempts to manipulate customers into making unwanted In-App Purchases." A Apple nem sempre diz qual elemento é o problema. Na minha recusa, não havia mais nada.

Outros desenvolvedores descrevem a tela em questão. Em um tópico do fórum da Apple de novembro de 2024, um desenvolvedor liga a recusa 5.6 a uma oferta única, mostrada quando o usuário fechava a primeira tela de assinatura.

A 5.6 não mira só paywalls. Um desenvolvedor também foi recusado por funções que pareciam escondidas durante a revisão. Se a sua recusa 5.6 não fala de compra, procure primeiro o que o revisor não conseguiu ver.

Minha recusa 5.6 na TradaZen

Em 12 de outubro de 2026, a Apple recusou a versão 1.5.1 da TradaZen, testada num iPad Air. Motivo: guideline 5.6, com a frase padrão sobre compras indesejadas. Nenhuma tela citada.

Então reli todo o meu fluxo de compra como alguém que só quer dizer não. O paywall do fim do onboarding não tem botão de fechar: o app pede o teste ou a assinatura para continuar. Três mecanismos em volta dele podiam passar por manipulação:

• Um X falso. No topo da tela, um botão em forma de X, anunciado como "Fechar" pelo VoiceOver, abria uma oferta com desconto em vez de fechar.
• Uma oferta que voltava sozinha. Enquanto a oferta estava valendo, ela reabria quando o usuário voltava ao app.
• Um lembrete promocional. Sair do app a partir do paywall agendava uma notificação anunciando um desconto exclusivo.

Um detalhe importa: esses mecanismos já existiam na versão anterior, aprovada três dias antes. Uma aprovação não valida seu paywall para sempre: outro revisor pode ler a mesma tela de outro jeito.

O que eu mudei

• O X sumiu dessa tela. No lugar, um ícone de presente, anunciado como "Desconto exclusivo" pelo VoiceOver, abre a oferta quando tocado. Nada mais finge fechar.
• A oferta nunca mais abre sozinha quando o usuário volta ao app.
• A notificação de desconto foi removida. Ficou um lembrete suave, enviado uma única vez por instalação e só se as notificações estiverem autorizadas. Ele não fala de preço, nem de desconto, nem de prazo.
• Esse lembrete está descrito na mensagem para o App Review, com o texto e o momento de envio.

O que eu mantive

Também reli o que sobrou, me perguntando se cada elemento realmente deixava escolha.

• Uma oferta depois de uma compra cancelada. Se o usuário cancela a folha de pagamento da Apple para a assinatura anual, abre uma oferta de boas-vindas. Ela tem uma única janela de 5 minutos, que não reinicia: se o usuário cancelar de novo nesse prazo, ela reabre. Fecha com um gesto, pelo X ou por "Não, obrigado", e mostra o preço real do produto.
• Um timer real de 5 minutos. O prazo final é salvo no aparelho na primeira exibição. Ele continua correndo com o app fechado e não zera ao reabrir. Quando acaba, a oferta some para essa instalação do app. Se o usuário fecha antes, um pequeno selo mostra o tempo restante e só reabre a oferta se for tocado.
• Um baú com cadeado. Ele mostra os itens ganhos durante o onboarding, e só esses, trancados enquanto o app não é desbloqueado. Nada diz que eles serão perdidos.

Esses elementos estão nas notas de revisão. A recusa não citava nenhuma tela, então não os apresento como aprovados pela Apple. São, na minha opinião, as versões transparentes dessas mecânicas, e eu as declarei.

A correção exigiu um novo build, já que tudo acontecia dentro do app. A TradaZen voltou para revisão em 13 de outubro de 2026.

Os dark patterns de paywall que disparam a 5.6

A Apple não publica uma lista. Uma mesma mecânica muitas vezes existe em duas versões: a que engana e a que deixa escolher. Esta tabela separa as duas, cruzando o texto das regras, recusas publicadas por outros desenvolvedores e a minha. A versão transparente não garante aprovação. É a que não tenta enganar. A última coluna diz em que cada linha se apoia.

Versão manipuladora	Versão transparente	Base
Um X que abre uma oferta em vez de fechar	O X fecha. Uma tela que não fecha não mostra X	Corrigido após minha recusa na TradaZen
Uma oferta "única" que surge quando você fecha o paywall	Um desconto atrás de um botão que o anuncia claramente	Recusa publicada no fórum da Apple
Uma segunda oferta lançada após uma recusa, num paywall com preço enganoso	Uma só oferta após compra cancelada, com preço real, fechável com um gesto	Caso Cal AI; conversa relatada pela Superwall
Um paywall ou oferta que reabre sozinho quando o usuário volta ao app	Ele volta quando o usuário atinge um limite ou toca num botão que o avisa	Corrigido após minha recusa na TradaZen
Uma notificação promocional que ninguém pediu	Promoção após consentimento explícito, com opção de sair no app	Regra 4.5.4
Um timer falso, que zera ou cuja oferta volta depois do fim	Um prazo real, que continua com o app fechado e termina de verdade	Minha leitura de "trick them", regra 5.6
Recompensas inventadas, ou ameaçadas de sumir sem compra	Os ganhos reais do usuário, mostrados sem ameaça de perdê-los	Minha leitura da regra 5.6
Um teste grátis que esconde a cobrança automática	Duração do teste e preço cobrado depois, ao lado do botão	Página de assinaturas da Apple
Um preço por semana em letras grandes, o valor cobrado em letras pequenas	O valor cobrado é o preço mais visível da tela	Página de assinaturas da Apple
Um botão de recusa que culpa o usuário	Uma recusa neutra, como "Agora não" ou "Não, obrigado"	Minha leitura da regra 5.6

O caso Cal AI foi relatado pelo TechCrunch: a Apple citou a 5.6 por uma segunda oferta de assinatura mostrada a quem recusava a primeira. O mesmo paywall também foi apontado na 3.1.2(c): o preço por semana dominava o valor cobrado, e o teste escondia a renovação automática. A matéria não descreve a segunda oferta em mais detalhes.

Do outro lado, a Superwall, uma empresa de ferramentas de paywall que vende esse tipo de oferta, relata uma conversa não oficial com a Apple em junho de 2026. Uma oferta mostrada após uma compra cancelada é descrita ali como permitida. A insistência não é: uma oferta que volta a cada sessão, ou um fluxo do qual só se sai pagando. A Superwall deixa claro que não são regras oficiais e que o revisor mantém o próprio julgamento. Uma oferta após uma recusa continua, portanto, numa zona cinzenta: o texto não proíbe, existem recusas publicadas, e o jeito de fazer conta.

A regra sobre notificações é a 4.5.4: nada de promoção por notificação sem consentimento explícito obtido no app, nem sem uma forma de cancelar.

Sobre preço, a página da Apple sobre assinaturas é clara: o valor cobrado deve ser o elemento de preço mais visível. O motivo cabe em uma frase: "This ensures that people are not misled." A regra 3.1.2 acrescenta que a Apple remove apps que vendem assinatura de forma enganosa ou com "bait-and-switch".

O teste que eu aplico agora: cada botão faz exatamente o que a aparência dele promete, e o usuário consegue dizer não com um gesto, sem que a oferta volte sozinha?

Os erros de paywall mais clássicos, que custam vendas sem necessariamente causar recusa, estão em paywall iOS: 7 erros de iniciante.

Como corrigir uma recusa 5.6

1. Liste todo o seu fluxo de compra. Paywall, ofertas secundárias, timers, notificações, lembretes ao voltar ao app. A Apple nem sempre diz o que está apontando. Para cada elemento, confira se ele está na versão transparente: fechável com um gesto, timer real, preço exato, nenhuma volta automática. Corrija ou remova tudo o que parecer armadilha, não só o elemento mais provável.
2. Refaça o caminho do revisor. Apague o app, reinstale, termine o onboarding e depois recuse tudo: feche, cancele, saia do app, volte. Anote cada tela que abre sem você pedir e confira se dá para fechá-la com um gesto.
3. Prepare um novo build. A causa está no app, ou seja, no código embarcado. Uma atualização remota não substitui o build, como explico no guia da guideline 2.1.
4. Não guarde nada na manga. Reativar uma oferta remotamente depois da aprovação é o mesmo que esconder uma função do revisor. A própria RevenueCat alerta contra isso no artigo sobre ofertas de saída.
5. Responda no App Store Connect, em inglês, respondendo à mensagem do App Review.

Aqui vai um modelo tirado da minha resposta e das minhas notas de revisão, encurtado. Troque o número do build e as mudanças pelas suas, depois liste o que continua no app:

Hello,

Thank you for your feedback on Guideline 5.6.

Issue: on the subscription screen, the button in the top
corner looked like a close button, but it opened a
discounted offer instead of closing the screen.

Changes in build X:
- Nothing on the subscription screen pretends to close it.
  A clearly labeled button now opens the optional offer.
- The offer never reopens by itself when the user comes
  back to the app.
- The notification announcing a discount has been removed.

Still in this build (also described in the review notes):
- [Each remaining offer: what triggers it, how often it
  appears, how the user dismisses it.]
- [Each remaining reminder: its text, when it is sent,
  and under which conditions.]

If another part of the purchase flow still looks unclear,
please tell me which screen, and I will change it.

Best regards,

O que você escreve precisa bater exatamente com o build. Se mantiver um lembrete ou uma oferta, mesmo disparada automaticamente, descreva-os na resposta e nas notas de revisão. Se achar que o revisor errou, a Apple permite recorrer ao App Review Board, com um único recurso por envio recusado. Para um paywall, corrigir me parece mais seguro do que contestar. Os outros motivos de recusa e como responder a eles estão em por que a Apple recusa um app.

O checklist anti-5.6 antes do envio

• Todo X fecha a tela. Uma tela que não fecha não mostra X.
• Cada botão diz o que faz, na tela e para o VoiceOver.
• Nenhuma oferta se esconde atrás de um botão de fechar.
• Uma oferta disparada por uma recusa, se você mantiver uma, cabe numa única janela que não reinicia, com preço real, e fecha com um gesto.
• Nenhum paywall ou oferta reabre sozinho quando o usuário volta ao app.
• Nenhuma notificação promocional sem consentimento explícito no app.
• Sem timer falso: um prazo exibido é real, não zera e termina de verdade.
• O que a tela mostra como ganho foi ganho de verdade, sem ameaça de perda.
• O teste mostra a duração e o preço cobrado depois.
• O valor cobrado é o preço mais visível da tela.
• As notas de revisão descrevem cada oferta e cada lembrete presentes no build.
• Você refez o caminho recusando tudo, no iPhone e no iPad.

Revise seu paywall antes da Apple

O Review Kit reúne meu checklist pré-envio, minhas recusas corrigidas e duas skills do Claude Code que revisam seu projeto, seu paywall e sua página na loja. Se a Apple recusar, elas preparam sua resposta. Para um olhar humano, agende uma hora comigo: a gente refaz seu fluxo de compra juntos, na sua tela. O passo a passo completo após uma recusa está na página app recusado pela Apple, e a parte técnica das assinaturas em assinaturas in-app no iOS.

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-recusa da Apple. A página inicial mostra como criar um aplicativo mobile com um paywall pensado para a revisão desde o começo.

Ninguém pode garantir que a Apple vai aprovar seu app. O que eu posso fazer é te ajudar a evitar uma recusa 5.6 que eu já paguei com um ciclo de revisão.

Perguntas frequentes

O que significa "Guideline 5.6 - Developer Code of Conduct" numa recusa?

É o título da regra sobre o código de conduta do desenvolvedor. Para um app com compras integradas, quase sempre indica um fluxo de compra considerado manipulador: botão de fechar falso, oferta que volta sozinha, teste ou preço apresentados de forma enganosa. A mensagem nem sempre diz qual tela é o problema.

A Apple proíbe ofertas de saída?

O texto não proíbe com todas as letras. A RevenueCat também observa isso, mas avisa que desenvolvedores já foram recusados por esse motivo. As recusas publicadas miram uma oferta que surge quando o usuário fecha o paywall, ou uma segunda oferta lançada após uma recusa. O que define a versão transparente: uma oferta opcional, limitada a uma única janela que não reinicia, com preço real, fechável com um gesto, que não volta sozinha, com um timer real se houver um. Descreva-a nas notas de revisão. Ninguém pode garantir que um revisor vai enxergá-la assim.

Um paywall sem X é permitido?

As regras não exigem um X, e essa foi a escolha feita na TradaZen depois dessa recusa. O que a Apple recusa é um botão que parece fechar e faz outra coisa. Mesmo assim, um desenvolvedor relatou uma recusa 5.6 por um paywall sem saída num app de download gratuito. Mostre o valor antes de pedir o teste e deixe claro na página da loja que o app é pago.

Preciso de um novo build depois de uma recusa 5.6?

Sim, na maioria dos casos, porque a causa é uma tela ou um comportamento do app. Se o problema estiver fora do app, na página da loja ou nos metadados, uma correção sem build pode bastar. Na dúvida, pergunte ao revisor qual tela ele está apontando.

Uma recusa 5.6 pode levar ao encerramento da conta de desenvolvedor?

A regra prevê isso em caso de comportamentos manipuladores repetidos, com exclusão do programa de desenvolvedor. Ela também prevê que uma conta encerrada pode ser restabelecida após um plano de melhoria por escrito, aprovado e depois verificado pela Apple. Por isso vale corrigir todo o fluxo logo na primeira recusa.

Qual a diferença entre a 5.6 e a 5.6.3?

A 5.6 é o código de conduta geral: respeito, confiança, nenhuma compra obtida na malandragem. A 5.6.3 é uma das sub-regras dela, sobre manipulação de rankings, da busca e das avaliações. A Apple a citou na Solys por um pedido de avaliação colocado no onboarding.