App Review in 48 ore: cosa è vero, cosa è esagerato, cosa è falso

In questo periodo gli animi si scaldano tra gli sviluppatori iOS, su X come nelle community WhatsApp, tra cui una che animo io. Si parla di revisioni interminabili, di account revocati e ci si scambia ricette per «ottenere l'approvazione in meno di 48 ore»: note dettagliate per la revisione, video dimostrativo, chiamata con Apple per passare in una coda separata, MVP minimalista per evitare «la pila dei 14 giorni»…

In questi consigli ci sono intuizioni molto valide. Ci sono anche affermazioni impossibili da verificare e una o due idee che, applicate male, possono costare molto più di un rifiuto.

I tempi e le revoche meritano ciascuno un capitolo, perché aiutano a capire tutto il resto.

Per dare un po' di contesto (anche se, arrivati su questo sito, probabilmente «sapete» chi sono): pubblico sull'App Store dal 2008, sia le mie app sia quelle dei clienti. Ho ripreso ogni consiglio e l'ho confrontato con quanto Apple scrive nero su bianco nella sua pagina App Review, nelle App Review Guidelines e nella guida di App Review. Ecco cosa regge e cosa no.

---

Prima di tutto, rimettiamo le 48 ore nella giusta prospettiva

Le ricette che circolano lasciano intendere che 48 ore siano un'impresa. Sulla carta, è lo standard dichiarato da Apple: il team App Review lavora 24 ore su 24 in tutto il mondo (Cupertino, Cork e altrove) e punta a esaminare almeno il 50% degli invii in meno di 24 ore e il 90% in meno di 48 ore.

Nella pratica, la situazione è più sfumata. Questi numeri sono medie calcolate su tutti gli invii, e una gran parte riguarda aggiornamenti di app già pubblicate, che spesso passano in poche ore. Nelle ultime settimane ho avuto aggiornamenti approvati in 7 ore, altri in 12. Una nuova app, invece, può aspettare molto più a lungo: mentre scrivo, alcune delle mie nuove app sono in revisione da più di dieci giorni. È tanto, ma fa parte del gioco.

Apple ha anche condiviso dati recenti. Interpellata da MobileGamer.biz il 20 ottobre, l'azienda afferma di aver gestito in media 378.000 invii a settimana nelle ultime dodici settimane, con un tempo medio di 1,5 giorni considerando tutte le app e 14 ore per gli aggiornamenti minori. Precisa inoltre che alcune nuove app richiedono più tempo quando necessitano di un esame approfondito. Per un volume del genere, la media è notevole; gli scarti si concentrano sui primi invii.

Un tempo la community aveva uno strumento per seguire questi tempi. I veterani ricorderanno appreviewtimes.com, lanciato all'inizio degli anni 2010 dall'amico Dave Verwer, autore di iOS Dev Weekly. Il principio era semplice: gli sviluppatori twittavano la durata delle loro revisioni con l'hashtag #iosreviewtime (sì, era ancora Twitter) e il sito calcolava una media. Quando bisognava contare in settimane, era uno strumento indispensabile per gestire le aspettative dei clienti.

Nel 2019 Dave ha chiuso il sito per la migliore delle ragioni: le revisioni erano diventate così rapide, circa un giorno, che misurarle non aveva più molto senso. Non l'ha mai riaperto. Dave è poi entrato in Apple quest'estate con lo Swift Package Index, e Alex Ozun ha preso in mano iOS Dev Weekly.

Risultato: nel 2026 non esiste più un barometro di riferimento della community, solo testimonianze sparse sui forum e sui social. Segno dei tempi: lo strumento che aveva chiuso perché la revisione era diventata rapida oggi ritroverebbe il suo posto.

Una breve storia del tempo

Non è la prima volta che i tempi cambiano. Agli inizi dell'App Store, una revisione poteva richiedere diverse settimane. La mia primissima app ha aspettato 26 giorni prima di essere approvata, per uscire il 14 luglio 2008, quattro giorni dopo l'apertura dell'App Store. Siamo poi scesi a una settimana, che è stata a lungo la norma. Poi Apple ha accelerato molto, finché da uno a tre giorni è diventata l'abitudine. Dall'inizio del 2026 i tempi risalgono per le nuove app, e il motivo merita un capitolo a sé (subito qui sotto).

Puntare a 48 ore non significa quindi cercare un trattamento di favore: significa rimanere nel flusso normale, sapendo che per un lancio il flusso normale oggi si misura in giorni. Pianificate di conseguenza.

La vera domanda diventa: cosa fa uscire un invio da questo flusso? Apple dà un indizio prezioso nella sua pagina App Review: oltre il 40% dei problemi irrisolti riguarda la guideline 2.1, App Completeness: crash, contenuti provvisori, informazioni mancanti. Non è la soggettività di chi esamina l'app a rallentare la maggior parte delle app. È un invio incompleto.

---

Gli agenti di coding: più app, più attesa

Perché i tempi risalgono? La spiegazione più probabile si riassume in una parola: gli agenti.

Claude Code, Codex, Cursor, gli agenti integrati in Xcode: scrivere un'app iOS non è mai stato così accessibile. Secondo Sensor Tower, citata da The Information, l'App Store ha ricevuto 235.800 nuove app nel primo trimestre 2026, l'84% in più rispetto a un anno prima: la crescita più forte misurata negli ultimi quattro anni. Per l'intero primo semestre, Sensor Tower stima circa 560.000 nuove app, il doppio dell'anno precedente, mentre i download sono aumentati solo del 2%. La stessa Apple ha scritto nel suo bilancio antifrode di maggio che gli strumenti di sviluppo basati sull'IA fanno aumentare gli invii.

