ITSAppUsesNonExemptEncryption: ti serve davvero, e che valore mettere?

Ogni build iOS incontra una domanda sul controllo delle esportazioni statunitensi, e niente in Xcode ti avvisa che sta arrivando. Si presenta come uno stato «Missing Compliance» che blocca TestFlight e ferma la tua submission. Questa pagina risponde alle uniche due domande che contano: ti serve davvero, e quale valore fa smettere la richiesta a ogni build.

Ultima verifica: 24 luglio 2026.

Che cosa sta chiedendo davvero App Store Connect

Le app distribuite tramite l'App Store sono giuridicamente «esportate» dagli Stati Uniti, quindi ricadono nelle Export Administration Regulations (EAR). Quando la tua build usa crittografia, App Store Connect deve sapere se è quella ordinaria (esente) o quella che richiede pratiche (non esente). Il significato della domanda è tutto qui.

Il trucco: oggi quasi tutte le app usano crittografia, perché lo fa qualsiasi chiamata HTTPS. Quindi «la tua app usa crittografia?» è quasi sempre sì; ma la risposta che ti sblocca riguarda se quella crittografia è esente, e per la stragrande maggioranza delle app lo è.

Albero decisionale: usi crittografia non esente?

Percorrilo in ordine. Il primo punto che corrisponde decide la tua risposta.

La tua app non usa alcuna crittografia, o nulla oltre a quella che fornisce iOS? → Esente. Rispondi NO (ITSAppUsesNonExemptEncryption = false).
Tutta la tua crittografia si limita a HTTPS/TLS o alle API crittografiche standard che Apple include in iOS/macOS (CryptoKit, Keychain, Secure Enclave, ecc.)? → Esente. Rispondi NO. Copre la stragrande maggioranza delle app.
Usi la crittografia solo per l'autenticazione — hash delle password, firma dei token — e non per cifrare contenuti dell'utente? → Esente. Rispondi NO.
Distribuisci un TUO algoritmo di cifratura, o usi la crittografia per proteggere dati dell'utente oltre a quanto sopra (per esempio uno schema end-to-end proprietario, un cifrario su misura, file cifrati con una tua gestione delle chiavi)? → Potenzialmente non esente. Rispondi SÌ e completa l'autoclassificazione (vedi sotto).

Riutilizzare crittografia standard attraverso un tuo wrapper di comodo non la rende non esente: conta l'algoritmo sottostante, non l'involucro. È inventare o incorporare un algoritmo non standard che ti fa scivolare nel non esente.

I due modi di rispondere — e perché vince il plist

I posti in cui rispondere sono esattamente due. Non sono equivalenti: uno te lo chiede a ogni release, l'altro risponde una volta e resta risposto.

Dove	Ogni quanto lo chiede	Ideale per
La richiesta di App Store Connect	A ogni build. Ogni caricamento su TestFlight o App Store mostra «Missing Compliance» finché non ripercorri le domande.	Un caso isolato, o quando non puoi pubblicare subito un nuovo binario.
ITSAppUsesNonExemptEncryption nell'Info.plist	Mai più. Il valore viaggia dentro il binario; App Store Connect lo legge e salta la domanda per quella build e per tutte le successive che portano la chiave.	Ogni app che non distribuisce crittografia proprietaria: imposta una volta e dimentica.

Entrambe soddisfano lo stesso requisito statunitense di conformità all'export; la chiave nel plist si limita a rispondere una volta per sempre.

Lo snippet esatto del plist

Aggiungi questo all'Info.plist del target della tua app (o dalla scheda Info / un xcconfig). È un booleano:

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

Poi Clean Build Folder (⇧⌘K), archivia di nuovo e carica. Impostarlo a false è corretto solo se la tua app è esente secondo l'albero qui sopra: è una dichiarazione legale, non un tasto muto. Una sottigliezza: una build già presente in App Store Connect non recupera la chiave retroattivamente. Rispondi a mano alla domanda di quella build per sbloccarla subito, e spedisci la chiave nel prossimo archivio così non te la chiederà più.

Quando ti serve davvero l'esenzione / l'autoclassificazione

