ITMS-90683: risolvere “Missing purpose string” con Expo

ITMS-90683 è un rifiuto automatico di Apple: arriva via e-mail poco dopo l'invio della tua build, prima di qualsiasi revisione umana. Significa che nel tuo file Info.plist manca la frase che spiega perché l'app accede a un dato sensibile. La correzione si fa in due mosse: aggiungere a ios.infoPlist la chiave citata nel messaggio, poi rifare una build.

Mi è capitato con Solys, la mia sveglia con minigiochi, per un dato che l'app non usa nemmeno. Ecco cosa vuol dire il messaggio, perché arriva e come evitarlo.

Cosa significa l'errore ITMS-90683?

Il messaggio completo si intitola "ITMS-90683: Missing purpose string in Info.plist". Dice che il codice della tua app fa riferimento a un'API che tocca dati sensibili (foto, fotocamera, microfono, posizione, contatti) e che il tuo Info.plist non contiene la chiave di descrizione corrispondente. Il messaggio indica il nome della chiave, per esempio NSPhotoLibraryUsageDescription.

Questa frase di descrizione si chiama "purpose string". È il testo che iOS mostra nella finestra di richiesta di autorizzazione. Apple lo scrive nella sua documentazione sull'accesso alle risorse protette: App Review rifiuta le app il cui codice accede a queste risorse senza purpose string.

Non è il rifiuto di un reviewer. Il controllo è automatico e scatta alla consegna della build, prima della revisione, come ITMS-91053 per il privacy manifest. La build viene scartata e devi inviarne un'altra.

Perché Apple rifiuta anche se la tua app non usa quel dato

È il punto che sorprende. Apple analizza il codice contenuto nella tua build, non quello che la tua app fa davvero. Se una libreria che includi contiene un riferimento alla libreria foto, la chiave è obbligatoria, anche se nessuna schermata chiede mai l'accesso alle foto. Lo precisa lo stesso messaggio di Apple: una libreria o un SDK esterno può fare riferimento a queste API, e la purpose string resta obbligatoria.

Il mio caso, il 26 settembre 2026. Mentre ripulivo la configurazione di Solys, avevo tolto la chiave NSPhotoLibraryUsageDescription, visto che l'app non tocca nessuna foto. La build successiva è stata rifiutata con ITMS-90683. La causa: due librerie di Expo che l'app usa, expo-image e expo-file-system, contengono codice che fa riferimento alla libreria foto. La build precedente passava perché la chiave c'era ancora.

La lezione: una chiave di descrizione non si toglie "perché non la usi". Si toglie solo quando nessuna libreria della build fa più riferimento all'API.

Le chiavi più comuni

• NSPhotoLibraryUsageDescription: lettura o scrittura delle foto.
• NSPhotoLibraryAddUsageDescription: aggiunta di foto, senza lettura.
• NSCameraUsageDescription: fotocamera.
• NSMicrophoneUsageDescription: microfono.
• NSLocationWhenInUseUsageDescription: posizione durante l'uso.
• NSContactsUsageDescription: contatti.
• NSUserTrackingUsageDescription: tracciamento pubblicitario (App Tracking Transparency).

Apple descrive ogni chiave nella sua documentazione, per esempio quella di NSPhotoLibraryUsageDescription: è obbligatoria appena l'app usa un'API che legge o scrive nella libreria foto.

Correggere ITMS-90683 in un'app Expo

1. Annota la chiave citata nell'e-mail di Apple. Il messaggio riporta il nome esatto.
2. Aggiungila nella tua configurazione, sotto ios.infoPlist, come indica la documentazione di Expo sulle autorizzazioni:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryUsageDescription": "Solys non accede alle tue foto. Questa autorizzazione non viene mai richiesta."
      }
    }
  }
}

3. Rifai una build. Expo lo specifica: una modifica all'Info.plist non passa con un aggiornamento da remoto, richiede un nuovo binario.
4. Rinvia la build ad Apple, poi selezionala nella tua versione.

Una trappola se la tua app è tradotta: i file di lingua traducono una chiave, non la dichiarano. La chiave deve prima esistere in ios.infoPlist (o nella configurazione del plugin interessato). Altrimenti l'app può crashare alla prima chiamata.

Che frase scrivere se la tua app non usa il dato?