Apple mantiene il suo obiettivo del 90% in 48 ore e ha adattato la propria organizzazione: più automazione e priorità agli aggiornamenti. Dal lato degli sviluppatori, ciò che si osserva è coerente con questa scelta: gli aggiornamenti delle app consolidate continuano a passare rapidamente, le nuove app aspettano di più.

Il lato positivo: what a great time to be a developer

È innanzitutto un'ottima notizia, per molti motivi. La barriera del codice non è mai stata così bassa. Designer, esperti di settore e sviluppatori indipendenti che non avrebbero mai imparato Swift oggi possono pubblicare un'app utile. Sviluppatori esperti consegnano in una settimana ciò che prima richiedeva un trimestre. Io stesso lavoro ogni giorno con gli agenti: scrivono SwiftUI, test e perfino una prima bozza delle note per la revisione.

Attenzione però: dire che la barriera è scomparsa sarebbe una bugia. Un agente scrive codice; non sa scegliere al posto vostro quale framework usare, quale pattern reggerà quando l'app crescerà, come si comportano la concorrenza di Swift, StoreKit o i permessi, né perché una revisione si blocca. Gli agenti amplificano ciò che sapete già. Più conoscete la piattaforma, più vi rendono veloci; meno la conoscete, più rapidamente accumulate problemi che non sapete interpretare.

Gli ingredienti sono gli stessi per tutti: Swift, SwiftUI, Xcode, le Human Interface Guidelines e ora un agente. A fare una grande app è il modo in cui li si combina, con intenzione e cura: una ragione d'essere esprimibile in una frase, un'unica fonte di verità per i dati, un'accessibilità verificata onestamente, test su dispositivi reali. Un agente può scrivere la schermata; non vi dirà se l'app merita di esistere. O peggio, si trasformerà in una mamma orgogliosa: «È un’idea fantastica, tesoro!», per poi aiutarvi a bruciare un miliardo di token costruendo un’app il cui pubblico di riferimento è composto interamente da voi, vostra madre, il vostro gatto, il vostro canarino e forse, ma proprio forse, il vostro partner. Ho descritto nel dettaglio tutto questo percorso, dagli otto principi di design di Apple fino alla pubblicazione, in La ricetta di una grande app iOS.

Se usati bene, aiutano anche con la conformità. Un agente può rileggere le vostre purpose strings, verificare che sia prevista l'eliminazione dell'account, confrontare il vostro percorso con le linee guida, elencare le funzionalità non evidenti da documentare. Tutto ciò che descrive questo articolo, un agente può verificarlo prima di voi.

A proposito, per semplificarvi il lavoro vi regalo una skill che vi aiuterà a scovare gli errori prima dell'invio: app-review-skill. Non è una garanzia di approvazione, ma almeno è una salvaguardia. 😉

Insomma: what a great time to be a developer.

Il miraggio del milionario in tre prompt

L'altra faccia della medaglia è il discorso che accompagna questa ondata. Ovunque si vede la stessa promessa: tre prompt, un abbonamento (o pubblicità dappertutto) ed eccovi milionari in tre giorni.

Spoiler: è falso. E i numeri non lasciano dubbi. Il rapporto State of Subscription Apps 2026 di RevenueCat, che riguarda oltre 115.000 app e 16 miliardi di dollari di ricavi, mostra che:

• un anno dopo il lancio, l'app mediana genera circa 72 $ al mese;
• solo il 17,3% delle app raggiunge 1.000 $ di ricavi mensili nei primi due anni e il 4,6% supera i 10.000 $;
• persino il 10% con le migliori prestazioni supera di poco i 2.574 $ al mese dopo un anno: lontano, molto lontano dal milione;
• le app lanciate nel 2025 o dopo rappresentano solo il 3% dei ricavi da abbonamento, mentre quelle lanciate prima del 2020 ne raccolgono il 69%.

E parliamo di app abbastanza serie da aver integrato un sistema di abbonamento.

Tutti pensano di avere la next big idea. Mi dispiace riportarvi con i piedi per terra. Se la vostra idea non esiste ancora sull'App Store, ci sono solo due possibilità: o è già stata tentata e non ha funzionato, oppure un centinaio di altre persone la sta costruendo proprio in questo momento. E con gli agenti, il centinaio diventa presto un migliaio.

Non è pessimismo, è un fenomeno ben documentato: le scoperte simultanee. Alexander Graham Bell ed Elisha Gray hanno depositato la domanda di brevetto per il telefono lo stesso giorno, nel 1876. Darwin e Wallace sono arrivati ciascuno per conto proprio alla selezione naturale, tanto da presentare insieme i loro lavori nel 1858. Newton e Leibniz hanno inventato il calcolo infinitesimale in parallelo. Niente di magico: in una data epoca, tutti condividono gli stessi strumenti, gli stessi problemi e lo stesso accesso alle informazioni. Due menti davanti allo stesso problema, con gli stessi strumenti, arrivano naturalmente alla stessa soluzione. Come dice la frase spesso attribuita a Victor Hugo, niente è più potente di un'idea il cui tempo è arrivato.

Il consiglio che ne deriva: non tenete segreta la vostra idea per paura che ve la rubino. Altri ci stanno già lavorando. Le persone con cui ne parlerete potrebbero perfino indicarvi app concorrenti che vi erano sfuggite. La differenza non la farà l'idea, ma l'esecuzione, la distribuzione, il tempo e il vostro tocco personale.