Se ha corrisposto il punto 4 dell'albero — distribuisci crittografia non standard o proprietaria — rispondere SÌ non è la fine. Ti assumi obblighi reali ai sensi delle EAR:

Autoclassificazione: determina l'ECCN della tua app (di norma 5D002) e conferma che rientri nella License Exception ENC ai sensi dell'EAR §740.17.
Report annuale di autoclassificazione: per la maggior parte delle app di crittografia di massa devi inviare una volta l'anno un report via email al BIS e al coordinatore delle richieste di crittografia ENC/NSA (il report di fine anno).
CCATS: alcuni prodotti richiedono una classificazione formale (CCATS) del Bureau of Industry and Security per rientrare nei requisiti; App Store Connect ti chiederà allora quell'autorizzazione.
Documentazione in App Store Connect: indichi la base della tua esenzione o i riferimenti CCATS/ERN nella sezione crittografia, release per release, salvo che tu abbia fornito un codice di conformità.

È davvero raro per un'app di consumo. Se usi CryptoKit, Keychain, TLS e nulla di esotico, sei esente e niente di tutto questo ti riguarda: rispondi NO e vai avanti.

Non sei sicuro che la tua crittografia sia esente? Apple rimanda al Bureau of Industry and Security statunitense; la prova pratica è «ho implementato un algoritmo di cifratura, o chiamo solo quello di Apple / uso HTTPS?». Il secondo caso è esente.

L'errore comune: la chiave del tutto assente

Il modo più frequente in cui questa cosa morde non è un valore sbagliato: è nessun valore. Con la chiave assente:

Ogni build TestFlight finisce in «Missing Compliance» e i tuoi tester non possono installarla finché non rispondi alla domanda in App Store Connect: gli inviti semplicemente non arrivano.
Una build inviata all'App Store non passa alla revisione finché la conformità non è risolta, quindi resta ferma mentre tu la credi in coda.
Poiché la richiesta torna a ogni caricamento, una pipeline CI/CD che invia build in automatico si blocca a ogni esecuzione: il classico «perché TestFlight è fermo».

La soluzione è la stessa di sopra: imposta ITSAppUsesNonExemptEncryption una volta nell'Info.plist (se sei esente) così nessuna build entrerà mai più nello stato Missing Compliance.

Domande frequenti

La mia app fa solo chiamate HTTPS. È esente?

Sì. HTTPS/TLS e la crittografia standard integrata in iOS sono crittografia esente. Imposta ITSAppUsesNonExemptEncryption su NO. È il caso della grande maggioranza delle app.

Impostare la chiave su NO sblocca sia TestFlight sia l'App Store?

Sì: lo stesso valore dell'Info.plist soddisfa la domanda sulla conformità all'export per la distribuzione TestFlight e per quella App Store insieme, quindi decidi una volta invece che canale per canale.

Ho impostato la chiave ma App Store Connect mostra ancora Missing Compliance. Perché?

Una build caricata prima che aggiungessi la chiave non la recupera retroattivamente. Rispondi a mano alla domanda di quella build in App Store Connect per sbloccarla, poi spedisci la chiave nel prossimo archivio: le build future non chiederanno più.

Rispondere NO è mai la scelta sbagliata?

Sì, se distribuisci davvero crittografia non esente: un algoritmo proprietario o crittografia che protegge dati dell'utente oltre a HTTPS e alla crittografia di sistema. Allora devi rispondere SÌ e completare l'autoclassificazione (ECCN, License Exception ENC ed eventualmente il report annuale o un CCATS). È una dichiarazione legale: rispondi con verità.

Che cos'è il report annuale (di fine anno) sulla crittografia?

Per le app di massa che usano crittografia non esente sotto License Exception ENC, la normativa statunitense richiede un report annuale di autoclassificazione inviato via email al BIS e al coordinatore ENC. Le app esenti (solo HTTPS) non lo presentano.

Da leggere anche: Il manifesto della privacy di Apple (PrivacyInfo.xcprivacy) · Checklist di invio all'App Store

Fonti

Controlla la tua build prima di inviarla

Fai passare il tuo .ipa o .apk attraverso App Review Checker e individua questi problemi in pochi secondi.

Controlla un'app