Guideline 5.1.1: como entender e corrigir a rejeição

A guideline 5.1.1 é a regra da Apple sobre coleta e armazenamento de dados. Nas minhas três rejeições dessa família, a causa sempre foi uma destas duas diferenças: o que o app fazia com os dados não batia com o que estava declarado, ou o pedido de permissão empurrava o usuário a dizer sim.

Este artigo trata só dessa regra: os incisos dela, o que eu verifico antes do envio e o que corrigir, com três rejeições que levei nos meus próprios apps. Para a visão geral de todos os motivos, leia por que a Apple rejeita um app.

O que é a guideline 5.1.1?

A guideline 5.1.1, “Data Collection and Storage”, define o que um app precisa respeitar assim que mexe com dados pessoais: uma política de privacidade completa, consentimento antes da coleta, pedidos de permissão honestos e uma conta que possa ser excluída. Ela vale para todos os apps, até os que quase não coletam nada.

O texto oficial está nas App Review Guidelines, seção 5 “Legal”, parte 5.1 “Privacy”. A mensagem da Apple muitas vezes cita um inciso específico, entre parênteses: 5.1.1(i), 5.1.1(iv), 5.1.1(v). É esse inciso que diz onde procurar.

Os cinco incisos da 5.1.1 para conhecer primeiro

Inciso	O que a Apple exige	A rejeição típica
5.1.1(i) Privacy Policies	Política completa e com link	Ausente ou incompleta
5.1.1(ii) Permission	Consentimento antes da coleta	Texto de permissão vago
5.1.1(iii) Data Minimization	Só os dados necessários	Acesso total às fotos
5.1.1(iv) Access	Não pressionar a aceitar	Tela que pressiona a aceitar
5.1.1(v) Account Sign-In	Nada de conta obrigatória	Login obrigatório

Três detalhes. A política de privacidade tem link no App Store Connect e dentro do app. Ela diz quais dados são coletados, como e para quê, confirma que os terceiros que os recebem oferecem a mesma proteção, e explica como retirar o consentimento ou pedir a exclusão dos dados. Um recurso pago não pode depender de um acesso a dados que o usuário tem o direito de recusar. E uma conta criada no app tem que poder ser excluída pelo próprio app.

A regra tem outros incisos, do (vi) ao (x), sobre casos mais específicos como as áreas regulamentadas ou a compilação de dados pessoais.

As três coisas que eu comparo antes do envio

Eu não tenho o manual do reviewer. Isto é o que eu mesmo comparo antes de cada envio, porque minhas rejeições vieram de uma diferença entre esses elementos:

• o que a política online diz, na URL declarada no App Store Connect;
• o que o app faz de verdade, tela por tela, incluindo cada pedido de permissão;
• o que está declarado na página do app, na parte de privacidade do app (App Privacy Details).

Também testo cada tela de permissão fechando o app e abrindo de novo. Foi a causa que identifiquei na minha segunda rejeição do Nolera.

Três rejeições 5.1.1 que eu levei, e a causa real

Clic: a política online era a versão antiga

O Clic transforma um produto em slides prontos para publicar, com IA. Em 16 de setembro de 2026, a Apple rejeita o app citando a 5.1.1(i) e a 5.1.2(i). A tela de consentimento para a IA estava no app. O problema estava fora do app: a política de privacidade publicada no site era a versão antiga. A nova existia, mas não tinha sido colocada no ar.

A correção: política completa publicada, resumo em inglês adicionado para o reviewer, notas de revisão atualizadas. Não fiz build novo: reenviei a mesma submissão.

A lição: a Apple lê o que está online, não o que está no seu repositório. No dia do envio, abra a URL da sua política e procure o nome de cada serviço de terceiros que seu app usa.

Nolera: um botão “Allow” antes do pedido do sistema

O Nolera é meu app de guarda-roupa. Em 17 de setembro de 2026, depois de uma revisão num iPad Air, a Apple cita a 5.1.1(iv). Antes do pedido de acesso à câmera, o app mostrava uma tela de explicação com um botão “Allow the camera”.

As regras de design da Apple são precisas nesse ponto. Uma tela própria colocada antes de um pedido do sistema deve ter um único botão, que abre esse pedido. A Apple recomenda um termo como “Continue” ou “Next”, e não “Allow”: um botão parecido com o do sistema leva a pessoa a tocar depois no “Allow” de verdade sem ter querido.

Essa regra vale para telas colocadas antes de um pedido do sistema: câmera, microfone, localização, contatos, calendário, rastreamento. Ela tem uma exceção, para um consentimento exigido por lei.

A correção: o botão agora se chama “Continue”, nos 8 idiomas do app.

A lição: uma tela que prepara uma permissão explica. Ela não decide no lugar do usuário.

Nolera, segunda rejeição: a tela “câmera negada” aparecia antes do pedido

Reenviado, o Nolera foi rejeitado uma segunda vez em 22 de setembro de 2026, de novo pela 5.1.1(iv), dessa vez num iPad Pro de 11 polegadas. A Apple apontou dois pontos: um link para o Settings antes do pedido de acesso, e uma tela da qual dava para sair sem ver esse pedido.

A causa que identifiquei: um caso que eu não tinha testado. A tela de captura mostrava o painel “câmera negada”, com o link para o Settings e uma alternativa, sempre que o acesso não estava concedido. Inclusive quando ele nunca tinha sido pedido. No fluxo normal, a tela de explicação vinha antes e estava tudo certo. Mas se você fechasse o app no meio e abrisse de novo, caía direto na captura, sem ter visto o pedido do sistema.

