Nota, agosto 2026: questo post risale a una versione precedente e descrive la struttura dei livelli di allora. Con la v1.2.0 AlcoLog ha unito il livello Pro a Premium, quindi oggi esiste un solo livello a pagamento. Nell’unione non si è perso nulla, e chi aveva Pro è passato a Premium senza costi aggiuntivi.

Se stai per pubblicare una v1.0 di un’app iOS con abbonamenti, acquisti in-app, un’app companion per Watch, widget o un qualsiasi posizionamento vicino alla salute, il processo di App Review sarà più difficile di quanto lasci intendere la documentazione. Questo post racconta un ciclo di lancio (quattro rifiuti in cinque giorni, cinque revisori, un solo binario) e gli schemi che hanno reso il ciclo sopportabile. Lo condivido perché è una delle parti meno documentate del pubblicare un’app indie seria, e la versione documentata (le sessioni della WWDC, la pagina delle Linee guida per la revisione, i forum per sviluppatori) non corrisponde alla realtà di tutti i giorni.

Se sei a metà ciclo e cerchi soluzioni pratiche, salta direttamente a “Cosa sistemare prima di inviare” e “Schemi che vale la pena capire”. La cronologia personale è nella seconda metà, se vuoi il contesto.

# Cosa sistemare prima di inviare

Questi sono i punti emersi nei quattro rifiuti. Se li sistemi in anticipo, elimini la maggior parte delle occasioni di rifiuto per una v1.0 in una categoria sensibile con abbonamenti.

# La gerarchia dei prezzi nei paywall degli abbonamenti

Le Human Interface Guidelines di Apple sugli abbonamenti non lasciano dubbi su come presentare i prezzi. L’importo addebitato deve essere l’elemento di prezzo più in evidenza. L’istinto del marketing (far sembrare lo sconto la vittoria) qui è quello sbagliato. L’istinto della conformità (fare dell’importo addebitato il protagonista tipografico) è quello giusto.

In pratica significa questo: il prezzo standard deve essere l’elemento più grande e più marcato. Il prezzo introduttivo o scontato deve essere più piccolo, con un’etichetta esplicita del tipo “Primo periodo:”. Evita i badge con le percentuali in piccoli indicatori (usa “OFFERTA DI LANCIO”, non “25% DI SCONTO”). L’applicazione della regola 3.1.2© Pagamenti e abbonamenti su questo punto è coerente tra un revisore e l’altro.

# Un percorso esplicito per cancellare i dati

Anche quando il tuo “account” è solo un identificativo anonimo facoltativo, la regola 5.1.1(v) di Apple richiede un percorso di cancellazione etichettato, visibile e immediato. Disattivare un interruttore come cancellazione implicita sembra conforme dal lato dello sviluppatore, ma non soddisfa il modo in cui la regola viene applicata oggi.

Inserisci un pulsante esplicito “Elimina i miei dati” nella schermata della privacy o delle impostazioni fin dalla prima build. Aggiungi un avviso di conferma. Assicurati che il testo intorno descriva come avviene davvero la cancellazione, e non una tempistica provvisoria che pensi di rivedere più avanti.

# Controlla Info.plist alla ricerca di dichiarazioni rimaste lì

Modalità in background, background fetch, entitlement per la posizione, dichiarazioni HealthKit e voci simili di Info.plist possono restare inutilizzate per mesi mentre il codice evolve. Vengono segnalate quando non corrispondono a una funzione reale. L’applicazione della regola 2.5.4 Requisiti software su questo punto è meccanica e inequivocabile.

Nello specifico: ogni voce di UIBackgroundModes deve corrispondere a una funzione che la usa davvero. Se la tua app dichiara “location” come modalità in background ma non usi mai la posizione continua in background e hai allowsBackgroundLocationUpdates = false, elimina la dichiarazione. Il monitoraggio delle regioni non la richiede. Il controllo richiede dieci minuti e ti evita un ciclo di rifiuto.