Conosco sviluppatori le cui app rendono da 80.000 a oltre un milione di dollari al mese. Esistono, sono brillanti e spesso hanno alle spalle anni di iterazioni. Chiaramente non sono la maggioranza.

Non è una ragione per non provarci. È una ragione per farlo per i motivi giusti: risolvere un problema reale, imparare, costruire qualcosa che duri nel tempo. E per curare ciò che invece non si automatizza: la qualità.

Il lato meno positivo

Arrivano in revisione app raffazzonate e la coda è condivisa. Generare un'app in un fine settimana non significa che sia pronta: molti invii arrivano senza essere stati testati su un dispositivo, con contenuti provvisori, senza informativa sulla privacy né note per la revisione. Altre app non interessano a nessuno tranne che al loro sviluppatore. Eppure Apple lo dice già nell'introduzione delle sue linee guida: un'app che si vuole mostrare soltanto a familiari e amici non ha posto sull'App Store; Xcode e la distribuzione Ad Hoc servono a questo. Ciascuno di questi invii occupa un membro del team di revisione che non si sta occupando del vostro. Dando priorità agli aggiornamenti delle app esistenti, Apple protegge gli utenti attuali e gli sviluppatori affermati; il rovescio della medaglia è un'attesa più lunga per le nuove app.

Lo spam è il primo bersaglio. La guideline 4.3 vieta di inviare più varianti della stessa app e app in categorie sature senza una differenza reale. Con un agente, produrre cinque cloni richiede un pomeriggio; è esattamente ciò che Apple filtra. Apple afferma di aver rafforzato l'automazione e il rilevamento degli abusi e di aver aggiunto salvaguardie contro gli invii ripetuti con gli stessi problemi irrisolti. Le sue linee guida lo dicevano già: un rifiuto ripetuto per lo stesso motivo allunga la revisione.

Le app che generano codice sono nel mirino. Quest'anno Apple ha bloccato aggiornamenti o rimosso diverse app di vibe coding, tra cui Replit, Vibecode e Anything. Il motivo non è il vibe coding in sé, ma la guideline 2.5.2: un'app non può scaricare o eseguire codice che ne cambi le funzionalità dopo la revisione.

Più app non significa più utenti. Con download quasi stabili, ogni nuova app compete per la stessa attenzione. La barriera tecnica si è abbassata; quella della qualità, invece, si è alzata.

Cosa cambia per voi

• Restate responsabili. Le linee guida lo ricordano: tutto ciò che si trova nella vostra app, SDK di terze parti compresi, è sotto la vostra responsabilità. «L'ha scritto l'agente» non è un argomento accettabile.
• La qualità dell'invio diventa un vantaggio. In una coda congestionata, un'app completa con note chiare si distingue ancora più di prima.
• Un'app, non cinque varianti. Usate gli acquisti in-app o le impostazioni per le varianti, invece di moltiplicare i bundle ID.
• Non inviate mai di nuovo senza correggere. Un inutile scambio vi costa giorni e può far rientrare il vostro comportamento tra quelli che Apple controlla.
• Prevedete un margine. Per una nuova app, calcolate una settimana, più un eventuale scambio. Se passa in 48 ore, tanto meglio.

---

I consigli che reggono

La qualità conta, ed è scritta nelle regole

«Un'app curata sarà trattata meglio»: è vero, ma non per una questione di umore di chi la esamina. La sezione 4 delle linee guida lo dice chiaramente: Apple si aspetta interfacce semplici, raffinate e facili da usare. La guideline 4.2 (Minimum Functionality) respinge le app che sono soltanto un sito web riconfezionato, una raccolta di link o un contenuto senza valore duraturo.

«Sviluppate nativamente con SwiftUI»: un buon consiglio, non una regola

Sono uno sviluppatore iOS nativo: lo pratico, lo difendo, lo promuovo e lo insegno. Per me è la via di riferimento per costruire un'app che rispetti le consuetudini della piattaforma e sfrutti appieno ciò che iPhone e iPad sanno fare. Con SwiftUI beneficiate di Dynamic Type, safe areas, sheets, navigazione di sistema e adattamento a iPhone/iPad, con accesso diretto a widget, Live Activities, App Intents e molte altre possibilità dei framework Apple. Questa integrazione fa una differenza concreta nella vita quotidiana e riduce naturalmente i piccoli difetti che chi esamina l'app nota.

Ma nessuna guideline impone SwiftUI. Un'app Expo, Flutter o UIKit ben fatta passa senza problemi. A essere penalizzato è il risultato: una web view mascherata, un'interfaccia che si rompe su iPad (la guideline 2.4.1 incoraggia il supporto per iPad appena possibile), una tastiera che copre un campo. Lo sviluppo nativo aumenta le vostre possibilità di raggiungere l'eccellenza; non la garantisce.

P.S.: Martin, non picchiare, non picchiare, non picchiaaaa... smack

Informativa sulla privacy, supporto e permessi

Qui spesso si sottovaluta la realtà. Non sono buone pratiche, sono obblighi:

• Un'informativa sulla privacy accessibile in App Store Connect e nell'app (5.1.1(i)). Deve descrivere i dati raccolti e i loro usi, impegnare le terze parti a un livello di protezione equivalente e spiegare conservazione, eliminazione e revoca del consenso.
• Un link di supporto con recapiti aggiornati e tutti i link funzionanti (2.1 e 5.1).
• Purpose strings chiare per ogni permesso sensibile, idealmente con un esempio concreto d'uso.
• La minimizzazione dei dati (5.1.1(iii)): privilegiate i selettori di sistema, come quello delle foto, rispetto all'accesso completo alla libreria fotografica.
• L'eliminazione dell'account nell'app quando è possibile crearne uno (5.1.1(v)).