Apple chiede una descrizione esatta, utile e precisa. Se la tua app usa davvero il dato, di' a cosa serve, in una frase: "L'app usa la fotocamera per scansionare il codice a barre del tuo biglietto."

Se la chiave c'è solo per colpa di una libreria, Apple dà due rimedi: scrivere la frase, o rimuovere il codice che accede al dato. Quando quel codice viene da una libreria, non puoi semplicemente rimuoverlo. Su Solys ho quindi scritto la verità: "Solys non accede alle tue foto. Questa autorizzazione non viene mai richiesta." È una scelta pragmatica: la build successiva ha superato la consegna, ma non posso garantirti che Apple accetterà sempre questa frase.

Trovare le chiavi mancanti prima dell'invio

Dalla root del tuo progetto, questo comando elenca i file delle librerie il cui codice iOS fa riferimento alle API più controllate:

grep -rlE "PHPhotoLibrary|AVCaptureDevice|CLLocationManager|CNContactStore|EKEventStore|ATTrackingManager" \
  node_modules/*/ios node_modules/@*/*/ios

Ogni nome corrisponde a un dato: PHPhotoLibrary per le foto, AVCaptureDevice per fotocamera e microfono, CLLocationManager per la posizione, CNContactStore per i contatti, EKEventStore per il calendario, ATTrackingManager per il tracciamento. Per ogni risultato, verifica che la chiave di descrizione corrispondente esista nella tua configurazione.

Questa rete becca i casi che ho incontrato io. Non sostituisce la lettura dell'e-mail di Apple, che resta l'unica lista sicura, come per le API non pubbliche di ITMS-90338. Da quel rifiuto, faccio questo controllo prima di ogni build: richiede pochi secondi, mentre un rifiuto ITMS-90683 costa una build e il tempo per rifarla.

Inviare la tua build senza brutte sorprese

ITMS-90683 si corregge in fretta quando sai leggerlo, proprio come ITMS-90725, che riguarda la versione di Xcode. I rifiuti che arrivano dopo, quelli di un reviewer, richiedono più lucidità: il procedimento è nella pagina app rifiutata da Apple, e i motivi più frequenti sono in perché Apple rifiuta un'app.

Per controllare tutto prima dell'invio, l'Apple Review Kit riunisce la mia checklist e delle skill di Claude Code che rileggono il tuo progetto. Se il tuo invio è bloccato e vuoi uno sguardo umano, prenota un'ora con me: riprendiamo il tuo progetto in videochiamata, sul tuo schermo. E se stai preparando la tua prima uscita, fai la tua diagnosi gratuita: rimette in ordine i passaggi e ti invia la mia checklist anti-rifiuto Apple.

Domande frequenti

ITMS-90683 è un rifiuto di App Review?

Non nel senso di un reviewer umano. È un controllo automatico fatto sulla build alla consegna, prima della revisione, come ITMS-90717 per l'icona. Nessuno ha aperto la tua app. La build viene scartata: devi correggere l'Info.plist e inviarne una nuova.

Perché Apple chiede una chiave per un dato che la mia app non usa?

Perché Apple analizza il codice presente nella build, non il comportamento dell'app. Se una libreria inclusa fa riferimento alla libreria foto o alla fotocamera, la chiave di descrizione è obbligatoria, anche se nessuna schermata chiede mai quell'accesso.

Si può correggere ITMS-90683 con un aggiornamento da remoto?

No. La chiave mancante si trova nell'Info.plist, che fa parte del binario. Un aggiornamento da remoto non modifica quel file: devi rifare una build e rinviarla ad Apple.

Dove aggiungere NSPhotoLibraryUsageDescription in un progetto Expo?

Nella configurazione della tua app, sotto ios.infoPlist, con una frase che descrive l'uso. Alcune librerie offrono anche un'impostazione dedicata nel loro plugin, che può aggiungere altre chiavi, come una modalità in background. In entrambi i casi, la chiave deve esistere nella configurazione di base, non solo nei file di traduzione.

Bisogna togliere le chiavi di descrizione inutilizzate?

Solo se nessuna libreria della build fa più riferimento all'API interessata. Altrimenti il prossimo invio verrà rifiutato con ITMS-90683. Prima di togliere una chiave, cerca il nome dell'API nel codice iOS delle tue dipendenze.