Il campo della Privacy Policy in App Store Connect è noto a tutti. Il requisito dei Termini d’uso lo è meno. Se usi l’EULA standard di Apple, inserisci un link ai Termini d’uso nella descrizione dell’app. Se usi un EULA personalizzato, aggiungilo nell’apposito campo EULA personalizzato di App Store Connect.

La pagina dei termini deve elencare tutti i prodotti a pagamento con durata dell’abbonamento, prezzo e modalità di rinnovo. La maggior parte dei team ha questi elementi sparsi su pagine diverse o sepolti nella privacy policy. Riuniscili in un’unica pagina dei termini che il revisore possa leggere in due minuti.

# Video App Preview: usa registrazioni dello schermo senza ritocchi

Mockup 3D del telefono, cornici del dispositivo e composizioni di marketing stilizzate sono valutazioni lasciate alla discrezione del revisore secondo la regola 2.3.4 Metadati accurati. La pagina di indicazioni pubblica non vieta esplicitamente le cornici del dispositivo, ma il materiale di formazione interno su cui lavorano i revisori sembra farlo. Le semplici registrazioni dello schermo alla risoluzione nativa sono sicure senza alcun dubbio.

Tieni la grafica di marketing per il tuo sito, i social e Reddit. Nello spazio App Preview metti registrazioni dello schermo. La differenza di conversione tra “anteprima con mockup curato” e “anteprima con registrazione dello schermo grezza” è piccola. La riduzione del rischio è grande.

# Percorsi espliciti verso gli acquisti in-app nelle note per App Review

I revisori lavorano con un tempo a disposizione di 5-15 minuti per app. Non sempre troveranno ogni acquisto in-app collegato alla versione. Se i tuoi acquisti in-app si raggiungono da percorsi diversi nell’app (paywall separati, schede separate, navigazione più profonda), inserisci nelle note per App Review il percorso passo per passo, tocco dopo tocco, per ogni acquisto in-app.

Un formato che funziona:

Premium subscriptions and Lifetime IAP: Settings tab > Premium card > Get Premium button > Premium upgrade sheet Pro subscriptions and Lifetime IAP: Settings tab > Pro card > Get Pro button Consumable Tip Jar items: Settings tab > scroll past tier cards > Tip Jar card > Show Tip Options

Sembra eccessivo. Evita uno specifico ciclo di rifiuto (regola 2.1(b) Informazioni necessarie) che altrimenti ti costa un giorno.

# Un margine di calendario tra l’invio e la data di lancio annunciata

Per l’invio di una v1.0 con abbonamenti in una categoria sensibile, prevedi almeno sette giorni di calendario tra il primo invio e la data di lancio che hai annunciato all’esterno. Ogni ciclo di rifiuto dura circa 24 ore se rispondi subito. Quattro cicli di rifiuto sono uno scenario peggiore realistico per l’invio di una v1.0 in una categoria sensibile.

Se la data di lancio è già annunciata all’esterno (preordine configurato, eventi in-app programmati, campagna di marketing prenotata, giornalisti contattati), sette giorni di margine sono il minimo. Dieci giorni sono più comodi. Con meno di sette rischi di mancare la data per un solo rifiuto procedurale.

# Schemi che vale la pena capire

Alcune osservazioni dall’interno del ciclo che dalla documentazione non si capiscono.

# Ogni rifiuto trova cose diverse

I quattro rifiuti hanno segnalato punti che non si sovrapponevano. Ogni revisore aveva accesso a ogni schermata che il revisore precedente aveva approvato. Il primo ha segnalato un link all’EULA nei metadati. Il secondo ha segnalato tre punti diversi nello stesso binario (modalità in background, visualizzazione dei prezzi, pulsante di cancellazione). Il terzo ha segnalato un materiale di marketing. Il quarto ha fatto una domanda sulla navigazione.

Non è un bug. È una caratteristica di come è strutturato App Review. Le revisioni sembrano ragionare per problema, non per app. I revisori si fermano al primo problema importante che trovano nel tempo a loro disposizione. Non sono tenuti a fare verifiche complete, e il sistema non assegna uno stato di “già approvato” alle parti che un revisore precedente ha accettato. La struttura privilegia la capacità di smaltimento dell’istituzione rispetto all’esperienza dello sviluppatore.

