Resolution Center Apple: rispondere a un rifiuto App Review
Di Mehdi Azizi
Pubblicato il , 9 min
Il Resolution Center ora è la sezione App Review di App Store Connect. Rispondi in inglese: motivo, correzione, verifica. Solo dopo, ricorri al Board.
Il Resolution Center non esiste più con questo nome. Rispondi a un rifiuto nella sezione App Review della tua app, con il pulsante Reply to App Review. Scrivi in inglese e dai tre informazioni: cosa bloccava, cosa è cambiato, come verificarlo. L'App Review Board serve solo dopo questa risposta, e solo se sei sicuro che la tua app rispetti la regola citata.
Ho scritto queste risposte per le mie app nel 2026: Solys, la mia sveglia con minigiochi, e TradaZen, il mio simulatore di trading. Ecco dove rispondere oggi, cosa scrivere, quando allegare un video, quando fare ricorso e cosa non funziona. Per i motivi veri e propri, leggi perché Apple rifiuta un'app.
Dov'è finito il Resolution Center?
La guida ufficiale, Reply to App Review messages, ora parla della sezione App Review. Lì scambi messaggi con Apple, allegati compresi, finché non invii di nuovo la tua submission. Il percorso:
- In Apps, apri la tua app.
- In cima alla pagina, clicca sul link dei problemi non risolti, chiamato View App Review Issues & Messages in un'altra pagina della guida.
- Nella parte In Progress, clicca su Resolve accanto alla submission.
- Clicca su Reply to App Review e scrivi nel campo Reply.
- Per allegare uno screenshot o un documento, clicca su Attach File, poi su Reply.
Solo i ruoli Account Holder, Admin e App Manager possono rispondere. La pagina App Review aggiunge che puoi seguire lo stato delle submission in App Store Connect o nella sua app per iPhone e iPad.
Prima di scrivere: che messaggio hai ricevuto?
La risposta giusta dipende dal messaggio, non dalla tua voglia di difenderti. Ecco la griglia che applico prima di aprire il campo di risposta.
| Cosa dice Apple | Cosa fai | Nuova build |
|---|---|---|
| Information Needed | Rispondi alla domanda | No |
| Bug o schermata difettosa | Correggi, poi rispondi | Sì |
| Scheda, link, screenshot | Correggi la scheda | No |
| App fraintesa | Spiega, con prove | Dipende |
| Disaccordo persistente | Ricorso al Board | No |
| Offerta Bug Fix Submissions | Accetta rispondendo | No |
Tre precisazioni cambiano tutto:
- Un rifiuto sui metadati non richiede una nuova build. Lo dice la guida di Apple: correggi e reinvii la stessa build. Succede spesso con un rifiuto 2.3.10, quando la menzione problematica è nella scheda.
- Un "Information Needed" non è un rifiuto nel merito. Il revisore ti fa una domanda. La guida sulla guideline 2.1 spiega la differenza con un vero bug riscontrato.
- Le Bug Fix Submissions sono un'offerta. Se la tua app è già online e il messaggio inizia con "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update", puoi chiedere l'approvazione dell'aggiornamento rispondendo al messaggio. Non reinviare l'app in quel momento, altrimenti parte una nuova revisione. Risolvi il problema nella versione successiva.
Cosa scrivere: il modello in quattro blocchi
Apple ha pubblicato i suoi consigli per contattare App Review. Da fare: essere precisi su cosa chiedi e dare le informazioni che aiutano a capire l'app, se pensi che sia stata fraintesa. Da evitare: usare il campo di risposta per fare ricorso o chiedere una revisione accelerata, o chiedere a che punto sono le app di altri sviluppatori.
Il mio modello sta in quattro blocchi. Scrivi in inglese, senza aggettivi. Sostituisci tutto ciò che è tra parentesi quadre e scrivi solo ciò che è vero nella build inviata.
Hello App Review team,
Thank you for your review and for the details on
Guideline [number].
What you reported: [one sentence that restates
Apple's message, in your own words].
What changed in build [version (build)]:
- [Screen or element]: [what it does now]
- [Screen or element]: [what it does now]
How to verify:
1. [Starting point, e.g. fresh install]
2. [Action]
3. [Expected result]
We tested this flow on [devices and iOS versions].
[Attached: a short screen recording of the fixed flow.]
If anything else is unclear, please tell us which
screen or wording, and we will change it.
Best regards,
[Your name]
Ogni blocco ha un ruolo. Il primo dimostra che hai letto. Il secondo nomina la build, perché il revisore testa il binario, non le tue intenzioni. Il terzo gli fa risparmiare tempo. L'ultimo lascia la porta aperta senza perorare la tua causa.
I modelli adattati a ogni regola sono nelle mie guide dedicate, per esempio sulla guideline 3.1.2 o sulla guideline 4.3. Una traccia di risposta c'è anche nel mio modello di note App Review, da scaricare.
Cosa ho imparato rispondendo per Solys e TradaZen
Solys, guideline 2.1. Il revisore chiedeva un modo per aggirare il gioco. La mia risposta indicava la schermata bloccante, la demo giocabile dell'onboarding, poi la vera causa: in modalità compatibilità su iPad, il suo ostacolo diventava insuperabile. Elencava due correzioni numerate, tra cui un link per saltare la demo dopo un fallimento, poi i simulatori testati, dall'iPhone SE all'iPhone più grande. Descriveva anche il pulsante di arresto d'emergenza della sveglia, ma solo dopo che avevo riletto il codice che lo attiva. Non scrivere niente sulla tua app che non hai verificato nella build.
TradaZen, guideline 5.6. Nell'ottobre 2026 Apple ha giudicato che l'app spingesse ad acquisti in-app non voluti, senza indicare un elemento preciso. Ho cercato cosa potesse ingannare: una X in alto nel paywall apriva un'offerta scontata invece di chiudere la schermata. La mia risposta lo riconosceva in una frase: era un mio errore. Poi elencava ogni modifica, schermata per schermata: la X sostituita da un regalo, nessuna offerta che si riapre da sola, una notifica promozionale eliminata. Ricordava cosa restava conforme: prezzo addebitato più visibile, ripristino degli acquisti, link legali. Finiva proponendo di modificare qualsiasi schermata ancora ritenuta ambigua. La nuova build è partita insieme alla risposta.
Queste due risposte seguono la stessa logica: la causa reale, la correzione visibile, il percorso per vederla.
Quando allegare un video o uno screenshot
La guida di Apple accetta come allegati screenshot e documenti. Un breve video della schermata corretta è utile in tre casi:
- il problema dipende da un dispositivo o da una condizione, come un iPad in modalità compatibilità o un permesso negato;
- il percorso è lungo fino alla schermata, per esempio alla fine dell'onboarding;
- la funzione è difficile da riprodurre. La pagina App Review chiede di essere pronti a fornire un video dimostrativo quando una funzione richiede un ambiente difficile da ricreare o un hardware specifico.
Per un'app legata a un accessorio, la guida sulla revisione completa richiede un vero video girato su un dispositivo Apple, non una registrazione dello schermo. Per un testo del paywall o un pulsante rinominato basta uno screenshot.
Chiedere una chiamata o un appuntamento
Se lo scritto non basta, Apple prevede due opzioni:
- Una chiamata con un rappresentante Apple. La chiedi nella finestra Reply to App Review, dopo una prima risposta di App Review. Indica il tuo fuso orario e, se vuoi, la lingua preferita. Prima controlla i tuoi recapiti in App Review Information. Apple indica che queste chiamate avvengono in genere entro tre-cinque giorni lavorativi.
- Un appuntamento di 30 minuti in videochiamata con App Review, il martedì o il giovedì, per parlare delle regole. È informativo: non accelera né garantisce la revisione.
Fare ricorso all'App Review Board
Il ricorso è l'ultimo passo. Secondo la pagina Appeal to the App Review Board, è adatto se la tua app è stata rifiutata mentre pensi che rispetti le regole, o se ritieni di essere stato trattato in modo ingiusto.
Prima di tutto, rispondi al messaggio in App Store Connect per chiarire. Se non basta, compila il modulo Submit an appeal to App Review. Le regole:
- un solo ricorso per app rifiutata, che tratti tutte le regole citate;
- cita la regola e spiega punto per punto perché la tua app la rispetta;
- non fare ricorso se hai già corretto e reinviato l'app;
- non fare ricorso per una semplice richiesta di informazioni.
Apple dà due esempi, che traduco. Completo: "La mia app è stata rifiutata ai sensi della 2.1 per informazioni incomplete. L'account demo e i passaggi per testare la funzione sono in App Review Information, con screenshot che la mostrano." Incompleto: "Questa app è importante per la mia azienda e non avrebbe dovuto essere rifiutata."
Il Board risponde in App Store Connect e può chiedere informazioni o proporre una chiamata. Apple non pubblica alcun tempo per il ricorso. Alcuni sviluppatori raccontano sui forum di Apple attese di oltre due settimane. Se la correzione è semplice, reinviare una build corretta spesso è più rapido.
Cosa funziona, cosa no
| Aiuta | Danneggia |
|---|---|
| Riprendere il motivo di Apple | Perorare la tua causa |
| Nominare la build corretta | Promettere una correzione futura |
| Dare il percorso da seguire | Citare un'app concorrente |
| Allegare una prova | Fare ricorso in Reply |
| Una risposta completa | Reinviare senza correggere |
Anche "La mia schermata era già stata accettata" non funziona: ogni versione ripassa in revisione, a volte davanti a un altro revisore. Le App Review Guidelines avvertono anche che un'app rifiutata più volte per la stessa regola richiede più tempo per essere esaminata. Per i tempi di revisione, leggi tempi di approvazione App Store.
Far rileggere la risposta prima dell'invio
Il Review Kit contiene i veri messaggi ricevuti per le mie app, le correzioni inviate e delle skill di Claude Code che preparano la tua risposta se Apple rifiuta. Per uno sguardo umano, prenota un'ora con me: leggiamo il messaggio di Apple e scriviamo la risposta insieme. Il percorso completo è nella pagina app rifiutata da Apple.
Non hai ancora inviato la tua app? Fai la tua diagnosi gratuita: ti manda la mia checklist anti-rifiuto Apple, così eviti di dover scrivere questa risposta.
Domande frequenti
Dove si trova il Resolution Center in App Store Connect?
Ora si chiama sezione App Review. Apri la tua app, clicca sul link dei problemi non risolti in cima alla pagina, poi su Resolve accanto alla submission. Il pulsante Reply to App Review apre il campo di risposta e l'aggiunta di allegati.
Quanto tempo ci mette Apple a rispondere?
Apple non pubblica tempi per le risposte scritte. Per la revisione, Apple dichiara che almeno il 50% delle submission viene esaminato in meno di 24 ore e il 90% in meno di 48 ore. Una chiamata richiesta ad App Review avviene in genere entro tre-cinque giorni lavorativi. Per l'App Review Board non è dichiarato alcun tempo.
Si può rispondere in francese ad App Review?
La guida di Apple non fissa alcuna lingua per la risposta scritta. Io scrivo in inglese, con frasi brevi, per essere capito al primo colpo. Per una chiamata, Apple permette di indicare una lingua preferita, senza garanzie.
Quante volte si può fare ricorso contro un rifiuto?
Una volta per app rifiutata. Se il messaggio cita più regole, il tuo ricorso deve trattarle tutte. Apple chiede anche di rispondere prima in App Store Connect e di non fare ricorso se hai già reinviato una build corretta.
Bisogna reinviare una build prima di rispondere?
Sì se il problema è nell'app: correggi, invia la build, poi rispondi nominando quella build. No se il rifiuto riguarda i metadati, come la scheda o gli screenshot: correggi in App Store Connect e reinvii la stessa build.