A correção: enquanto o iOS ainda puder fazer a pergunta, a própria tela dispara o pedido do sistema. O painel “câmera negada” só aparece depois de uma recusa de verdade. Essa correção exigiu um build novo, já que o reviewer testa o código embarcado.

A lição: “nunca pedido” e “negado” são dois estados diferentes. Teste cada tela de permissão voltando a ela depois de fechar o app, não só na ordem do fluxo.

5.1.1 e IA: o que a 5.1.2(i) acrescenta

No Clic, a Apple citou a 5.1.2(i) além da 5.1.1. Essa regra pede para indicar claramente onde os dados pessoais são compartilhados com terceiros, e ela cita explicitamente a IA de terceiros (“third-party AI”). Ela também exige uma permissão explícita antes do compartilhamento.

Minha prática desde essa rejeição: três coisas coerentes entre si.

• Uma tela de consentimento no app, antes do primeiro envio, dizendo para qual serviço os dados vão e quais são.
• A mesma informação na política de privacidade online.
• A mesma informação nas declarações de privacidade da página do app.

O detalhe do que a política precisa conter está em política de privacidade de um aplicativo.

O que responder à Apple depois de uma rejeição 5.1.1

A conversa acontece na seção App Review do seu app, no App Store Connect. O procedimento oficial para responder ao App Review é o mesmo das outras regras. Escreva em inglês, de forma simples: o que causava o problema, o que mudou, como verificar. Este é o modelo que eu uso (troque o número do build e a correção pelos seus):

Hello,

Thank you for your review.

Issue: the custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,

São dois casos:

• A causa está online (política, página de suporte, declarações da página do app): você corrige, responde, e a mesma submissão pode seguir sem build novo.
• A causa está no app (tela, botão, ordem dos pedidos): precisa de um build novo. Uma atualização remota não basta, como explico no guia sobre a guideline 2.1.

O checklist 5.1.1 antes da submissão

• A URL da sua política de privacidade abre, e a página online é a versão mais recente.
• A política cita cada serviço de terceiros que recebe dados, IA incluída. Essa é a minha regra, mais rígida que o texto da Apple.
• As declarações de privacidade da página do app dizem o mesmo que a política e que o privacy manifest do build.
• Cada texto de permissão explica o uso numa frase precisa.
• Nenhuma permissão é pedida na abertura se o app funciona sem ela. A mesma lógica vale para os modos de segundo plano: nenhum modo declarado sem um recurso que o use.
• Uma tela própria antes de um pedido tem um só botão, “Continue”, que abre o pedido do sistema.
• Quem recusa uma permissão consegue continuar de outro jeito, ou entende o que perde.
• A tela “acesso negado” só aparece depois de uma recusa real. Você testou fechando e abrindo o app de novo.
• O app pode ser usado sem conta quando a conta não é indispensável.
• Uma conta criada no app pode ser excluída pelo app: a receita está em exclusão de conta no iOS.
• Tudo testado no iPad também: minhas duas rejeições 5.1.1 no Nolera foram apontadas no iPad.

Corrija sua rejeição com alguém que já levou essa

Se seu app acabou de ser rejeitado pela 5.1.1, o Apple Review Kit ajuda você a encontrar a regra citada, o que ela exige, e um exemplo de correção e de resposta. Se quiser que a gente olhe seu caso junto agora mesmo, reserve uma hora comigo, por videochamada. O processo completo também está na página app rejeitado pela Apple.

Se você está preparando seu primeiro lançamento, faça o diagnóstico gratuito: ele coloca suas etapas em ordem e envia meu checklist anti-rejeição da Apple, privacidade incluída. Para criar seu aplicativo mobile pensado para a revisão desde o início, o percurso em quatro etapas do iOS Kit vai da ideia até o envio para a Apple.

Ninguém pode garantir que a Apple vai aprovar seu app. O que eu posso fazer é ajudar você a evitar as rejeições 5.1.1 que eu já paguei com um ciclo de revisão.

Perguntas frequentes

O que significa “Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage”?

É o título completo da regra na mensagem da Apple. Ele indica um problema com dados pessoais: política de privacidade incompleta, pedido de permissão considerado insistente, ou conta impossível de excluir. O inciso entre parênteses, por exemplo 5.1.1(iv), diz qual deles.

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

Nem sempre. Se a causa está online, como uma política de privacidade desatualizada, você corrige a página, responde à Apple e a submissão segue sem build novo. Se a causa é uma tela ou um botão do app, precisa de um build novo.

Posso mostrar uma tela de explicação antes de um pedido de permissão?

Sim, a Apple permite quando é realmente útil. A tela tem então um só botão, que abre o pedido do sistema, com um termo como “Continue” ou “Next”. Nada de botão “Allow”, nada de botão para fechar ou pular, salvo consentimento exigido por lei.

Meu app usa uma IA externa: o que preciso declarar?

A guideline 5.1.2(i) pede para indicar onde os dados são compartilhados com terceiros, IA incluída, e obter uma permissão explícita antes. Eu aplico isso em três lugares: uma tela de consentimento no app, a política de privacidade online e as declarações de privacidade da página do app. No Clic, a Apple citou essa regra junto com a 5.1.1.

A conta é obrigatória para cumprir a 5.1.1?

Não, é o contrário. Se seu app não tem um recurso que dependa de verdade de uma conta, a Apple pede que ele possa ser usado sem login. E se ele permite criar uma conta, também tem que permitir excluí-la pelo próprio app.