La conseguenza: non puoi ottenere una verifica completa da una singola revisione. Puoi ottenere solo ciò che il revisore di turno fa emergere nel suo tempo, e devi accettare che il revisore successivo possa far emergere in modo indipendente qualsiasi altra cosa al passaggio successivo.

# Ogni rifiuto tende ad avere una portata minore del precedente

È una tendenza generica, non una garanzia. Il primo rifiuto è spesso sostanziale (un requisito mancante, un problema di architettura). Il secondo è ancora sostanziale ma ha più la forma di una checklist. Il terzo scivola verso i metadati periferici. Il quarto a volte è una domanda procedurale più che un vero rifiuto.

Il motivo non è che l’app “migliora” a ogni passaggio. Il motivo è che la superficie revisionabile nel binario e nei metadati si riduce a ogni passaggio, man mano che i punti già segnalati vengono sistemati e quelli già approvati escono dal perimetro. I revisori esauriscono in modo indipendente la checklist disponibile, quindi le revisioni successive hanno meno da trovare.

Questo schema rassicura mentre sei nel ciclo, ma non contarci. Un revisore alla fine del ciclo può ancora far emergere un punto sostanziale che i precedenti non avevano visto.

# Lo scrupolo dei revisori varia in modo enorme

Nelle quattro revisioni dello stesso binario, la differenza in ciò che ogni revisore ha trovato è stata notevole. Uno ha trovato tre punti. Un altro ha trovato un solo punto periferico. Un terzo ha fatto una domanda a cui si poteva rispondere toccando una scheda nella seconda tab dell’app.

Non hai alcuna influenza su quale revisore riceve il tuo invio in un dato passaggio. Metti in conto la variabilità. Non dare per scontato che il passaggio successivo sarà più scrupoloso o più indulgente del precedente. Sono campioni indipendenti presi da una distribuzione molto ampia.

# L’approvazione della Beta App Review non predice l’approvazione di App Review completa

Le due pipeline hanno team diversi e criteri diversi. Una build che passa la revisione Beta con le stesse funzioni che vengono segnalate nella revisione per la produzione non è una contraddizione. Sono due processi di revisione diversi.

Se usi TestFlight per verificare che l’app sia pronta per la revisione di produzione, lo stai usando per il segnale sbagliato. TestFlight intercetta problemi di validità della build e di conformità di base. App Review per la produzione copre l’intera superficie dei controlli. Non sono intercambiabili.

# Nelle categorie sensibili i fattori di controllo si sommano

Gli abbonamenti, soprattutto con prezzi introduttivi o prove gratuite, fanno scattare automaticamente i controlli della regola 3.1.2. Le categorie vicine alla salute (alcol, fitness, salute mentale, sonno) attirano l’attenzione del revisore sui timori legati a dichiarazioni mediche della regola 1.4.1. Le funzioni delicate per la privacy (posizione, HealthKit, identificativi anonimi) fanno scattare lo scrutinio della regola 5.1.1. Gli invii della prima versione v1.0 fanno scattare revisioni complete. Gli eventi in-app legati alle date di lancio fanno scattare controlli sui metadati.

Ogni fattore, preso da solo, è gestibile. Insieme si moltiplicano. Un lancio serio in una categoria sensibile, con abbonamenti, più piattaforme e un evento in-app, ha tutti i fattori attivi nello stesso momento. Un’utility gratuita di una sola schermata senza acquisti in-app passa in 2 minuti. La difficoltà della tua revisione è legata alla serietà e all’ampiezza del tuo lancio, non alla qualità della tua app.

# Documentazione e applicazione delle regole non coincidono sempre alla perfezione

Un rifiuto può citare indicazioni che non compaiono in modo esplicito nella pagina pubblica collegata. I revisori lavorano con materiale di formazione interno che si sovrappone alle Linee guida pubbliche per la revisione ma non è identico. Se ricevi un rifiuto che non corrisponde alla documentazione pubblica, puoi contestarlo con garbo. A volte viene ritirato, a volte no.

