Guideline 5.1.1: capire e risolvere un rifiuto App Store

La guideline 5.1.1 è la regola di Apple sulla raccolta e la conservazione dei dati. Nei miei tre rifiuti di questa famiglia, la causa era sempre una di queste due incongruenze: quello che l'app faceva con i dati non corrispondeva a quello che era dichiarato, oppure la richiesta di autorizzazione spingeva l'utente a dire sì.

Questo articolo tratta solo questa regola: i suoi commi, cosa controllo prima dell'invio e cosa correggere, con tre rifiuti che ho preso sulle mie app. Per il quadro generale di tutti i motivi, leggi piuttosto perché Apple rifiuta un'app.

Che cos'è la guideline 5.1.1?

La guideline 5.1.1, "Data Collection and Storage", stabilisce cosa deve rispettare un'app appena tocca dati personali: una privacy policy completa, un consenso prima della raccolta, richieste di autorizzazione oneste e un account che si può eliminare. Vale per tutte le app, anche quelle che non raccolgono quasi nulla.

Il testo ufficiale si trova nelle App Review Guidelines, sezione 5 "Legal", parte 5.1 "Privacy". Il messaggio di Apple cita spesso un comma preciso, tra parentesi: 5.1.1(i), 5.1.1(iv), 5.1.1(v). È quel comma a dirti dove cercare.

I cinque commi della 5.1.1 da conoscere per primi

Comma	Cosa chiede Apple	Il rifiuto tipico
5.1.1(i) Privacy Policies	Policy completa e collegata	Assente o incompleta
5.1.1(ii) Permission	Consenso prima della raccolta	Testo di autorizzazione vago
5.1.1(iii) Data Minimization	Solo i dati necessari	Accesso completo alle foto
5.1.1(iv) Access	Non spingere ad accettare	Schermata che spinge ad accettare
5.1.1(v) Account Sign-In	Nessun account imposto	Login obbligatorio

Tre precisazioni. La privacy policy va collegata in App Store Connect e nell'app. Dice quali dati vengono raccolti, come e per cosa, conferma che le terze parti che li ricevono offrono la stessa protezione e spiega come revocare il consenso o far eliminare i propri dati. Una funzione a pagamento non può dipendere da un accesso ai dati che l'utente è libero di rifiutare. E un account creato nell'app deve poter essere eliminato dall'app.

La regola ha altri commi, da (vi) a (x), su casi più particolari come i settori regolamentati o la raccolta in massa di dati personali.

Le tre cose che confronto prima dell'invio

Non ho il manuale del reviewer. Ecco cosa confronto io prima di ogni invio, perché i miei rifiuti sono nati da un'incongruenza tra questi elementi:

• cosa dice la policy online, all'URL dichiarato in App Store Connect;
• cosa fa davvero l'app, schermata per schermata, comprese tutte le richieste di autorizzazione;
• cosa è dichiarato nella scheda, nella parte sulla privacy dell'app (App Privacy Details).

Testo anche ogni schermata di autorizzazione chiudendo l'app e poi riaprendola. È la causa che ho individuato per il mio secondo rifiuto su Nolera.

Tre rifiuti 5.1.1 che ho preso, e la loro vera causa

Clic: la policy online era la vecchia versione

Clic trasforma un prodotto in slide pronte da pubblicare, con l'IA. Il 16 settembre 2026 Apple rifiuta l'app citando la 5.1.1(i) e la 5.1.2(i). La schermata di consenso all'IA c'era, nell'app. Il problema era fuori dall'app: la privacy policy pubblicata sul sito era la vecchia versione. Quella nuova esisteva, ma non era stata messa online.

La correzione: policy completa pubblicata, riassunto in inglese aggiunto per il reviewer, note per la revisione aggiornate. Non ho fatto una nuova build: ho rimandato la stessa submission.

La lezione: Apple legge quello che è online, non quello che c'è nel tuo repository. Il giorno dell'invio, apri l'URL della tua policy e cerca il nome di ogni servizio terzo usato dalla tua app.