Il formato «HTML statico» spesso consigliato non è obbligatorio. Ciò che conta è che la pagina sia accessibile, aggiornata e coerente con ciò che fa l'app.

Le app social: quattro requisiti precisi

Segnalazione, blocco, contatto, moderazione: è esattamente la guideline 1.2 (User-Generated Content), che richiede:

1. un modo per filtrare i contenuti inaccettabili prima della pubblicazione;
2. un meccanismo di segnalazione e una risposta rapida alle segnalazioni;
3. la possibilità di bloccare gli utenti abusivi;
4. recapiti pubblicati per potervi contattare.

Dall'aggiornamento del 16 ottobre 2026, la guideline cita esplicitamente le app di creazione tramite IA e Apple precisa che le immagini intime non consensuali, comprese quelle generate dall'IA, devono essere attivamente prevenute e rimosse. Uno sviluppatore che non introduce salvaguardie, o non corregge dopo una notifica, può essere considerato in violazione del codice di condotta.

L'API gratuita di moderazione di OpenAI ricorre spesso nelle discussioni. È un'opzione tecnica valida, con una precisazione importante: la guideline 5.1.2(i) impone di dichiarare chiaramente quando i dati personali vengono condivisi con terze parti, compresa un'IA di terzi, e di ottenere un permesso esplicito. Inviare le foto dei vostri utenti a un modello esterno senza dirlo significa sostituire un rifiuto con un altro.

Gli acquisti in-app devono funzionare

Sembra ovvio, ma spesso non accade: la guideline 2.1(b) richiede acquisti in-app completi, visibili e funzionanti per chi esamina l'app. Se un prodotto configurato non è accessibile nella build inviata, spiegate perché nelle note. E prevedete un pulsante «Ripristina acquisti».

---

Le note per la revisione: la leva più sottovalutata

È il consiglio più utile di tutti, e Apple va ancora oltre.

Cosa chiede Apple nella checklist «Before You Submit»:

• accesso completo all'app: account demo attivo o modalità demo completa, più l'hardware o le risorse necessarie (credenziali, codice QR di esempio…);
• un back-end online per tutta la durata della revisione;
• una spiegazione dettagliata delle funzionalità non evidenti e degli acquisti in-app nelle note, con documentazione se necessaria.

Sì, c'è una parte di automazione, ed è normale con questo volume. Ma Apple lo scrive nero su bianco nell'introduzione delle sue linee guida: ogni app viene esaminata da esperti. In nove casi su dieci, se non di più, ai comandi c'è un essere umano che preme il bottoncino verde (o rosso).

Le vostre note si rivolgono quindi a una persona che scopre la vostra app in pochi minuti. Scrivetele per lei.

E la guideline 2.3.1(a) è inequivocabile: ogni nuova funzionalità deve essere descritta con precisione nelle note e le descrizioni generiche vengono respinte.

Attenzione a un dettaglio: una modalità demo al posto di un account demo è accettata solo previo accordo di Apple e soltanto se obblighi legali o di sicurezza vi impediscono di fornire un account.

Una struttura che funziona

Non serve ricopiare il romanzo di qualcun altro. Ecco lo scheletro che uso:

Buongiorno,

[Nome dell'app] è [una frase: cosa fa l'app, per chi e quale problema risolve].
Modello di business: [gratuita / abbonamento / acquisto unico], tramite In-App Purchase.

Accesso:
- Account demo: [identificativo] / [password]
  (oppure: nessun account richiesto)

Percorso principale:
1. …
2. …
3. …

Acquisti in-app:
- Dove appare il paywall, come provarlo in sandbox.
- «Ripristina acquisti»: [posizione].

Funzionalità non evidenti:
- [Funzione]: come accedervi, cosa fa.

Dati e permessi:
- Quali permessi, quando vengono richiesti e perché.
- Dati condivisi con terze parti (compresa IA) e consenso.

Servizi esterni:
- [Servizio]: a cosa serve (dati, autenticazione, pagamenti, IA, pubblicità…).

Differenze regionali:
- [Nessuna / quali].

Normativa e contenuti di terzi:
- [Non applicabile / documenti allegati].

Account e sicurezza:
- Eliminazione account: [percorso].
- Segnalare / bloccare: [percorso] (in presenza di contenuti degli utenti).

Quanto allo stile, la regola d'oro: frasi brevi, comprensibili a chi scopre l'app. Mi limiterei a sfumare il «non usate l'IA» che a volte si legge: far scrivere una prima bozza a un agente che conosce il vostro codice fa davvero risparmiare tempo. Ciò che conta è rileggere e semplificare prima dell'invio.

Un esempio reale: dichiarare ciò che è controllato a distanza

Ecco una nota che ho lasciato su una delle mie app (anonimizzata). Il caso è comune: l'SDK pubblicitario è integrato, ma gli annunci non possono essere attivati prima della pubblicazione, perché AdMob richiede un'app pubblicata su uno store per convalidarne l'«app readiness». Al momento della revisione gli annunci sono quindi disattivati tramite un feature flag.

ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.

The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.

The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=en

Perché questa nota funziona:

• Indica ciò che è nel binario: l'SDK AdMob e il modulo di consenso UMP.
• Dichiara il feature flag e precisa che non è rivolto alla revisione. È l'esatto contrario di una funzionalità dormiente ai sensi della guideline 2.5.19.
• Spiega perché, con una fonte esterna verificabile.
• Annuncia cosa cambierà dopo la pubblicazione, affinché l'attivazione degli annunci non sia una sorpresa.
• Ricorda il consenso: gli annunci personalizzati resteranno soggetti alle autorizzazioni di tracciamento.