Quando contesti, fallo per iscritto nel Resolution Center, con un paragrafo strutturato che citi le indicazioni pubbliche e chieda quale clausola specifica viene applicata. Evita la frustrazione nel linguaggio. Il revisore legge la risposta con un tempo limitato; la risposta che viene letta con attenzione è quella che ne tiene conto.

# Come rispondere ai rifiuti in modo costruttivo

Qualche nota pratica sullo scambio nel Resolution Center.

# Rispondi in giornata, se puoi

Il modo più veloce per uscire dal ciclo è tenerlo in movimento. Il conteggio di ogni ciclo di rifiuto riparte quando rispondi. Risposte in giornata portano a una soluzione in settimana; risposte dopo più giorni allungano il ciclo in proporzione.

Serve che il tuo team sia organizzato per rilasciare correzioni in fretta. Per uno sviluppatore indie spesso significa liberare il calendario nei giorni successivi all’invio. La finestra di invio non può essere trattata come un lavoro in sottofondo.

# Raggruppa le correzioni in un unico nuovo invio

Se un rifiuto segnala tre punti, sistemali tutti e tre prima di inviare di nuovo. Non mandare una risposta del tipo “ne ho sistemati due su tre, sto lavorando al terzo”. Il revisore successivo farà emergere punti del tutto diversi; la risposta con una correzione parziale aggiunge solo un altro ciclo alla coda.

# Allega registrazioni dello schermo che mostrino le correzioni

Per ogni correzione non banale, allega una registrazione dello schermo di 30 secondi che la mostri in azione. Il flusso di cancellazione, la visualizzazione dei prezzi corretta, il nuovo percorso di navigazione. È più probabile che il revisore chiuda la questione al passaggio successivo se può vedere la correzione senza doverci arrivare da solo.

# Chiedi una revisione completa nella tua risposta

Una richiesta cortese perché eventuali dubbi residui vengano sollevati tutti insieme nel passaggio in corso, invece di essere distribuiti su altri cicli, è ragionevole. Non sempre funziona, ma a volte sì. La formulazione conta: “We have addressed every issue raised so far promptly and in good faith. We would appreciate a comprehensive review against all applicable guidelines in this pass to minimize further cycles.” (Abbiamo affrontato ogni problema sollevato finora con tempestività e in buona fede. Apprezzeremmo una revisione completa rispetto a tutte le linee guida applicabili in questo passaggio, per ridurre al minimo ulteriori cicli.)

Così il revisore si trova in una posizione in cui la sua prossima risposta o approva l’app o fa emergere tutti i dubbi rimasti. Entrambi gli esiti sono meglio di un altro rifiuto su un singolo punto.

# Tratta ogni passaggio come indipendente

La tentazione è pensare che il revisore successivo abbia letto le note del precedente. Probabilmente non l’ha fatto. Ogni risposta nel Resolution Center deve reggersi da sola, riassumendo lo stato dell’invio per qualcuno che non ha visto la conversazione precedente.

Questo significa che un po’ di ripetizione tra un ciclo e l’altro è necessaria. Le note dettagliate per App Review che hanno funzionato con il primo revisore vanno allegate di nuovo o ripetute per il terzo. Non dare per scontata una memoria istituzionale.

# La cronologia personale

Per contesto, ecco com’erano davvero quei cinque giorni.

Ho inviato la build 22 il sabato pomeriggio. L’invio comprendeva 4 abbonamenti a rinnovo automatico, 2 acquisti in-app a vita non consumabili, 5 elementi consumabili del Tip Jar, la descrizione dell’app, gli screenshot, i video App Preview, un evento in-app legato alla settimana di lancio e il preordine configurato per la data di lancio in 175 paesi.