Nolera: un pulsante "Consenti" prima della richiesta di sistema

Nolera è la mia app per l'armadio. Il 17 settembre 2026, dopo una revisione su iPad Air, Apple cita la 5.1.1(iv). Prima della richiesta di accesso alla fotocamera, l'app mostrava una schermata di spiegazione con un pulsante "Allow the camera".

Le regole di design di Apple sono precise su questo punto. Una schermata personalizzata mostrata prima di una richiesta di sistema deve avere un solo pulsante, che apre quella richiesta. Apple consiglia un termine come "Continua" o "Avanti", e non "Consenti": un pulsante che somiglia a quello di sistema spinge poi a toccare il vero "Consenti" senza averlo voluto.

Questa regola riguarda le schermate mostrate prima di una richiesta di sistema: fotocamera, microfono, posizione, contatti, calendario, tracciamento. Prevede un'eccezione, per un consenso richiesto dalla legge.

La correzione: il pulsante si chiama "Continua", nelle 8 lingue dell'app.

La lezione: una schermata che prepara un'autorizzazione spiega. Non decide al posto dell'utente.

Nolera, secondo rifiuto: la schermata "fotocamera negata" arrivava prima della richiesta

Rimandata, Nolera viene rifiutata una seconda volta il 22 settembre 2026, sempre per la 5.1.1(iv), stavolta su iPad Pro 11 pollici. Apple segnala due punti: un rimando alle Impostazioni prima della richiesta di accesso, e una schermata da cui si poteva uscire senza vedere quella richiesta.

La causa che ho individuato: un caso che non avevo testato. La schermata di scatto mostrava il suo pannello "fotocamera negata", con il link alle Impostazioni e una soluzione alternativa, appena l'accesso non era concesso. Anche quando non era mai stato richiesto. Nel percorso normale, la schermata di spiegazione arrivava prima e andava tutto bene. Ma se chiudevi l'app a metà e poi la riaprivi, ripartivi direttamente dallo scatto, senza aver visto la richiesta di sistema.

La correzione: finché iOS può ancora fare la domanda, è la schermata stessa a lanciare la richiesta di sistema. Il pannello "fotocamera negata" compare solo dopo un vero rifiuto. Questa correzione ha richiesto una nuova build, perché il reviewer testa il codice incluso nell'app.

La lezione: "mai richiesto" e "negato" sono due stati diversi. Testa ogni schermata di autorizzazione tornandoci dopo aver chiuso l'app, non solo seguendo l'ordine del percorso.

5.1.1 e IA: cosa aggiunge la 5.1.2(i)

Su Clic, Apple ha citato la 5.1.2(i) oltre alla 5.1.1. Questa regola chiede di indicare chiaramente dove i dati personali vengono condivisi con terze parti, e nomina espressamente l'IA di terze parti ("third-party AI"). Chiede anche un'autorizzazione esplicita prima della condivisione.

Quello che faccio da quel rifiuto: tre cose coerenti tra loro.

• Una schermata di consenso nell'app, prima del primo invio, che dice a quale servizio vanno i dati e quali.
• La stessa informazione nella privacy policy online.
• La stessa informazione nelle dichiarazioni sulla privacy della scheda.

Il dettaglio di cosa deve contenere la policy è in privacy policy di un'app.

Cosa rispondere ad Apple dopo un rifiuto 5.1.1

La conversazione si svolge nella sezione App Review della tua app, in App Store Connect. La procedura ufficiale per rispondere ad App Review è la stessa delle altre regole. Scrivi in inglese, in modo sobrio: cosa non andava, cosa è cambiato, come verificarlo. Ecco il modello che uso (sostituisci il numero di build e la correzione con i tuoi):

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,

I casi sono due:

• La causa è online (policy, pagina di supporto, dichiarazioni della scheda): correggi, rispondi, e la stessa submission può ripartire senza nuova build.
• La causa è nell'app (schermata, pulsante, ordine delle richieste): serve una nuova build. Un aggiornamento da remoto non basta, come spiego nella guida sulla guideline 2.1.

