ITSAppUsesNonExemptEncryption: você precisa disso e o que colocar?

Toda build de iOS esbarra em uma pergunta de controle de exportação dos Estados Unidos, e nada no Xcode avisa que ela vem. Ela aparece como o status «Missing Compliance», que bloqueia o TestFlight e trava o seu envio. Esta página responde às duas únicas perguntas que importam: você precisa mesmo disso, e qual valor faz a pergunta parar de voltar a cada build.

Última revisão: 24 de julho de 2026.

O que o App Store Connect está perguntando de verdade

Apps distribuídos pela App Store são juridicamente «exportados» dos Estados Unidos, então caem sob as Export Administration Regulations (EAR). Quando sua build usa criptografia, o App Store Connect precisa saber se é do tipo comum (isenta) ou do tipo que exige papelada (não isenta). É só isso que a pergunta significa.

O detalhe: hoje quase todo app usa criptografia, porque qualquer chamada HTTPS usa. Então «seu app usa criptografia?» é quase sempre sim — mas a resposta que te destrava é sobre essa criptografia ser isenta, e para a imensa maioria dos apps ela é.

Árvore de decisão: você usa criptografia não isenta?

Percorra na ordem. O primeiro item que se aplicar decide a sua resposta.

Seu app não usa criptografia nenhuma, ou nada além do que o próprio iOS oferece? → Isento. Responda NÃO (ITSAppUsesNonExemptEncryption = false).
Toda a sua criptografia se limita a HTTPS/TLS ou às APIs criptográficas padrão que a Apple entrega no iOS/macOS (CryptoKit, Keychain, Secure Enclave etc.)? → Isento. Responda NÃO. Isso cobre a esmagadora maioria dos apps.
Você usa criptografia só para autenticação — hash de senhas, assinatura de tokens — e não para criptografar conteúdo do usuário? → Isento. Responda NÃO.
Você entrega o SEU PRÓPRIO algoritmo de criptografia, ou usa criptografia para proteger dados do usuário além do acima (por exemplo, um esquema ponta a ponta próprio, uma cifra sob medida, arquivos criptografados com gerenciamento de chaves próprio)? → Possivelmente não isento. Responda SIM e faça a autoclassificação (veja abaixo).

Reaproveitar criptografia padrão através de um wrapper seu não a torna não isenta — o que conta é o algoritmo por baixo, não o embrulho. Inventar ou embutir um algoritmo fora do padrão é o que empurra você para a categoria não isenta.

As duas formas de responder — e por que a plist vence

Existem exatamente dois lugares para responder isso. Eles não são equivalentes: um pergunta a cada versão, o outro responde uma vez e continua respondido.

Onde	Com que frequência pergunta	Melhor para
O aviso do App Store Connect	A cada build. Todo envio ao TestFlight ou à App Store mostra «Missing Compliance» até você percorrer as perguntas de novo.	Casos pontuais, ou quando você não pode publicar um binário novo agora.
ITSAppUsesNonExemptEncryption no Info.plist	Nunca mais. O valor viaja dentro do binário; o App Store Connect o lê e pula a pergunta para aquela build e todas as futuras que carregarem a chave.	Todo app que não entrega criptografia própria — configure uma vez e esqueça.

Os dois atendem à mesma exigência de conformidade de exportação dos EUA; a chave na plist só responde a ela de forma permanente.

O trecho exato da plist

Adicione isto ao Info.plist do target do seu app (ou pela aba Info / um xcconfig). É um booleano:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Depois faça Clean Build Folder (⇧⌘K), arquive de novo e envie. Colocar false só é correto se o seu app for isento segundo a árvore acima — é uma declaração legal, não um botão de silenciar. Uma sutileza: uma build que já está no App Store Connect não pega a chave retroativamente. Responda à pergunta daquela build na mão para liberá-la agora, e entregue a chave no próximo arquivamento para nunca mais ser perguntado.

Quando você realmente precisa da isenção / autoclassificação