Avevo passato le sei settimane precedenti a eliminare in modo sistematico ogni problema che riuscivo a prevedere. Le note per App Review erano scritte con spiegazioni pensate per il revisore sulle parti dell’app che più probabilmente avrebbero attirato l’attenzione. Le informazioni DSA sul commerciante erano state approvate una settimana prima. Le etichette sulla privacy dell’app erano online. La Beta App Review aveva approvato diverse build. Mi sentivo pronto.

Giorno 2, 5:15: primo rifiuto. Regola 3.1.2©. Mancava un link funzionante ai Termini d’uso nei metadati dell’App Store. Correzione pubblicata in giornata (aggiunto il link ai Termini nel foglio di upgrade in-app, ampliata la pagina dei termini per elencare tutti i prodotti a pagamento, aggiornata la descrizione dell’app). Ciclo di un giorno.

Giorno 4, 16:03: secondo rifiuto. Tre punti in un solo messaggio. Regola 2.5.4 (una voce “location” di UIBackgroundModes rimasta lì e che non doveva esserci). Regola 3.1.2© (prezzo introduttivo mostrato con più evidenza dell’importo addebitato). Regola 5.1.1(v) (la disattivazione dell’identificativo anonimo richiedeva un pulsante di cancellazione esplicito ed etichettato). Correzione pubblicata in giornata (eliminata la voce da Info.plist, invertita la gerarchia dei prezzi, aggiunto un pulsante esplicito “Elimina dati anonimi” con avviso di conferma). Ciclo di un giorno.

Giorno 5, 17:05: terzo rifiuto. Regola 2.3.4 Metadati accurati. I video App Preview mostravano le schermate dell’app dentro mockup 3D del telefono. La nota del revisore citava contenuti che non “mostrano a sufficienza l’app in uso” e indicava in modo specifico le cornici del dispositivo.

Il problema: la pagina di indicazioni pubblica su developer.apple.com/app-store/app-previews/ non vieta esplicitamente le cornici del dispositivo. La regola documentata più vicina è “Resta all’interno dell’app”, con esempi su riprese da sopra la spalla e interazioni fisiche con i dispositivi. Nessuno dei due casi si applicava.

Con il lancio a quattro giorni di distanza e quattro giorni di ritardo complessivo già accumulati, ho fatto lo scambio. Ho tolto i video App Preview per sbloccare il nuovo invio. Ho chiesto con garbo un riesame nel caso mi fosse sfuggita una clausola specifica delle linee guida. Ho mandato un paragrafo cortese e strutturato chiedendo che eventuali dubbi residui venissero sollevati tutti insieme in quel passaggio. La rimozione delle App Preview è rimasta. La richiesta di riesame non ha ricevuto una risposta diretta.

Giorno 6, 19:23: quarto messaggio. Regola 2.1(b) Informazioni necessarie. Tecnicamente non un rifiuto. Una pausa nella revisione per fare una domanda. Il revisore non riusciva a trovare due degli acquisti in-app collegati alla versione e chiedeva dove fossero.

Lo screenshot allegato mostrava correttamente il primo paywall. Il secondo paywall era nella stessa schermata Impostazioni, raggiungibile toccando una scheda proprio sotto la prima scheda a cui il revisore era arrivato senza problemi. Ho risposto con la navigazione esplicita passo per passo per tutti gli 11 acquisti in-app, inviata entro un’ora.

Giorno 7, 20:30: approvazione. Build approvata. Preordine attivato. La settimana di lancio è fissata per l’11 maggio.

Quei cinque giorni sono stati intensi. Nessuno, col senno di poi, era una questione di vita o di morte, anche se a metà ciclo non sembrava. Il ritardo accumulato ha quasi fatto saltare la data di lancio, ma non è successo. Il prodotto lanciato è esattamente quello costruito prima dell’invio. Niente è stato tagliato, modificato o rimandato per superare la revisione.

# Anche ciò che il ciclo non segnala dice qualcosa

Nelle quattro revisioni, le parti su cui mi ero preoccupato di più non sono mai state segnalate.