Niente di nascosto, niente da interpretare: chi esamina l'app sa esattamente cosa sta approvando.

Il video dimostrativo: non obbligatorio, ma sempre più richiesto

A volte si legge che i primi invii senza note né video verrebbero respinti automaticamente. Niente nella documentazione Apple lo dice. Apple scrive che bisogna essere pronti a fornire un video dimostrativo o l'hardware quando alcune funzionalità dipendono da un ambiente difficile da riprodurre o da hardware specifico.

In pratica, una breve registrazione dello schermo commentata, allegata in App Review Information, aiuta molto non appena l'app esce dall'ordinario: dispositivo connesso, geolocalizzazione, funzionalità social che richiede più account. Per un'app di note senza account, è superflua.

L'obiettivo resta giusto: rendere evidente la revisione. Chi capisce la vostra app in tre minuti non ha alcun motivo di farvi domande.

Quando Apple vi chiede «maggiori informazioni»

Per le nuove app, un messaggio ricorre sempre più spesso: una richiesta standardizzata di informazioni, collegata alla guideline 2.1. Ecco quella che ho ricevuto recentemente per una delle mie app:

We need additional information to better understand the app and complete the review.

Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:

1. A screen recording captured on a physical device, running the latest operating
   system, demonstrating the app's functionality. The recording must begin with
   launching the app and show the typical user flow. If the app has any of the
   following, include them in the recording:
   - Account registration, login, and account deletion flows.
   - Any user-generated content, including the required content reporting and
     blocking mechanisms.
   - Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
   it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
   any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
   its core functionality (for example, data providers, authentication services,
   payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
   that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
   third-party material, provide any relevant documentation or credentials to
   demonstrate you are authorized to provide these services or protected material

Il messaggio ricorda anche le insidie classiche: bug su un dispositivo fisico, account demo, screenshot che mostrano l’app in uso, acquisti in-app configurati insieme all’app, distribuzione riservata alle aziende.

Ed ecco la mia risposta, anonimizzata:

1. [Screen recording attached, captured on a physical device.]

2. [App] is a [category] app that [what the app does]. It's inspired by
   [well-known reference], but adds [its own distinctive features]. It's designed
   for [target audience], and [the problem it solves / the value it provides].

3. There's no account to create and no login required. Users can simply open the
   app and start using it. The main flow consists of [main interaction]. Users
   can also [secondary features] directly from the app. The app includes optional
   rewarded ads to unlock [optional extra].

4. The app runs primarily on the device. [Core processing] is handled locally,
   so there's no external API involved in the core functionality. Google's AdMob
   is used to display advertisements, including optional rewarded ads.

5. The app works the same way in every region where it's available. The main
   difference is the language: the app has a localized name and content adapted
   to each language. Features and core mechanics remain consistent across all
   supported regions.

6. Not applicable. [App] is an original app and doesn't operate in a regulated
   industry.

Tre insegnamenti:

• Il video non è richiesto d'ufficio, ma qui viene chiesto esplicitamente, registrato su un dispositivo fisico, con l'ultima versione di iOS, a partire dall'avvio dell'app. Tanto vale prepararlo prima del primo invio.
• Apple chiede di aggiungere queste risposte nel campo Notes, per gli invii successivi. In altre parole: se fossero state lì fin dall'inizio, probabilmente lo scambio si sarebbe evitato.
• Le sei domande sono un'ottima checklist. Scopo, pubblico, accesso, servizi esterni, differenze regionali, normativa: le ho integrate nel modello di note qui sopra.

---

Cosa non fare (e perché a volte è peggio di un rifiuto)

Le schermate «prossimamente»

Contenuti provvisori, pulsanti inattivi, link vuoti: è il cuore della guideline 2.1 e la prima causa di problemi secondo Apple. Eliminate la funzionalità dalla build invece di mostrarla a metà.

Modificare il paywall dopo la revisione

A volte si vede «rendere non conforme un paywall remoto dopo la revisione» classificato tra i semplici dark pattern. È molto più grave di così.

La guideline 2.5.19, aggiunta il 16 ottobre 2026 per colpire esplicitamente il bait-and-switch, vieta le funzionalità nascoste, dormienti o non documentate e prevede la rimozione dell'app e la revoca dell'account sviluppatore. L'introduzione delle linee guida è ancora più diretta: tentare di ingannare il processo di revisione porta alla rimozione delle app e all'esclusione dall'Apple Developer Program. Non è una scommessa sulla clemenza di chi esamina l'app, è un rischio per tutta la vostra attività.

Configurare il paywall a distanza non è vietato. Cambiarlo in qualcosa che chi esamina l'app non ha visto, sì.

Le richieste di valutazione

La guideline 5.6.1 impone l'uso dell'API fornita da Apple per chiedere una valutazione e vieta i prompt personalizzati. La guideline 3.2.2(x) vieta di subordinare l'accesso a una funzionalità alla valutazione dell'app.

Chiedere una valutazione durante l'onboarding non è esplicitamente vietato, ma è assurdo: l'utente non ha ancora visto nulla e il sistema limita comunque la frequenza con cui viene mostrata la richiesta. Aspettate un vero momento di soddisfazione.

La falsa prova sociale e le promesse non verificabili

«Un milione di utenti» inventato, recensioni false, «risolve il 100% dei vostri problemi»: la guideline 5.6.3 vieta qualsiasi manipolazione di recensioni, classifiche o ricerca, e la 2.3.7 vieta le affermazioni non verificabili nei metadati. Per le app sanitarie, la 1.4.1 richiede di documentare la metodologia alla base di ogni promessa di accuratezza.

Copiare un'app

Sembra ovvio, e Apple va oltre. La guideline 4.1 respinge le copie e spacciarsi per un'altra app viola il codice di condotta. La 4.3 chiude la porta alle categorie sature (torce, sfondi, app di incontri, semplici timer…), salvo offrire un'esperienza realmente diversa. Esistono già un milione di cuscini scoreggia, torce e app di incontri: Apple cita espressamente le app di peti e rutti tra quelle che non aggiungono nulla all'App Store.

Le offerte di fidelizzazione: usare gli strumenti ufficiali

Si parla molto di «transaction abandon» e di «exit offers» (proporre un'offerta a chi è indeciso o vuole disdire). Queste pratiche non sono vietate di per sé e StoreKit offre meccanismi ufficiali per farlo: offerte promozionali, offerte di riconquista (win-back offers), schermata di sistema per la gestione degli abbonamenti.

Riservarle a un aggiornamento successivo è ragionevole: meno cose da esaminare, meno domande. Ma la vera regola è altrove. La guideline 3.1.2(c) richiede di descrivere chiaramente cosa ottiene l'utente per il prezzo pagato e la 5.6 vieta di spingere ad acquisti indesiderati. Un'offerta chiara, descritta nelle note, non ha nulla da temere. Un'offerta che confonde sul prezzo, sì.

---

La revoca degli account: capire per non esserne coinvolti

Un rifiuto costa qualche giorno. Una revoca costa tutte le vostre app. Nelle ultime settimane l'argomento occupa molto spazio sui social e merita di essere affrontato con calma.

Perché Apple stringe la vite

Il 16 ottobre 2026 Apple ha rafforzato le proprie linee guida su due punti: le immagini intime non consensuali, comprese quelle generate dall'IA, che le app devono prevenire e rimuovere (1.2), e il bait-and-switch, ovvero le app che appaiono innocue durante la revisione e attivano funzionalità dannose dopo l'approvazione (2.5.19). Nello stesso annuncio Apple afferma di aver impedito a oltre 150.000 app con problemi di sicurezza di raggiungere gli utenti l'anno scorso e di aver revocato oltre 193.000 account sviluppatore per frode e abusi.

Questi numeri dicono l'essenziale: la frode sull'App Store è massiccia e organizzata. Le app di «nudificazione» si sono moltiplicate, autorità come la città di San Francisco ne hanno chiesto la rimozione e l'afflusso di invii generati con l'IA aumenta ulteriormente la pressione. Se la fiducia degli utenti nell'App Store resiste nonostante tutto, è in gran parte grazie a questo lavoro.

Su questa scala capita anche che sviluppatori in buona fede finiscano nella rete. È proprio per questi casi che esiste il ricorso all'App Review Board.

Cosa raccontano alcuni sviluppatori

Le notifiche condivise invocano la sezione 3.2(f) del Developer Program License Agreement e parlano di uno «schema di comportamento manipolatorio o ingannevole», seguito da un elenco di possibili comportamenti: metadati inesatti, contenuti ingannevoli, recensioni false, risposte ingannevoli al supporto o in App Store Connect, acquisti in bait-and-switch…

Phillip Shoemaker, che ha diretto App Review, ha pubblicato a fine ottobre la sua analisi. Ritiene che lo storico dei rifiuti pesi ormai molto: numero di invii, cambi di nome, rifiuti ripetuti per contenuti inaccettabili, in particolare per le app fotografiche generative. Riconosce anche la difficoltà dal lato di Apple: le app generative sono molto difficili da esaminare, una correzione lato server può essere annullata in qualsiasi momento e Apple collega gli account tra loro, ottenendo una visione che lo sviluppatore non sempre ha. Le sue proposte sono costruttive: rifiuti più precisi su ciò che deve cambiare ed elementi concreti nelle notifiche affinché il ricorso sia utile.

Chi troppo vuol fare il furbo finisce nel burrone

Non serve fare nomi: le storie che circolano si assomigliano. E, leggendole da vicino, si ritrovano spesso le stesse reazioni. Raramente partono da una cattiva intenzione, ma viste da Cupertino assomigliano moltissimo a ciò che Apple cerca di individuare:

• Inviare di nuovo in continuazione cambiando ogni volta un dettaglio, «per vedere se passa».
• Rinominare l'app, cambiare concetto o categoria in corsa, a volte più volte.
• Correggere solo in superficie: rimuovere un'opzione da un menu mentre la funzionalità resta accessibile in altro modo.
• Mantenere un interruttore lato server che chi esamina l'app non ha mai visto.
• Riempire di parole chiave, o ispirarsi un po' troppo al nome di un'app concorrente.
• Moltiplicare gli account, o prestare il proprio, per aggirare un rifiuto.
• Aggiustare la verità nelle risposte ad App Review.

Preso isolatamente, ciascuno di questi gesti può sembrare innocuo. Messi insieme, delineano uno schema. E sulla scala di centinaia di migliaia di invii a settimana, è quello schema che Apple legge, non le vostre intenzioni.

La morale è semplice: fare i furbi con App Review significa scommettere contro il banco. E il banco ha lo storico completo.

L'App Review Board resta a disposizione per correggere un errore e gli sviluppatori in buona fede vi ottengono ragione. Ma il miglior ricorso è quello che non si ha mai bisogno di presentare.

Cosa cambia per voi

Non fingerò di essere un giurista: per una revoca, l'unica strada è il ricorso all'App Review Board e, nei casi riportati, la notifica concede 30 giorni per presentarlo. Se vi succede, fatevi assistere. Alcune buone abitudini, invece, riducono nettamente il rischio:

• Il vostro storico dei rifiuti conta. Ogni invio lascia una traccia. Non inviate mai di nuovo «per vedere»: ponete una domanda precisa in App Store Connect prima di correggere.
• Non cambiate l'identità dell'app in corsa. Nome, concetto, categoria: cambiamenti ripetuti assomigliano a ciò che Apple cerca di individuare. Se è App Review a chiedervelo, fatevelo confermare per iscritto in App Store Connect, anche dopo una chiamata, e riepilogate per iscritto ciò che è stato detto al telefono.
• Quando un rifiuto si ripete in un ciclo, smettete di inviare. Chiedete per iscritto l'elenco completo dei punti bloccanti, poi ricorrete all'App Review Board invece di concatenare tentativi.
• Documentate tutto ciò che è configurabile a distanza. Feature flag, paywall, modelli di IA: indicatelo nelle note e mostrate cosa può cambiare.
• Per un'app generativa, correggete alla fonte. Rimuovere un'opzione da un menu non basta se il modello produce ancora il contenuto con un semplice prompt. Il filtraggio deve essere effettivo, sia sul modello sia sull'output.
• Rispondete con esattezza in App Store Connect. Le «risposte ingannevoli» figurano esplicitamente nell'elenco dei motivi.
• Conservate un archivio di ogni invio. Build, note, screenshot, scambi con App Review: è il vostro unico dossier in caso di ricorso.
• Fate attenzione alle vostre frequentazioni. Account condivisi, certificati prestati, soci con pratiche dubbie: Apple collega gli account tra loro.

È anche per questo che non condivido l'idea, talvolta avanzata, che «Apple vorrebbe che cercassimo il limite». Nel 2026 ogni invio conta nel vostro storico. Meglio puntare alla chiarezza che al limite.

---

Accelerare una revisione: cosa esiste davvero

È qui che circolano più luoghi comuni.

La revisione accelerata (expedite)

Esiste, per circostanze eccezionali: un bug critico o un lancio legato a un evento a cui siete direttamente associati. Alcune precisazioni spesso dimenticate:

• solo un invio già trasmesso per la revisione può essere accelerato;
• per un bug critico, indicate nelle note i passaggi per riprodurlo sulla versione attuale;
• per un evento, indicate l'evento, la sua data e il legame dell'app con esso;
• Apple gestisce la richiesta in base alla disponibilità e alla domanda, senza garanzie;
• e soprattutto, in caso di abuso, Apple si riserva il diritto di respingere le vostre richieste future.

«Non serve dare una ragione» è quindi fuorviante: il modulo è semplice, ma la motivazione deve trovarsi nelle note. Quanto al «momento virale» o al «marketing», non figurano tra i criteri. Io non mi giocherei questa cartuccia per questo.

La chiamata con Apple: non è una corsia preferenziale

La chiamata viene spesso presentata come un metodo poco conosciuto che farebbe passare in una coda separata. Non è ciò che descrive Apple.

Si può richiedere una chiamata con un rappresentante Apple dalla finestra di risposta ad App Review, dopo una prima risposta da parte loro, indicando il proprio fuso orario e la lingua. Queste chiamate avvengono generalmente entro tre-cinque giorni lavorativi. È uno strumento eccellente per chiarire un malinteso su un rifiuto. Non è in alcun modo una scorciatoia verso le 48 ore. Tenete presente che la revisione successiva potrebbe essere condotta da un'altra persona: fate sempre confermare le conclusioni per iscritto in App Store Connect.

Gli appuntamenti App Review: il vero segreto

Ciò che viene menzionato raramente, e che raccomando a tutti i miei clienti prima di un primo invio delicato: gli appuntamenti App Review tramite Meet with Apple. Trenta minuti in video con un esperto App Review, il martedì e il giovedì secondo disponibilità, per porre domande precise su come una guideline si applica alla vostra app.

Due limiti da conoscere: l'appuntamento è informativo, non sostituisce, accelera né garantisce la revisione e Apple non preapprova alcuna funzionalità. Ma arrivare all'invio sapendo già come Apple interpreta il vostro caso è il miglior investimento possibile.

Uscire dal ciclo dei rifiuti successivi

L'incubo è ben noto: un rifiuto, una correzione, poi un nuovo rifiuto per un altro motivo. Per uscirne bisogna utilizzare i canali giusti:

• Rispondere in App Store Connect con una domanda precisa: la funzionalità, la guideline o il passaggio da chiarire. Vi risponde uno specialista che conosce la vostra app. Chiedere «ci sono altri punti bloccanti?» è legittimo, anche se nessuno può garantirvelo.
• La Bug Fix Submission: per un'app già pubblicata, un aggiornamento correttivo non è bloccato da altri problemi relativi alle linee guida, salvo questioni legali o di sicurezza. Correggete il resto nell'invio successivo.
• Il ricorso all'App Review Board se ritenete che l'app sia stata fraintesa: una sola volta per invio respinto, con argomenti precisi.

Quanto al tono, la guideline 5.6 ricorda di trattare tutti con rispetto, anche negli scambi con Apple. Lamentarsi non serve a nulla; argomentare sulla base delle linee guida, sì.

---

Lo scope creep: il consiglio migliore, con una sfumatura

«Inviate un MVP» è un ottimo consiglio e Apple lo conferma a modo suo: un'app complessa o che solleva questioni nuove può richiedere un esame più approfondito, e i rifiuti ripetuti per la stessa guideline allungano la revisione.

La descrizione di «due pile» con un'escalation a uno specialista senior e 14 giorni di attesa, invece, non è documentata da nessuna parte. Ciò che Apple documenta sono settori regolamentati che richiedono più documenti e tempo:

• le app di banca, finanza, salute, gioco d'azzardo, cripto o trasporto aereo devono essere inviate dalla persona giuridica che fornisce il servizio (5.1.1(ix));
• per il gioco d'azzardo occorre prevedere tempi aggiuntivi (5.3);
• le app mediche o legate a contenuti concessi in licenza devono fornire le relative autorizzazioni.

Un'ultima sfumatura: un MVP non è un'app scarna. La soglia della guideline 4.2 si applica fin dalla prima versione. Riducete il numero di funzionalità, non la loro cura.

---

In sintesi: vero, da sfumare, falso

---

La mia checklist prima dell'invio

Completezza (2.1)

• Testata su dispositivi, con l'ultima versione di iOS, su iPhone e iPad
• Nessun contenuto provvisorio, nessun link non funzionante
• Back-end online, account demo valido
• Acquisti in-app visibili, funzionanti in sandbox, ripristino disponibile

Informazioni per la revisione

• Note: cosa fa l'app, percorso principale, funzionalità non evidenti, acquisti
• Recapiti aggiornati in App Review Information
• Video o documenti allegati se l'ambiente è difficile da riprodurre

Privacy e sicurezza (5.1, 1.2)

• Informativa sulla privacy in App Store Connect e nell'app
• Purpose strings precise, selettori di sistema quando possibile
• Condivisione con terze parti (compresa IA) dichiarata e autorizzata
• Eliminazione dell'account nell'app
• Se ci sono contenuti degli utenti: filtraggio, segnalazione, blocco, contatto

Metadati (2.3)

• Screenshot che mostrano l'app in uso
• Nessuna promessa non verificabile, nessuna falsa prova sociale
• Acquisti a pagamento chiaramente segnalati

Strategia

• Prima versione essenziale, offerte avanzate in un aggiornamento successivo
• Almeno una settimana di margine prima della data di lancio di una nuova app
• Archivio di ogni invio: build, note, screenshot, scambi con App Review
• Appuntamento App Review fissato se una guideline vi lascia dubbi

---

Il vero segreto: essere noiosi e onesti

A volte si legge che Apple vorrebbe che cercassimo il limite. Non sono d'accordo. Le linee guida sono un documento vivo e Apple si assume una parte di discrezionalità. Ma l'introduzione è chiara: il principio è un'esperienza sicura per gli utenti e qualsiasi tentativo di ingannare la revisione si paga molto caro.

Per il resto, una regola mette tutti d'accordo: siate chiari, siate onesti, spiegate cosa fate e mostratelo. Un invio completo, leggibile e senza sorprese passa nei tempi normali. Per un aggiornamento, spesso sono meno di 48 ore. Per una nuova app nel 2026, prevedete piuttosto una settimana e lasciatevi sorprendere piacevolmente.

Con agenti che permettono a tutti di inviare un'app in un fine settimana, App Review torna a essere ciò che era all'inizio: un filtro. Ed è una buona cosa. È questo filtro che permette a un utente di installare un'app sconosciuta senza diffidare, ed è questa fiducia a dare valore all'App Store per noi sviluppatori. I team App Review gestiscono centinaia di migliaia di invii a settimana; facilitare loro il lavoro significa anche semplificarsi la vita.

Tanto vale stare dalla parte giusta del filtro.

---

Creo e pubblico app dalla nascita dell'App Store, per me, per startup o per marchi che hanno il loro negozio sugli Champs-Élysées. Se state preparando un primo invio delicato, un'app social, un modello di abbonamento o un'app in un settore regolamentato, è il tipo di assistenza che offro con BNC Consulting. Scrivetemi.

Contattami

E per parlarne tra sviluppatori, unitevi alla community ⌘+F: le storie di rifiuti le condividiamo anche ai meetup, davanti a un caffè o a una cena.

E per finire, un grande bacio a Raph’, Anders, Erica, Ewelina e a tutti gli altri miei amici di App Review, che fanno un lavoro particolarmente difficile. Un altro a Martin, Mac, SiQing e ai team WWDR, che spesso fanno da cuscinetto, e a tutte le altre persone che conosco nel mondo ma che non posso nominare qui.

Grazie per essere lì a proteggere gli utenti. Anche questo è il lato positivo dell’App Store.

— Clément

---

Fonti ufficiali (consultate il 1° novembre 2026)

• App Review — Apple Developer
• App Review Guidelines (aggiornamento del 16 ottobre 2026)
• Richiedere una revisione accelerata
• Contattare App Review e richiedere una chiamata
• Richiedere un appuntamento App Review

Dati e stampa

• MobileGamer.biz — tempi di revisione e afflusso di app generate dall'IA (20 ottobre 2026, con la risposta di Apple corredata di cifre)
• 9to5Mac — aumento dell'84% delle nuove app
• TweakTown — 560.000 nuove app nel primo semestre 2026
• RevenueCat — State of Subscription Apps 2026
• iPhoneSoft — AppReviewTimes chiude i battenti (marzo 2019)
• Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (16 ottobre 2026)
• Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (30 ottobre 2026)
• 9to5Mac — nuove regole contro la nudificazione e il bait-and-switch

---

Come al solito, questo articolo è stato scritto a mano in francese. La traduzione italiana e le illustrazioni sono state realizzate con gli strumenti di OpenAI.