Se o passo 4 da árvore se aplicou — você entrega criptografia fora do padrão ou própria — responder SIM não é o fim. Você assume obrigações reais sob as EAR:

Autoclassificação: determine o ECCN do seu app (normalmente 5D002) e confirme que ele se enquadra na License Exception ENC conforme a EAR §740.17.
Relatório anual de autoclassificação: para a maioria dos apps de criptografia de mercado de massa, é preciso enviar por e-mail, uma vez por ano, um relatório ao BIS e ao coordenador de solicitações de criptografia ENC/NSA (o relatório de fim de ano).
CCATS: alguns produtos precisam de uma classificação formal (CCATS) do Bureau of Industry and Security antes de se qualificarem — o App Store Connect vai então pedir essa autorização.
Documentação no App Store Connect: você informa a base da sua isenção ou os dados de CCATS/ERN na seção de criptografia, versão a versão, a menos que tenha fornecido um código de conformidade.

Isso é realmente raro em apps de consumo. Se você usa CryptoKit, Keychain, TLS e nada exótico, está isento e nada disso se aplica: responda NÃO e siga em frente.

Na dúvida sobre a isenção da sua criptografia? A Apple aponta para o Bureau of Industry and Security dos EUA; o teste prático é «eu implementei um algoritmo de criptografia, ou só chamo o da Apple / uso HTTPS?». O segundo caso é isento.

A falha comum: a chave simplesmente não existe

O jeito mais frequente de isso doer não é um valor errado, é nenhum valor. Com a chave ausente:

Toda build do TestFlight cai em «Missing Compliance» e seus testadores não conseguem instalar até você responder à pergunta no App Store Connect — os convites simplesmente não chegam.
Uma build enviada para a App Store não avança para a revisão até a conformidade ser resolvida, então ela fica parada enquanto você acha que está na fila.
Como o aviso volta a cada envio, um pipeline de CI/CD que submete builds automaticamente trava em toda execução — o clássico «por que o TestFlight está parado».

A correção é a mesma de cima: defina ITSAppUsesNonExemptEncryption uma vez no Info.plist (se você for isento) para que nenhuma build volte ao estado Missing Compliance.

Perguntas frequentes

Meu app só faz chamadas HTTPS. Ele é isento?

Sim. HTTPS/TLS e a criptografia padrão embutida no iOS são criptografia isenta. Coloque ITSAppUsesNonExemptEncryption como NO. É o caso da grande maioria dos apps.

Colocar a chave como NO libera tanto o TestFlight quanto a App Store?

Sim — o mesmo valor do Info.plist satisfaz a pergunta de conformidade de exportação para a distribuição no TestFlight e na App Store de uma vez, então você decide uma vez em vez de canal a canal.

Coloquei a chave e o App Store Connect ainda mostra Missing Compliance. Por quê?

Uma build que já tinha sido enviada antes de você adicionar a chave não a pega retroativamente. Responda à pergunta daquela build na mão no App Store Connect para liberá-la e entregue a chave no próximo arquivamento — as builds futuras não vão perguntar.

Responder NÃO é alguma vez a escolha errada?

Sim, se você realmente entrega criptografia não isenta: um algoritmo próprio ou criptografia que protege dados do usuário além do HTTPS e da criptografia do sistema. Aí você precisa responder SIM e fazer a autoclassificação (ECCN, License Exception ENC e possivelmente o relatório anual ou um CCATS). É uma declaração legal, então responda com a verdade.

O que é o relatório anual (de fim de ano) de criptografia?

Para apps de mercado de massa que usam criptografia não isenta sob a License Exception ENC, a regulamentação dos EUA exige um relatório anual de autoclassificação enviado por e-mail ao BIS e ao coordenador ENC. Apps isentos (só HTTPS) não apresentam esse relatório.

Veja também: O manifesto de privacidade da Apple (PrivacyInfo.xcprivacy) · Checklist de envio para a App Store

Fontes

Verifique sua build antes de enviar

Passe seu .ipa ou .apk pelo App Review Checker e pegue esses problemas em segundos.

Verificar um app