La funzione del punteggio sulle abitudini (un punteggio da 0 a 100 con fattori positivi e negativi su sei pilastri ponderati). La parte sul monitoraggio dei farmaci (solo registrazione, senza alcun consiglio in uscita). Il modello di privacy (nessun account, dati sul dispositivo, condivisione anonima facoltativa con cancellazione esplicita). Le scritture su HealthKit. Nessuna di queste parti, cioè quelle dell’app che più probabilmente avrebbero sollevato dubbi su dichiarazioni sanitarie o sulla privacy, è stata segnalata in nessuna delle quattro revisioni. Quattro revisori indipendenti le hanno guardate tutti, e tutti hanno scelto di non segnalarle.

La conseguenza per chi sviluppa in categorie sensibili: il lavoro di trasparenza preventiva conta. Le note per App Review che spiegano la metodologia, le avvertenze nell’app, le scelte attente dei nomi, il tono prudente nella descrizione dell’app. Niente di tutto questo è affascinante. Tutto ha contribuito a far sì che quattro revisori di fila scegliessero di non segnalare le parti più discutibili. La classificazione 18+, la schermata di avvertenze obbligatoria al primo avvio, il testo esplicito “non forniamo consigli medici” nelle aree pertinenti. Ha funzionato tutto.

Sono state segnalate invece le parti procedurali e meccaniche. La gerarchia dei prezzi. Le dichiarazioni delle modalità in background. La presenza di un link nei metadati. La composizione dei materiali di marketing. La reperibilità degli acquisti in-app. Le parti sostanziali dell’app hanno superato ogni passaggio.

# Note finali per gli sviluppatori indie

Alcune osservazioni che non trovavano un posto preciso sopra.

Le app economiche che vedi sull’App Store non ricevono un trattamento più indulgente. Sono state approvate anni fa, quando gli standard erano più bassi, oppure non fanno scattare i fattori di controllo che fa scattare il tuo lancio serio. Il sistema premia le app a basso sforzo e basso rischio con un basso livello di controllo. Il tuo impegno e la tua cura sono parte del motivo per cui la tua revisione è più dura. Non è un giudizio sulla qualità della tua app.

Il sistema non ha il personale per darti l’esperienza che vorresti. App Review è un bacino di collaboratori esterni. I revisori gestiscono decine di app al giorno, con pochi minuti per app. Sono formati sulle Linee guida per la revisione come checklist, non sull’esperienza d’uso specifica di ogni singola app. La mancanza di empatia è strutturale, non personale.

Documentare le esperienze degli indie prima o poi smuove le cose. Apple ha migliorato App Review in modo significativo nell’ultimo decennio. Parte di quel miglioramento nasce dagli sviluppatori indie che hanno documentato con costanza le loro esperienze e dalla pressione collettiva che ne è derivata. Il tuo singolo rifiuto non farà riaddestrare nessun revisore in particolare. L’insieme strutturato delle esperienze indie, alla lunga, smuove l’istituzione.

Probabilmente pubblicherai il prodotto che hai costruito. Ogni funzione che temevo potesse essere tagliata è uscita intatta. Il ciclo dei quattro rifiuti sembrava una questione di vita o di morte mentre accadeva. L’esito reale è arrivato all’approvazione, a patto di continuare a rispondere con chiarezza e di tenere in tasca il margine sulla data di lancio.

Se in questo momento sei a metà ciclo e passi le notti nel Resolution Center: il lancio arriva. Continua a rispondere. Il sistema non ce l’ha con te. Il prodotto è tuo.

Questo post racconta il lancio di AlcoLog, un’app iOS per monitorare i drink. AlcoLog arriva sull’App Store l’11 maggio 2026, dopo il ciclo descritto qui sopra. L’app è gratuita con livelli Premium opzionali ed è già disponibile in preordine in 175 paesi.

Se sei uno sviluppatore iOS e vuoi confrontarti sulle esperienze con App Review, la community indie-iOS su r/iOSProgramming e Indie Hackers sono buoni punti di partenza. Più ognuno di noi documenta con precisione ciò che ha incontrato, più l’insieme diventa utile per chi viene dopo.