La checklist 5.1.1 prima dell'invio

• L'URL della tua privacy policy si apre, e la pagina online è l'ultima versione.
• La policy nomina ogni servizio terzo che riceve dati, IA compresa. È una mia regola, più severa del testo di Apple.
• Le dichiarazioni sulla privacy della scheda dicono la stessa cosa della policy e del privacy manifest della build.
• Ogni testo di autorizzazione spiega l'uso con una frase precisa.
• Nessuna autorizzazione viene chiesta all'avvio se l'app può funzionare senza. Stessa logica per le modalità in background: nessuna modalità dichiarata senza una funzione che la usi.
• Una schermata personalizzata prima di una richiesta ha un solo pulsante, "Continua", che apre la richiesta di sistema.
• Chi rifiuta un'autorizzazione può andare avanti in un altro modo, o capisce cosa perde.
• La schermata "accesso negato" compare solo dopo un vero rifiuto. L'hai testata chiudendo e riaprendo l'app.
• L'app si usa senza account quando l'account non è indispensabile.
• Un account creato nell'app può essere eliminato dall'app: la ricetta è in eliminazione dell'account iOS.
• Tutto è testato anche su iPad: i miei due rifiuti 5.1.1 su Nolera sono arrivati su iPad.

Risolvi il tuo rifiuto con qualcuno che l'ha già preso

Se la tua app è appena stata rifiutata per la 5.1.1, l'Apple Review Kit ti aiuta a ritrovare la regola citata, cosa chiede, e un esempio di correzione e di risposta. Se vuoi che guardiamo insieme il tuo caso subito, prenota un'ora con me, in videochiamata. Il percorso completo è anche nella pagina app rifiutata da Apple.

Se stai preparando la tua prima pubblicazione, fai la diagnosi gratuita: rimette in ordine i tuoi passaggi e ti manda la mia checklist anti-rifiuto Apple, privacy compresa. Per creare la tua app mobile pensata per la review fin dall'inizio, il percorso in quattro tappe dell'iOS Kit va dall'idea fino all'invio ad Apple.

Nessuno può garantire che Apple accetterà la tua app. Quello che posso fare è aiutarti a evitare i rifiuti 5.1.1 che ho già pagato con un ciclo di revisione.

Domande frequenti

Cosa significa "Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage"?

È il titolo completo della regola nel messaggio di Apple. Segnala un problema di dati personali: privacy policy incompleta, richiesta di autorizzazione giudicata insistente o account impossibile da eliminare. Il comma tra parentesi, per esempio 5.1.1(iv), indica quale.

Serve una nuova build dopo un rifiuto 5.1.1?

Non sempre. Se la causa è online, come una privacy policy non aggiornata, correggi la pagina, rispondi ad Apple e la submission riparte senza nuova build. Se la causa è una schermata o un pulsante dell'app, serve una nuova build.

Si può mostrare una schermata di spiegazione prima di una richiesta di autorizzazione?

Sì, Apple lo permette quando è davvero utile. La schermata ha allora un solo pulsante, che apre la richiesta di sistema, con un termine come "Continua" o "Avanti". Niente pulsante "Consenti", niente pulsante per chiudere o saltare, salvo consenso richiesto dalla legge.

La mia app usa un'IA esterna: cosa devo dichiarare?

La guideline 5.1.2(i) chiede di indicare dove i dati vengono condivisi con terze parti, IA compresa, e di ottenere prima un'autorizzazione esplicita. Io la applico in tre punti: una schermata di consenso nell'app, la privacy policy online e le dichiarazioni sulla privacy della scheda. Su Clic, Apple ha citato questa regola insieme alla 5.1.1.

L'account è obbligatorio per rispettare la 5.1.1?

No, è il contrario. Se la tua app non ha una funzione che dipende davvero da un account, Apple chiede di lasciarla utilizzabile senza login. E se permette di creare un account, deve anche permettere di eliminarlo dall'app.