Archivio delle rifiuti della community

La storia del rifiuto dell'app store

I peggiori loop di rifiuto di Apple App Store e Google Play, raccolti come screenshot e testo semplice per consentire ai team mobili di imparare cosa costino le code di revisione.

Regola di invio

1 a 5 immagini più il testo della storia.

Non inserire link all'interno delle storie. Utilizza solo immagini locali. Tieni il rifiuto doloroso, specifico e utile.

Storie seminate

Negozio coperto

5 al massimo

Immagini per storia

The archivio

Rifiuti che costano più di una cattiva sprint

Ogni storia è testo-in-primo piano, immagine-backup e intenzionalmente priva di collegamenti esterni per mantenere l'archivio leggibile.

Richiesta di Apple App Review che chiede chi saranno gli utenti dell'app di Adrien

Apple App Store Assurdo Condiviso da Adrien

L'app con gli utenti che Apple non è riuscita a identificare

"Chi saranno gli utenti di questa app?"

Adrien ha inviato la versione 1.0 e Apple ha interrotto la revisione sotto la linea guida 2.1, Informazioni necessarie. Non c'era un rapporto di crash, nessuna funzione rotta e nessuna richiesta di correzione binaria. Il solo blocco era che Apple voleva una risposta dettagliata spiegando chi l'app era per prima che la revisione potesse continuare.

App: Versione 1.0 dell'app iPad
Ritardo: La revisione è stata sospesa il 29 maggio 2026
Esito: Apple ha chiesto una spiegazione del target utente prima di continuare la revisione.

Messaggio di revisione di Apple App che dice che l'app di Adrien non differiva abbastanza da altre app

App Store di Apple Penoso Condiviso da Adrien

L'app che Apple ha deciso non era abbastanza diversa

"Ci sono già abbastanza di queste app sull'App Store."

Adrien ha ricevuto una rifiuto di Design - Spam perché Apple non ha visto abbastanza valore distintivo rispetto a simili app. La revisione ha detto che l'app era principalmente un'app per flatulenza o per borbottio, e anche se aveva funzionalità che la distinguevano, quella funzionalità era prominente abbastanza per Apple da trattare l'intera app come contenuto duplicato in una categoria saturata.

App: App di intrattenimento con suono
Ritardo: Rifiutato il 15 maggio 2026
Esito: L'Apple lo ha rifiutato in base alla linea guida 4.3(b), dicendo che l'app duplicava una categoria saturata.

Schermo guida di revisione dell'app utilizzato per rappresentare un flusso di lavoro di rifiuto dell'Apple App Store

Interfaccia di pubblicazione dell'App Store di Apple utilizzata per rappresentare una revisione ritardata di Apple

App Store di Apple Blocco di lancio

Il loop di metadati che ha mangiato la settimana di lancio

"Il build era buono. Il rifiuto continuava a spostarsi dall'app alle parole che circondavano l'app."

Il team ha spedito un build pulito, poi ha trascorso più di una settimana a ciclare attraverso le obiezioni dei metadati. Ogni rinvio ha risposto alla nota precedente, ma la prossima risposta si è concentrata su un'altra frase, screenshot o spiegazione. Nessun code è stato modificato. Il calendario di lancio, la finestra di stampa e il piano di acquisizione pagato sono stati tutti tenuti in ostaggio dalla copia di revisione.

App: App di produttività per i consumatori
Ritardo: 9 giorni
Esito: Approvato dopo aver rivisto le schermate, i sottotitoli e le note di revisione senza modifiche binarie.

Schermo di gestione della costruzione di App Store Connect rappresentante un blocco di rilascio post-approvazione

Schermo di conformità di App Store Connect rappresentante un ulteriore passaggio di revisione di conformità

Apple App Store Assurdo

Approvato, poi bloccato da un'altra domanda di conformità

"L'email di approvazione è arrivata prima del blocco."

The build è stato approvato, ma la release è ancora bloccata da un prompt di conformità che il team credeva già essere stato risposto. Il proprietario della release doveva fermare il rollout, raccogliere le parole d'ordine legali, aggiornare la risposta di App Store Connect, e aspettare nuovamente. I clienti hanno visto l'annuncio prima che l'app fosse effettivamente disponibile.

App: App di dashboard B2B
Ritardo: 4 giorni
Esito: Pubblicato dopo aver risposto nuovamente alla conformità degli esporti e aver aspettato la prossima revisione.

Schermo delle rilascia di Google Play Console rappresentante una rilascia bloccata

Schermo di caricamento dell'artifact di Google Play Console rappresentante sottmissioni Android ripetute

Schermo di salvataggio e pubblicazione di Google Play Console rappresentante una pubblicazione ritardata

Google Play Costoso

The time sink of the policy of permissions

"L'app necessitava la autorizzazione per una sola schermata, ma la revisione la trattava come tutto il prodotto."

Una autorizzazione Android ristretta ha scatenato una revisione della politica ampia. Il team ha documentato la funzionalità, ha aggiunto istruzioni per i revisori, ha registrato un percorso di demo e, tuttavia, ha dovuto rimuovere l'autorizzazione dalla versione principale per sbloccare i clienti. La versione finale è stata distribuita con un flusso di lavoro degradato mentre il team si preparava a una suddivisione più pulita delle autorizzazioni.

Applicazione: Applicazione di operazioni sul campo
Ritardo: 13 giorni
Esito: Approvato dopo aver rimosso un'autorizzazione, registrato un nuovo demo e rivisto la dichiarazione del negozio.

Interfaccia di app mobile rappresentante un hotfix in produzione in attesa di revisione del negozio

Schermo di conferma del console di Google Play rappresentante la pubblicazione di un hotfix ritardata Painful

La patch di emergenza che aspettava in coda alla coda di policy

"La cassa di checkout rotta era urgente per gli utenti, ma non urgente per la coda di revisione."

Un bug di cassa di checkout richiedeva una correzione rapida per dispositivi mobili, ma la versione di negozio di rilascio era entrata in revisione al momento peggiore.

App: App di e-commerce
Ritardo: 6 giorni
Esito: La correzione del negozio nativo arrivò dopo che il team aveva già mitigato l'incidente altrove.

Evita la prossima storia orribile

Consegna le correzioni urgenti con Capgo mentre i negozi prendono il loro tempo.

Capgo consente ai Capacitor team di inviare aggiornamenti in tempo reale, annullare le versioni rotte e targetizzare i canali senza dover attendere il ciclo di revisione completo di App Store o Google Play.

Inizia con Capgo Vedi aggiornamenti in tempo reale

Aggiungi una storia di rifiuto

Modifica i dati della storia, inclusi uno a cinque percorsi di immagini locali, e apri una PR. Mantieni i nomi anonimi a meno che tu non sia il proprietario della storia.

Modifica su GitHub