Rifiuto dell'App Store: cosa correggere prima del reinvio

Un rifiuto dell’App Store richiede una risposta adatta al problema citato. Inizia dal messaggio della revisione e verifica che cosa non ha funzionato. Le attuali indicazioni di Apple consentono di rispondere dopo aver corretto informazioni, metadati o problemi lato server; una correzione al codice della build inviata richiede una nuova build. Se contesti la decisione, chiariscila prima di presentare ricorso.

Un reinvio immediato può far ripartire un lavoro che avresti potuto risolvere nella conversazione.

Noi iniziamo affiancando il messaggio all’app inviata e annotando ciò che il revisore poteva vedere. In questo modo hai un compito concreto da discutere con lo sviluppatore, anche se non puoi modificare personalmente il codice.

Che cosa dice davvero il rifiuto dell’App Store?

Leggi lo stato e l’elemento interessato prima di scegliere una correzione. Il riferimento di Apple sugli stati distingue un invio in attesa di revisione da un’app rifiutata o da informazioni della scheda rifiutate. Un invio può comprendere diversi elementi. Annota quale presenta il problema, la linea guida citata e la spiegazione del revisore; il solo badge di un vecchio rifiuto fornisce troppo poche informazioni per agire.

Per metadati si intendono le informazioni della scheda, come descrizioni e screenshot, esterne al pacchetto eseguibile dell’app. Una build è la versione pacchettizzata inviata alla revisione. Le App Review Guidelines di Apple considerano la completezza, l’accuratezza dei metadati e una funzionalità sufficiente dell’app come requisiti distinti. Una descrizione più chiara non può risolvere un arresto anomalo, mentre una funzionalità operativa potrebbe comunque richiedere informazioni migliori per la revisione.

Conserva una scheda dell’attività con questi campi: elemento interessato, linea guida, problema osservato, correzione proposta, prove, persona responsabile e azione successiva. Usa il problema effettivamente indicato dal revisore. Se il messaggio non lo spiega, contrassegna un campo come sconosciuto e poi poni una domanda mirata.

Individua il problema che il revisore ha potuto riprodurre

Prova la versione inviata partendo dal punto descritto nel messaggio. Il tuo account abituale potrebbe già disporre di un accesso o aver completato una configurazione che manca al revisore. Le indicazioni di Apple sulla preparazione richiedono credenziali demo funzionanti e le informazioni necessarie per raggiungere le funzionalità dell’app. Controlla l’intero percorso prima di chiedere allo sviluppatore una nuova versione.

1. Verifica versione e ambiente. Chiedi allo sviluppatore quale build è stata inviata e su quale dispositivo e sistema operativo è stata provata. La guida di Apple sui test dei dispositivi richiede prove su dispositivi fisici, comprese le modalità di compatibilità pertinenti. Annota tutto ciò che non riesci a riprodurre sui dispositivi a tua disposizione.
2. Prova l’account di revisione con un nuovo accesso. Segui i passaggi forniti fino alla funzionalità segnalata. Controlla i ruoli dell’account e le eventuali istruzioni per i codici di autenticazione. La guida di Apple per una revisione completa richiede che questi dati siano forniti in anticipo; le credenziali devono rimanere utilizzabili quando inizia la revisione.
3. Leggi la scheda insieme all’app. Confronta gli screenshot e la descrizione con ciò che quella build fa realmente. Se il rifiuto riguarda un messaggio di autorizzazione, le indicazioni di Apple sulle purpose string richiedono una spiegazione concreta di come l’app usa la risorsa richiesta.
4. Controlla il comportamento relativo alla privacy citato. Per un problema riguardante l’eliminazione dell’account, prova il percorso effettivo. Le indicazioni di Apple richiedono che le app che supportano la creazione di account consentano di avviarne l’eliminazione dall’app; la sola disattivazione non basta. Gli obblighi di conservazione e le eccezioni per le app regolamentate richiedono una verifica specifica.

Usa un account di prova con dati di esempio sicuri. Una registrazione o un allegato deve mostrare il percorso non riuscito o corretto senza esporre dati dei clienti o credenziali.

Rispondere, inviare una nuova build o presentare ricorso?

Scegli la procedura dopo aver stabilito che cosa è cambiato. La guida di Apple sullo stato della revisione distingue le correzioni che possono essere spiegate in una risposta dalle modifiche che richiedono un’altra revisione. La tabella aiuta a decidere in caso di rifiuto già avvenuto; un avviso di rimozione o un provvedimento sull’account richiede una procedura distinta.

Apple avverte che un reinvio avvia una nuova revisione e impedisce di rispondere al messaggio precedente. Un reinvio durante un ricorso chiude il ricorso. Consulta la persona che gestisce la conversazione prima di modificare l’invio.

Un’offerta esplicita di Bug Fix Submission è un caso distinto. La guida di Apple la limita agli aggiornamenti idonei di app approvate in precedenza, in assenza di problemi legali o di sicurezza. L’accettazione avviene tramite risposta, con l’impegno a correggere i problemi nell’aggiornamento successivo. Leggi l’offerta prima di seguire la normale procedura con una nuova build.

Prepara insieme la correzione e le prove

Associa a ogni problema una correzione e un modo per verificarla. Noi teniamo l’attività dello sviluppatore e la risposta al revisore collegate alla stessa scheda, affinché una modifica dell’app si rifletta nelle informazioni inviate con essa. Inizia dai controlli che puoi eseguire personalmente, poi assegna allo sviluppatore le modifiche al codice.

1. Elimina le lacune nell’accesso e nelle informazioni. Aggiorna le note per la revisione con lo scopo dell’app, le funzionalità modificate, i servizi esterni e le differenze regionali quando pertinenti, seguendo la guida di Apple per una revisione completa. Prova di nuovo le credenziali dopo averle modificate.
2. Controlla il sito web collegato. Apri su un telefono gli URL dell’assistenza e della privacy indicati nell’invio. Controlla che la destinazione e il testo corrispondano all’app sottoposta a revisione. Questa verifica di coerenza può rientrare nel lavoro di sviluppo del sito web quando un sito supporta un’app.
3. Chiedi una correzione tecnica dimostrabile. Per un problema della build, chiedi allo sviluppatore di mostrare il percorso segnalato dopo la correzione e di identificare la build che la contiene. Questo passaggio di consegne rientra nello sviluppo e nella pubblicazione di app mobili, insieme alla preparazione della revisione.
4. Invia una risposta mirata. Le istruzioni di Apple per rispondere prevedono l’uso del link dell’app relativo ai problemi non risolti, quindi In Progress, Resolve e Reply to App Review. È richiesto l’accesso Account Holder, Admin o App Manager. Spiega il problema, dove trovare la correzione e come provarla; se utile, allega prove pertinenti, quindi seleziona Reply.
5. Usa il ricorso per un disaccordo ancora irrisolto. La guida di Apple sui ricorsi richiede prima di chiarire la questione e poi di rispondere ai requisiti citati con delle prove. Includi nel ricorso tutte le violazioni indicate per quell’app. Una richiesta di aggiornamento sullo stato o di revisione più rapida va presentata altrove.

Non inserire password Apple personali nella scheda dell’attività. Mantieni l’account sviluppatore sotto il controllo dell’azienda e usa l’accesso appropriato al lavoro di ogni persona.

Come sai che il problema è stato risolto?

Distingui una correzione che hai provato dalla decisione di Apple. Ripeti esattamente il percorso dopo la modifica e conserva il risultato, la versione della build o delle informazioni e la risposta inviata. Poi leggi lo stato corrente in App Store Connect. Un test locale riuscito fornisce informazioni su quel test; la decisione sull’invio spetta comunque ad Apple.

Tieni traccia della presenza di prove per ogni problema citato, del corretto funzionamento dell’accesso per la revisione e dell’eventuale ripetizione dello stesso problema in un messaggio successivo. Se accade, confronta il nuovo messaggio con la tua scheda prima di apportare un’altra modifica. Una volta pubblicata l’app, ottenere download per l’app è un’attività distinta.

Dove interveniamo noi

Partiamo dal messaggio di rifiuto, dalla versione inviata e da un percorso riproducibile nell’app. Possiamo quindi separare le correzioni della scheda e del sito web dal lavoro di sviluppo e preparare le informazioni per il revisore. Porta questi materiali alla persona responsabile della pubblicazione, indicando le domande irrisolte, prima di concordare un’altra build.

← Tutti gli articoli