Quanto costa davvero un rifiuto dell'App Store

Mostrate 51 storie.

1. 

   4.3(a) Spam iOS Guideline 4.3

   Un intero portfolio segnalato in un colpo solo

   Cosa è successo

   Un developer con diverse app create dallo stesso progetto starter ha ricevuto lo stesso avviso 4.3 su ognuna di esse: le app condividevano binari, metadati o concept simili con differenze minime. Hanno deciso di procedere con le app una alla volta.

   Risoluzione

   Ancora in corso al momento della pubblicazione.

   Lezione

   La 4.3(a) riguarda anche la sovrapposizione tra le tue stesse app. Se diverse app derivano da un unico template, ognuna deve avere un core realmente distinto, non solo un nuovo nome e icona.

2. 

   4.3(a) Spam iOS Direttiva 4.3

   La stessa email due volte in una settimana

   Cosa è successo

   Una piccola app fotografica con un unico scopo è stata rifiutata per la 4.3(a) nel cuore della notte, una settimana dopo aver ricevuto lo stesso identico testo di rifiuto per una build precedente.

   Risoluzione

   Non specificata.

   Lezione

   Inviare di nuovo con modifiche cosmetiche raramente ribalta una decisione 4.3. Cambia il concept o spiega chiaramente nelle note di review cosa rende l'app diversa.

3. 

   4.3 Design / Spam iOS Linea guida 4.3

   Sviluppare in una categoria affollata

   Cosa è successo

   Un developer indie che documentava una challenge di build quotidiana ha ricevuto un rifiuto per la 4.3 Design / Spam al quarto giorno e ha iniziato a chiedersi se scegliere una categoria satura fosse stato un errore.

   Risoluzione

   Non specificata.

   Lezione

   Le categorie che Apple considera sature sono soggette a controlli più severi. Valuta cosa rende unica la tua app prima del build, non dopo la revisione.

5. 

   2.1 Informazioni necessarie iOS Linee guida 2.1

   Sette domande per un nuovo account

   Cosa è successo

   La prima submission di un team è stata respinta per "2.1 Informazioni necessarie": sette domande, una richiesta di screen recording e un account demo. Rispondere onestamente ha fatto emergere quattro dettagli che avevano trascurato.

   Risoluzione

   Hanno risolto i problemi e risposto.

   Lezione

   I nuovi account developer dovrebbero aspettarselo. Prepara un account demo, una registrazione e note di revisione chiare prima di inviare.

6. 

   2.1 Completezza dell'app iOS Linee guida 2.1

   Il revisore non è riuscito a usare l'app

   Cosa è successo

   Un nuovo sviluppatore è stato rifiutato due volte prima del rilascio. Il primo rifiuto, relativo alla 2.1, è avvenuto perché il revisore non riusciva a capire come utilizzare l'app.

   Risoluzione

   App approvata dopo aver aggiunto un video demo registrato su un dispositivo reale e note di revisione passo dopo passo.

   Lezione

   I revisori hanno pochi minuti e poco contesto. Spiega esattamente cosa cliccare e cosa dovrebbero vedere.

7. 

   Configurazione metadati e acquisti in-app iOS Metadati e IAP

   Due rifiuti per checkbox già note

   Cosa è successo

   Un developer indie è stato rifiutato due volte per errori già noti. Prima, la build è stata inviata senza gli acquisti in-app collegati e la descrizione non riportava il link ai termini d'uso. Settimane dopo, uno screenshot descriveva l'app come gratuita.

   Risoluzione

   Corretto e reinviato ogni volta.

   Lezione

   Tieni una checklist pre-invio per metadati, abbonamenti e link legali. La maggior parte dei rifiuti sui metadati è evitabile.

8. 

   Tempi della coda di revisione iOS Revisioni infinite

   9 giorni di attesa, poi 8 in revisione

   Cosa è successo

   Un developer ha aspettato nove giorni che lo stato passasse da Waiting for Review a In Review, per poi rimanere in revisione per altri otto giorni senza alcun aggiornamento.

   Risoluzione

   Nessuno al momento della pubblicazione.

   Lezione

   I tempi di revisione non sono garantiti. Non legare mai una data di lancio, comunicati stampa o campagne creator a una data di approvazione prevista.

9. 

   Tempi della coda di revisione iOS Revisioni infinite

   20 giorni tra rifiuti, fix e attesa

   Cosa è successo

   Per oltre 20 giorni, uno sviluppatore è rimasto intrappolato tra rifiuti, fix e attesa della revisione, ed era ancora in attesa al momento della pubblicazione.

   Risoluzione

   In attesa.

   Lezione

   Ogni ciclo può costare giorni. Raggruppa ogni fix derivante da una nota di rifiuto in un unico build.

10. 

    Chiusura dell'account iOS Chiusura dell'account

    Chiuso prima della prima revisione

    Cosa è successo

    Un developer con dieci anni di esperienza si è visto chiudere l'account da developer con un'accusa di frode che non spiegava cosa avesse fatto, mentre un gioco per l'apprendimento delle lingue era ancora in attesa della primissima revisione. Le app già esistenti sono sparite e i clienti hanno iniziato a chiedere il perché.

    Risoluzione

    Nessuna segnalazione.

    Lezione

    La chiusura di un account rimuove tutte le app contemporaneamente. Mantieni un tuo canale diretto con gli utenti (email, sito web) per poterli contattare se lo store dovesse sparire.

11. 

    Avviso di chiusura dell'account iOS Chiusura dell'account

    Troppe versioni rifiutate

    Cosa è successo

    Un prolifico sviluppatore indie ha ricevuto un avviso: il suo account sarebbe stato chiuso entro dieci giorni. Apple ha indicato che l'alto numero di versioni rifiutate era tra le cause principali. Dopo l'attenzione pubblica e un ricorso, l'account non è stato chiuso.

    Risoluzione

    Account salvato dopo il ricorso.

    Lezione

    I rifiuti si accumulano. Evita di inviare nuovamente l'app lo stesso giorno con modifiche minime o versioni quasi identiche delle tue app.

12. 

    Requisito di login (numero guideline non specificato) iOS Requisito di login

    Registrazione obbligatoria: non sei una big app

    Cosa è successo

    L'app social di un developer è stata rifiutata perché richiedeva la creazione di un account prima di accedere al feed. Quando il developer ha spiegato che ogni utente necessita di un nickname per il funzionamento dell'app, citando un noto social network che fa lo stesso, il revisore ha risposto, in sostanza, che la loro app non era quel network.

    Risoluzione

    Non specificata.

    Lezione

    Ciò che le grandi app riescono a fare non è un precedente da citare. Se richiedi la registrazione, spiega nelle note di revisione perché la funzione principale non può operare senza un account, e valuta di permettere ai revisori o agli ospiti di visualizzare parte dei contenuti inizialmente.

13. 

    4.3 Spam iOS Linea guida 4.3

    Da nessuna revisione a quasi tutto rifiutato

    Cosa è successo

    Un developer ha visto le proprie app non venire revisionate per giorni. Durante l'attesa di circa una settimana, ha inviato altre submission. Quando la revisione è finalmente ripartita, quasi tutte sono state rifiutate per la guideline 4.3 spam.

    Risoluzione

    Non specificata.

    Lezione

    Una coda ferma non è un segnale per inviare altro. Accumulare submission mentre nulla viene revisionato può far sembrare il tuo account un pattern di spam non appena un reviewer le vedrà tutte insieme.

14. 

    4.3 Spam iOS Linea guida 4.3

    App non correlate rifiutate insieme

    Cosa è successo

    Un developer aveva diverse app, sviluppate in mesi diversi e non correlate tra loro, tutte rifiutate come spam nello stesso momento. Ha chiesto pubblicamente se fosse normale.

    Risoluzione

    Non specificata.

    Lezione

    La regola 4.3 può essere applicata a livello di account, non singola app. Se diverse app vengono rifiutate insieme, rispondi a ciascuna separatamente e specifica nelle note di revisione cosa rende ogni app distinta.

15. 

    Tempi della coda di revisione iOS Revisioni infinite

    Un rifiuto, poi due mesi di silenzio

    Cosa è successo

    Dopo un singolo rifiuto, l'app di uno sviluppatore è rimasta in revisione per circa due mesi, con ogni ciclo di revisione lungo quasi un mese. Sospettavano che i cicli lunghi fossero diventati un modo per limitare l'ingresso di nuove app.

    Risoluzione

    Ancora bloccato al momento del post.

    Lezione

    Dopo un rifiuto, il ciclo successivo può essere molto più lento del primo. Assicurati che la nuova sottomissione sia completa e ben documentata, per evitare di perdere un altro mese in un secondo round.

16. 

    Contenuti inaccettabili iOS Contenuti inaccettabili

    Rifiutato per invio senza correzioni

    Cosa è successo

    Un'app di editing foto con AI è stata rifiutata perché inviata più volte senza risolvere il problema segnalato da Apple, ovvero la presenza di contenuti inaccettabili.

    Risoluzione

    Rifiutato.

    Lezione

    Rinviare lo stesso build sperando in un revisore diverso può penalizzarti. Risolvi il problema segnalato o chiedi chiarimenti tramite il Resolution Center prima di riprovare. Per le funzioni di AI generativa, aggiungi filtri per i contenuti che Apple considera inaccettabili.

17. 

    4.3 Spam iOS Linea guida 4.3

    Rifiutata al primo minuto della revisione

    Cosa è successo

    Un developer ha passato settimane a sviluppare un'app, che è stata rifiutata per spam (4.3) proprio nel minuto in cui è entrata in revisione. Secondo lui, il revisore ha giudicato la nicchia, non l'app.

    Risoluzione

    Non specificata.

    Lezione

    Nelle nicchie affollate, un rifiuto 4.3 può arrivare prima ancora di un'analisi approfondita. Inizia le note di revisione evidenziando ciò che rende l'app unica, guidando il revisore direttamente lì.

18. 

    4.2.6 Template iOS Guideline 4.2.6

    Segnalato per un template mai utilizzato

    Cosa è successo

    Un team è stato rifiutato secondo la guideline 4.2.6, che riguarda le app create da template commerciali o servizi di generazione app, nonostante non avessero usato alcun template o servizio di generazione.

    Risoluzione

    Non specificata.

    Lezione

    La 4.2.6 può essere un falso positivo. Rispondi nel Resolution Center spiegando chiaramente che l'app è sviluppata su misura, chi l'ha creata e offriti di mostrare il codice o la cronologia dello sviluppo.

19. 

    3.1.2 Abbonamenti iOS Linee guida 3.1.2

    Il prezzo mensile era superiore a quello fatturato

    Cosa è successo

    Il paywall di uno sviluppatore è stato rifiutato perché mostrava il prezzo mensile calcolato di un abbonamento a lungo termine in modo più evidente rispetto all'importo effettivamente fatturato. Lo stesso paywall era passato in revisioni precedenti senza problemi. Lo sviluppatore concordava con la regola, ma era frustrato dal fatto che fosse stato segnalato solo ora, quindi ha ridisegnato il paywall mettendo in risalto l'importo fatturato.

    Risoluzione

    Inviato nuovamente con il nuovo design.

    Lezione

    Un paywall approvato in precedenza può essere rifiutato in seguito. Rendi sempre l'importo e il periodo di fatturazione i prezzi più evidenti; mostra eventuali suddivisioni mensili in modo più piccolo e secondario.

20. 

    Enrollment (non è una linea guida di App Review) Apple Developer Program Enrollment e account

    Due mesi, poi un rifiuto senza motivo

    Cosa è successo

    Un developer ha passato oltre due mesi a cercare di completare l'enrollment, tra chiamate al supporto, email, verifica dell'identità, dettagli del dispositivo e persino prove video. Apple ha poi rifiutato l'enrollment senza fornire una motivazione specifica.

    Risoluzione

    Nessuna al momento della pubblicazione.

    Lezione

    L'enrollment può richiedere molto più tempo dello sviluppo dell'app. Inizia l'enrollment in anticipo, prima che il tuo piano di lancio ne dipenda, e tieni traccia di ogni scambio con il supporto.

21. 

    5.1.2 Utilizzo e condivisione dei dati iOS Linee guida 5.1.2

    Un rifiuto per App Tracking Transparency che ha messo in crisi una startup

    Cosa è successo

    Dopo mesi di rilasci rapidi e ottimi feedback dagli utenti, l'app di una startup è stata rifiutata in tardo autunno per via dell'App Tracking Transparency, la regola sulla privacy di iOS che richiede il consenso dell'utente prima di tracciarlo tra diverse app e siti web. Il fondatore l'ha descritta come un rifiuto che ha messo a rischio l'intera azienda.

    Risoluzione

    Non specificato nel post.

    Lezione

    Controlla ogni SDK della tua app per il tracking prima dell'invio. Se qualcosa collega i dati dell'utente con quelli di altre aziende, serve il prompt per il consenso al tracking e le relative privacy label, anche se il tracking proviene da una libreria di terze parti.

22. 

    Login (numero di linea guida non indicato) iOS Accedi

    Il reviewer non è riuscito ad accedere con Apple o Google

    Cosa è successo

    Per fermare le registrazioni da bot, uno sviluppatore ha rimosso il login con email e password, mantenendo solo Sign in with Apple e Google Sign-In. Funzionava sul suo iPhone e iPad, e persino per il reviewer precedente, che aveva rifiutato l'app per un altro motivo. Il reviewer successivo l'ha rifiutata perché non riusciva ad accedere.

    Risoluzione

    Non specificata.

    Lezione

    Se la tua app offre solo il social login, i reviewer possono comunque restare bloccati. Fornisci loro un percorso funzionante nelle note di revisione, ad esempio un account demo o un login solo per la review, e testa l'accesso su un dispositivo e un account nuovi prima di ogni submission.

23. 

    Gioco d'azzardo simulato (numero di linea guida non indicato) iOS Gioco d'azzardo simulato

    Una funzione di staking in-game su un account individuale

    Cosa è successo

    Un gioco è stato rifiutato per la presenza di gioco d'azzardo simulato: i giocatori potevano scommettere oggetti di gioco tra di loro, una meccanica comune nei classici RPG online. Poiché lo sviluppatore pubblicava con un account individuale invece che aziendale, ha deciso di rimuovere la funzione per il momento.

    Risoluzione

    Rimozione della funzione e nuova sottomissione.

    Lezione

    Le meccaniche simili al gioco d'azzardo sono soggette a controlli extra anche senza soldi veri, e ciò che Apple permette dipende dal tipo di account e dalla documentazione. Controlla le regole sul gambling prima di implementare funzioni di staking, loot o scommesse, e pianifica il tipo di account developer di conseguenza.

24. 

    Documenti falsi (numero guideline non specificato) iOS Documenti falsi

    Un editor PDF accusato per le azioni degli utenti

    Cosa è successo

    Un'app editor PDF è stata rifiutata perché Apple sosteneva che permettesse di creare ID e documenti falsi. Lo sviluppatore ha ribattuto che, con la stessa logica, qualsiasi app bancaria o di messaggistica potrebbe essere rifiutata per l'uso improprio che ne fanno i malintenzionati.

    Risoluzione

    Non specificata.

    Lezione

    Gli strumenti general-purpose possono essere giudicati in base al loro peggior uso possibile. Evita template o marketing che sembrino ID o certificati ufficiali, e spiega nelle note di revisione a cosa serve l'app e cosa non supporta.

25. 

    Condivisione dati AI (numero della linea guida non indicato) iOS Condivisione dati AI

    No consent screen for third party AI data sharing

    Cosa è successo

    Un team ha ricevuto il primo rifiuto per aver condiviso dati utente con un provider AI di terze parti. Apple richiedeva il consenso esplicito degli utenti e un'informativa chiara su quali dati vengono inviati e a quale provider AI. La preoccupazione del team era realizzare una schermata di consenso che superasse la review senza penalizzare le conversioni.

    Risoluzione

    In corso.

    Lezione

    Se la tua app invia contenuti degli utenti a un servizio AI esterno, chiedi il consenso prima della prima richiesta e indica il provider e i dati coinvolti. Realizza quella schermata prima dell'invio, non dopo il rifiuto.

26. 

    Entitlement Family Controls (numero della linea guida non indicato) iOS Metadati e IAP

    Cinque rifiuti per una singola spunta mancante

    Cosa è successo

    Uno sviluppatore che stava pubblicando un'app simile a Screen Time è stato rifiutato cinque volte. Le note di revisione vaghe lo avevano portato a pensare che il problema fosse il design. La vera causa era un'impostazione di Family Controls non attivata nel setup developer. Una volta selezionata, l'app è stata approvata.

    Risoluzione

    Approvata dopo aver abilitato l'impostazione Family Controls e aver effettuato il resubmit.

    Lezione

    Quando le note di rifiuto sono vaghe, controlla entitlement e certificati prima di ridisegnare il prodotto. Le app tipo Screen Time e Family Controls richiedono la relativa capability abilitata nel developer portal, non solo in Xcode.

27. 

    Guideline 5.1.1(v) iOS Direttiva 5.1.1 Requisito di login

    Account richiesta per una feature a pagamento eseguita sul dispositivo

    Cosa è successo

    Uno sviluppatore web è stato rifiutato per la guideline 5.1.1(v). Sul web, gli acquisti erano sempre legati a un account. Su iOS, Apple gestisce l'acquisto, quindi gli utenti possono pagare senza registrarsi. Il suo piano premium sbloccava dei filtri che giravano solo sul telefono, ma sia lo sblocco che il Restore degli acquisti richiedevano comunque la creazione di un account.

    Risoluzione

    Ristrutturazione del codice per far sì che un acquisto effettuato senza account venga riconosciuto dopo un eventuale sign up. Lavoro in corso al momento del post.

    Lezione

    Se una feature a pagamento gira sul dispositivo e non richiede un'identità lato server, permetti l'acquisto e il restore senza account. Riserva il sign up solo per funzioni che ne hanno davvero bisogno, come il backup cloud.

28. 

    Direttiva 1.4.2 Danni Fisici iOS Direttiva 1.4.2

    App per il calcolo del dosaggio rimosse in un crackdown sulle regole

    Cosa è successo

    Un developer si è svegliato trovando due delle sue app segnalate per la direttiva 1.4.2, nonostante non avesse nulla in fase di review. Entrambe erano già live: un calcolatore di dosaggio peptidico standalone e un tracker con lo stesso calcolatore integrato, che insieme avevano rappresentato il loro primo vero successo economico. Altri developer nella stessa nicchia hanno ricevuto lo stesso avviso contemporaneamente. Il messaggio specificava che le app che calcolano dosaggi di farmaci, inclusi dosaggi e ricostituzione di peptidi, devono essere pubblicate dal produttore del farmaco o da un'istituzione riconosciuta come ospedali, assicurazioni, farmacie o università.

    Risoluzione

    Nessuna. Il developer ha dichiarato di aver compreso le preoccupazioni sulla sicurezza e ha accettato la chiusura di quelle app.

    Lezione

    L'approvazione non è permanente. Apple può rivalutare un'app live quando stringe una regola. Se la tua app calcola dosaggi o fornisce indicazioni sulla salute che potrebbero causare danni, leggi la direttiva 1.4 prima di iniziare il build, e pianifica di pubblicare tramite un'istituzione qualificata o evita di includere il calcolo.

29. 

    Linee guida 4.3 Spam e 4.2.6 Servizi di generazione app iOS Linea guida 4.3 Linee guida 4.2.6

    Un'app di ticketing offline scambiata ancora per spam

    Cosa è successo

    Uno sviluppatore ha creato una piccola app che trasforma un foglio di calcolo in un sistema di ticketing e check-in completamente offline, senza account né abbonamento. Durante l'estate, l'app ha già gestito l'ingresso a un evento locale con diverse centinaia di partecipanti. Apple l'ha rifiutata nuovamente con una notifica combinata 4.3 e 4.2.6, sostenendo che potrebbe duplicare app già presenti sullo store, essere una variante opportunistica di una categoria affollata o derivare da un template o da un servizio di generazione app. Lo sviluppatore ha dichiarato di non conoscere altre app con le stesse funzioni e che la versione Android era online da circa una settimana.

    Risoluzione

    Rifiutata ancora al momento della pubblicazione. Lo sviluppatore ha precisato che, in ogni caso, non intendeva trarne profitto dall'App Store.

    Lezione

    Un revisore della 4.3 vede la tua scheda e pochi minuti dell'app, non i tuoi utenti reali. Se l'app è autenticamente diversa, spiega esattamente come nelle note di revisione e nei primi screenshot, menziona l'uso nel mondo reale e dichiara chiaramente di non aver usato template o generatori di app.

30. 

    Guideline 5.6.4 Qualità dell'app Apple Developer Program Direttiva 5.6.4

    Payout congelati per l'aumento del tasso di rimborso

    Cosa è successo

    Un developer con un'app in abbonamento in forte crescita si è svegliato con un avviso da Apple: il suo account violava il Code di condotta secondo la guideline 5.6.4, App Quality. La notifica segnalava un numero eccessivo di rimborsi e reclami, avvertendo che l'account poteva essere chiuso e che tutti i pagamenti erano sospesi e i trasferimenti app disabilitati. Il tasso di rimborso era quasi raddoppiato negli ultimi due mesi. Analizzando i dati, la maggior parte dei rimborsi era classificata come acquisto non intenzionale, probabilmente dovuto a utenti che dimenticavano di annullare la prova gratuita di 3 giorni prima del rinnovo annuale. L'avviso è arrivato proprio mentre un grande redesign dell'app era in fase di testing.

    Risoluzione

    La pratica era ancora aperta al momento del post. Il developer ha aggiunto più reminder durante la prova, ha reso più chiaro il prossimo addebito, ha inserito la gestione dell'abbonamento nell'app, ha completato il redesign con più test e ha sospeso il marketing a pagamento in attesa di risoluzione.

    Lezione

    Apple monitora i tassi di rimborso e i reclami, non solo il tuo binario. Una prova gratuita che si trasforma silenziosamente in un abbonamento annuale può causare problemi di acquisti non intenzionali su larga scala. Ricorda agli utenti la scadenza della prova, mostra chiaramente il prezzo reale, rendi facile la cancellazione e considera l'aumento dei rimborsi come un rischio per l'account molto prima che lo faccia Apple.

31. 

    Configurazione metadati e acquisti in-app iOS Metadati e IAP

    Rifiutata tre volte per un'immagine che la console non riusciva a eliminare

    Cosa è successo

    Un developer ha aggiunto un'immagine promozionale a un abbonamento in App Store Connect, finendo accidentalmente per caricarla due volte. Da quel momento, l'immagine non poteva essere eliminata o sostituita: ogni tentativo falliva con un errore generico che invitava a riprovare più tardi. L'app è stata rifiutata tre volte a causa di quella configurazione. Ogni volta, il developer ha risposto inviando una screen recording del tentativo di eliminazione e dell'errore, ma sembrava che il reviewer lo ignorasse sistematicamente. Il developer è convinto che la causa principale sia un bug di App Store Connect.

    Risoluzione

    Ancora bloccati in fase di pubblicazione, senza alcuna soluzione da parte di Apple.

    Lezione

    Quando App Store Connect blocca la soluzione, una risposta nel thread del rifiuto potrebbe non arrivare a chi può risolvere il problema. Carica le immagini degli abbonamenti con cura e una sola volta; se la console si rompe, contatta separatamente l'assistenza sviluppatori Apple per il bug mentre rispondi ad App Review.

32. 

    Linee guida 4.3 Spam iOS Linea guida 4.3

    Tre rifiuti per un'app creata per gestire una palestra

    Cosa è successo

    Uno sviluppatore ha creato un'app iOS per la propria palestra, con circa centosettantasei commit di lavoro. Apple l'ha rifiutata il 29 settembre, di nuovo il 7 ottobre e il 13 ottobre per la linea guida 4.3 Spam. Lo stesso giorno ha risposto a tutte le nove domande inviate da App Review. Sei giorni dopo, il 19 ottobre, non aveva ricevuto notizie. La lista delle app su App Store Connect mostrava altre app sullo stesso account anch'esse in stato di rifiuto, sia su iOS che su macOS.

    Risoluzione

    Ancora aperto al momento della pubblicazione, senza alcuna risposta da App Review dopo l'invio delle risposte.

    Lezione

    L'impegno e il numero di commit non sono ciò che la linea 4.3 valuta. Se un'app è creata per un singolo business, un'app non elencata può restare fuori dalle ricerche pur essendo accessibile tramite link diretto; la distribuzione Custom App limita l'accesso a organizzazioni specifiche. Scegli l'opzione che meglio gestisce il controllo degli accessi. Per un rilascio pubblico, rendi evidenti le differenze rispetto alle app esistenti nelle prime schermate, negli screenshot e nelle note di revisione.

33. 

    Linee guida 5.6 Developer Code of Conduct e 2.5.19 Hidden Features iOS Linee guida 5.6 Developer Code of Conduct Linee guida 2.5.19 Hidden Features

    Rifiutata per frode a causa di switch di test rimasti attivi

    Cosa è successo

    A settembre 2026, un developer ha visto la propria app iOS rifiutata per la linea guida 5.6 Developer Code of Conduct. Apple ha dichiarato di aver riscontrato un pattern di comportamento associato alle frodi, nello specifico funzionalità che sembravano essere state deliberatamente nascoste durante la review. Il developer ha risalito al problema a tre switch di test rimasti nel release build: una modalità per scattare screenshot per lo store, uno switch che simulava un controllo lento delle autorizzazioni e uno switch per sbloccare acquisti mock. Nessuno di questi era raggiungibile dagli utenti normali della versione App Store. Nell'aggiornamento delle App Review Guidelines di Apple del 16 ottobre, le funzionalità nascoste, dormienti o non documentate sono diventate una linea guida specifica, la 2.5.19, e Apple avverte che violarla può mettere a rischio l'intero account developer.

    Risoluzione

    Ora lo sviluppatore controlla le stringhe in ogni archivio di rilascio prima dell'upload. Non è stato specificato se quel build sia stato poi approvato.

    Lezione

    Escludi i code di solo test dai release build durante la compilazione, ad esempio usando i flag DEBUG, invece di affidarti a un controllo a runtime. Verifica cosa viene effettivamente incluso nel binario archiviato e indica ogni switch nelle note di App Review.

34. 

    2.1 Informazioni necessarie iOS Linee guida 2.1

    Review in pausa finché Apple non ha chiarito il target dell'app

    Cosa è successo

    Uno sviluppatore ha inviato la versione 1.0 di un'app per iPad e la revisione si è bloccata per la Guideline 2.1, Information Needed. Non c'erano crash report, funzionalità rotte o richieste di fix al binario. Apple voleva solo una risposta dettagliata a una domanda prima di procedere: chi userà questa app.

    Risoluzione

    Apple ha richiesto una spiegazione sul target di utenti prima di procedere con la revisione.

    Lezione

    Considera il pubblico e il caso d'uso come requisiti per la revisione, non come copy di marketing da scrivere dopo. Prepara una risposta chiara sul target prima di inviare la prima versione.

35. 

    4.3 Design / Spam iOS Linea guida 4.3

    Differenze insufficienti in una categoria di app per suoni già satura

    Cosa è successo

    Un'app di suoni per l'intrattenimento è stata rifiutata secondo la Guideline 4.3(b). Apple ha dichiarato che lo store è già saturo di app simili, trattando il prodotto come contenuto duplicato in una categoria affollata, nonostante il team ritenesse che le funzionalità extra lo rendessero unico.

    Risoluzione

    Rifiutata per la 4.3(b): scarsa differenziazione in una categoria satura.

    Lezione

    Nelle categorie definite 'sature' da Apple, la novità deve emergere subito durante la revisione. Punta su ciò che è unico, non su un gimmick che i revisori hanno già visto mille volte.

36. 

    Metadata e store listing copy iOS Metadati e IAP Revisione infinita

    The metadata loop that ate launch week

    Cosa è successo

    Un team di produttività consumer ha rilasciato un build pulito, per poi passare oltre nove giorni tra rifiuti di metadati. Ogni nuova sottomissione rispondeva al commento precedente, ma la risposta successiva si concentrava su un'altra frase, uno screenshot o una spiegazione. Nessun code è cambiato, mentre i piani di lancio, pressione e acquisizione a pagamento restavano in attesa della revisione.

    Risoluzione

    Approvato dopo aver riscritto screenshot, sottotitoli e note di revisione senza alcuna modifica al binario.

    Lezione

    Blocca testi, screenshot e note di revisione in un colpo solo prima di fissare la data di lancio. I rifiuti dei metadati possono accumularsi anche se il binario non cambia mai.

37. 

    Conformità sull'esportazione (App Store Connect) iOS Metadati e IAP

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

    Cosa è successo

    Il rilascio di una dashboard B2B è stato bloccato quando è riapparso un prompt di compliance, nonostante il team pensasse di aver già risposto alle domande sull'export. Il responsabile ha fermato il rollout, raccolto i testi legali, aggiornato la risposta su App Store Connect e atteso un nuovo passaggio di revisione, mentre i clienti vedevano l'annuncio prima ancora che l'app fosse disponibile.

    Risoluzione

    Rilasciato dopo aver confermato nuovamente la compliance sull'export e aver atteso il completamento della revisione.

    Lezione

    Gestisci la compliance sull'export come un gate di rilascio, non come una semplice spunta da fare una volta. Verifica che App Store Connect mostri uno stato pronto per il rilascio prima di annunciare una data di uscita.

38. 

    Permessi di Google Play e revisione delle policy Google Play Metadati e IAP Revisione infinita

    Il calvario delle policy sui permessi

    Cosa è successo

    Un'app Android per operazioni sul campo ha scatenato una revisione completa delle policy a causa di un singolo permesso usato in una sola schermata. Il team ha documentato la feature, aggiunto istruzioni per i revisori e registrato un video demo, ma ha comunque dovuto rimuovere il permesso dal rilascio principale per sbloccare i clienti dopo tredici giorni.

    Risoluzione

    Approvata dopo aver rimosso il permesso, registrato una nuova demo e riscritto la dichiarazione sullo store.

    Lezione

    Limita i permessi sensibili alla superficie minima possibile al primo rilascio. Un singolo permesso può trasformarsi in una revisione completa delle policy su Google Play.

39. 

    Tempi di coda della revisione su Google Play Google Play Revisioni infinite

    L'hotfix rimasto bloccato in coda per la revisione

    Cosa è successo

    Un team e-commerce aveva bisogno di un fix rapido per un bug nel checkout, ma il rilascio sullo store è rimasto in revisione per sei giorni nel momento peggiore. I ticket di supporto aumentavano mentre lo stato restava in attesa. Hanno prima mitigato il problema lato server, per poi vedere l'approvazione del binario arrivare quando l'emergenza era già passata dopo un intero weekend.

    Risoluzione

    Il fix nativo è arrivato solo dopo che il team aveva già mitigato l'incidente altrove.

    Lezione

    La revisione degli store non è un canale di incident response. Mantieni un percorso di mitigazione alternativo per i bug urgenti in produzione mentre il binario è in coda.

40. 

    Linee guida 3.1.1 In-App Purchase e 3.1.3(f) Free Stand-alone Apps iOS Linee guida 3.1.1 Direttiva 3.1.3

    App companion rifiutata perché la prova scade

    Cosa è successo

    Uno sviluppatore ha rilasciato un'app companion gratuita per iOS per il suo servizio email a pagamento basato su web. L'app non vendeva nulla al suo interno. Ha indicato al team di App Review l'eccezione 3.1.3(f) per le app companion gratuite e stand-alone, ma l'app è stata rifiutata quattro volte. Ha presentato ricorso, ma l'App Review Board ha confermato il rifiuto. La motivazione era che il servizio offriva una prova gratuita di 14 giorni, quindi per un utente iOS l'app smetteva di essere utile dopo 14 giorni e non rappresentava una vera esperienza stand-alone. Apple ha proposto due soluzioni: fornire all'app abbastanza contenuti e funzionalità gratuite per renderla autonoma, oppure permettere agli utenti dell'App Store di acquistare il servizio tramite In-App Purchase. Lo sviluppatore ha fatto notare che una nota app di email sembrava fare la stessa cosa con un limite di 14 giorni.

    Risoluzione

    Ancora irrisolto al momento della pubblicazione. Il ricorso è stato respinto e lo sviluppatore stava valutando se offrire un piano gratuito limitato o aggiungere gli In-App Purchase.

    Lezione

    L'eccezione per le app companion 3.1.3(f) viene interpretata in modo restrittivo. Se il tuo servizio web ha una prova a tempo limitato, Apple potrebbe considerare l'app come un paywall mascherato una volta terminata la prova. Prima di sottoporre l'app, decidi cosa l'utente può ancora fare gratuitamente dopo la prova, oppure pianifica l'integrazione di In-App Purchase. Citare altre app che sembrano fare lo stesso raramente aiuta a vincere un ricorso.

41. 

    Guideline 3.1.1 In-App Purchase iOS Direttiva 3.1.1

    La propria chiave API considerata un pagamento fuori dall'App Store

    Cosa è successo

    Uno sviluppatore singolo che creava un assistente AI per iPhone lasciava incollare agli utenti la propria chiave API di un aggregatore di modelli di terze parti, per far girare modelli cloud di grandi dimensioni. Al quarto round di review, App Review ha rifiutato l'app secondo la guideline 3.1.1, trattando l'opzione bring your own key come un modo per pagare funzionalità fuori dall'App Store. Da quanto lo sviluppatore ha capito del rifiuto, una chiave acquistata altrove può sbloccare funzionalità a pagamento nell'app solo se quel venditore offre In-App Purchase nella propria app iOS, e questo provider non ha un'app iOS. Lo sviluppatore non ha presentato ricorso.

    Risoluzione

    Ha rimosso del tutto la funzione bring your own key, ha ricostruito la versione successiva per far girare i modelli interamente on-device e aveva in programma di riportare i modelli cloud più avanti come crediti in-app venduti tramite In-App Purchase. L'esito di quella nuova sottomissione non era noto al momento della scrittura.

    Lezione

    Se le funzionalità a pagamento della tua app si sbloccano con credenziali acquistate altrove, verifica prima di iniziare a sviluppare se quel venditore offre In-App Purchase nella propria app iOS. In caso contrario, prevedi un tuo flusso In-App Purchase o una modalità che funzioni senza.

42. 

    Direttiva 1.2 iOS Direttiva 1.2

    Un confronto tra outfit rifiutato perché indicava un vincitore

    Cosa è successo

    Un singolo sviluppatore ha rilasciato un'app AI che confronta due outfit. Dopo il confronto, l'app annunciava quale look avesse vinto. L'App Review l'ha rifiutata secondo la linea guida 1.2, interpretando il risultato come una classifica di persone anziché di vestiti. Lo sviluppatore ha condiviso la preoccupazione.

    Risoluzione

    Hanno rimosso ogni riferimento al vincitore, il badge del winner e qualsiasi punteggio elevato o colore di evidenziazione, così entrambi i look hanno ora lo stesso peso visivo, ognuno riceve il proprio feedback e l'utente decide. Non è stato comunicato se la nuova build sia stata approvata.

    Lezione

    Apple valuta la percezione di una schermata, non solo la sua funzione. Se la tua app assegna punteggi legati all'aspetto delle persone, presenta il feedback senza classifiche e prevedi l'interpretazione più severa.

43. 

    Categoria Kids, Linea Guida 3.1.2 e questioni sulla privacy iOS Categoria Kids Direttiva 3.1.2 Revisione infinita

    Un'app di storie per bambini ancora in attesa dopo un mese di rifiuti

    Cosa è successo

    Un developer indipendente ha creato un'app di storie per bambini dai 4 ai 10 anni, in cui i bambini ascoltano storie e possono mettere in pausa per fare domande. L'app era già online su Android da settimane. È stata inviata all'App Store il 19 settembre 2026. Dopo diversi round di rifiuti e nuovi invii, circa un mese dopo non era ancora stata approvata. Nell'ultimo round Apple ha chiesto due cose: poiché l'app vende abbonamenti settimanali, mensili e annuali, la pagina dell'App Store doveva avere un link funzionante ai Termini di utilizzo; e poiché l'app è nella categoria Kids, la revisione non poteva proseguire finché il developer non avesse risposto a quattro domande su analytics di terze parti, pubblicità di terze parti, se i dati vengono condivisi con terzi e dove sono archiviati, e se vengono raccolti altri dati di utenti o dispositivi e per quali scopi.

    Risoluzione

    Il developer ha risolto entrambi i problemi e ha inviato di nuovo. Al momento della pubblicazione l'esito era ancora in sospeso.

    Lezione

    Per app per bambini, salute, finanza o istruzione, scopri in anticipo cosa chiederanno le leggi locali sulla privacy e gli store, ad esempio il consenso dei genitori prima di raccogliere i dati di un minore, e prepara il link ai Termini di utilizzo e una risposta scritta sui dati prima del primo invio.

44. 

    Guideline 5.1.1(v) e 3.1.2 iOS Linea guida 5.1.1 Direttiva 3.1.2

    Versione 1.0 rifiutata per i flussi di login, acquisto e cancellazione

    Cosa è successo

    La versione 1.0 di uno sviluppatore è stata rifiutata per tre problemi contemporaneamente, nessuno dei quali riguardava l'idea dell'app. Dopo il Sign in with Apple, l'app chiedeva ancora all'utente il nome che Sign in with Apple aveva già fornito. La cancellazione dell'account doveva poter essere avviata dall'interno dell'app. La schermata di abbonamento e supporto doveva mostrare il prezzo, i termini di rinnovo e un link ai Termini. La lezione appresa dallo sviluppatore è che tutti e tre i problemi riguardavano il login, l'acquisto e la cancellazione.

    Risoluzione

    Non specificata.

    Lezione

    Prima della prima submission, testa i flussi di login, acquisto e cancellazione account come un reviewer. Questi tre flussi causano molti rifiuti iniziali.

45. 

    Guideline 5.2.3 Download Audio/Video iOS Guideline 5.2.3 Download Audio/Video

    Radio internet vintage rifiutata per diritti audio di terze parti

    Cosa è successo

    L'app radio internet di un singolo developer con look vintage, alla versione 1.0 del quinto build, è stata rifiutata per la guideline 5.2.3. Questa norma riguarda le app che riproducono o scaricano audio e video da fonti terze e richiede la prova che il developer abbia i diritti su tali contenuti. Il giorno successivo, il developer ha risposto nel Resolution Center spiegando la situazione sui diritti.

    Risoluzione

    Esito non ancora noto al momento della pubblicazione.

    Lezione

    Se la tua app trasmette stazioni o media di cui non sei il proprietario, raccogli le autorizzazioni o usa fonti i cui termini permettano esplicitamente il playback nell'app, e includi la documentazione nelle note di revisione prima dell'invio.

46. 

    Linee guida 4.3 (Spam) iOS Linea guida 4.3

    Sei rifiuti, un'etichetta spam 4.3 e due settimane di attesa per una chiamata

    Cosa è successo

    Un developer indipendente ha lavorato mesi alla sua prima app, pensata come rompighiaccio per contesti sociali. È stata rifiutata sei volte, l'ultima per la Guideline 4.3 (spam), nonostante il dev ritenesse che offrisse molto più delle app simili già presenti sullo store. Ha chiesto ad App Review una chiamata dedicata. È passata una settimana senza risposta, e la chiamata è avvenuta solo due settimane dopo il rifiuto 4.3. Il developer è uscito dalla chiamata con l'impressione che la 4.3 venga ora usata per segnalare app che sembrano cloni generati da AI con poco sforzo, cosa che la sua app non era.

    Risoluzione

    Il developer ha presentato ricorso. Al momento della scrittura, la pratica è ancora in sospeso.

    Lezione

    In una categoria affollata, il revisore valuta screenshot, descrizione e prima sessione. Rendi evidente la differenza rispetto alle app esistenti e richiedi subito una chiamata ad App Review, perché ottenerne una può richiedere una settimana o più.

47. 

    Accordo non accettato (nessuna linea guida citata) iOS Iscrizione e account

    Una settimana in coda, rifiuto per un accordo non firmato, poi un'altra settimana

    Cosa è successo

    Un'app è rimasta in attesa di revisione per circa una settimana, per poi essere rifiutata senza alcun motivo interno all'app. L'account non aveva ancora accettato un nuovo accordo pubblicato su App Store Connect. Il developer lo ha accettato e ha effettuato il resubmit, ma la submission è tornata in coda per circa un'altra settimana. Il supporto developer ha risposto solo che tutto procedeva regolarmente.

    Risoluzione

    Al momento della scrittura, l'app è ancora in attesa di revisione.

    Lezione

    Prima di ogni submission, controlla su App Store Connect se ci sono accordi in attesa di accettazione. Un click mancato può costarti un intero ciclo di revisione.

48. 

    Crash durante la review (linea guida non specificata) macOS Direttiva 2.1

    Rifiutata per un crash su una versione di macOS non installata dallo sviluppatore

    Cosa è successo

    Un'app Mac è stata rifiutata perché crashava su macOS 27, una versione che lo sviluppatore non aveva ancora installato e non voleva caricare sulla propria macchina principale. Cercando un modo per riprodurre il crash, ha scoperto che il framework Virtualization di Apple permette di avviare una macchina virtuale macOS su Apple silicon gratuitamente, quindi ne ha configurata una per testare la nuova versione.

    Risoluzione

    Non specificato, oltre alla riproduzione del crash in una macchina virtuale.

    Lezione

    L'App Review testa le app sull'OS più recente. Tieni pronta una macchina virtuale con l'ultimo macOS per riprodurre i crash segnalati senza dover aggiornare il tuo computer principale.

49. 

    Review delay (no guideline cited) iOS Revisione infinita

    Dodici giorni in Waiting for Review dopo due richieste di expedite

    Cosa è successo

    Un developer con app già approvate ha inviato la versione 1.0 di una nuova app con un gruppo di cinque abbonamenti. Dopo dodici giorni era ancora in Waiting for Review, contro la solita media di meno di 48 ore. Ha richiesto due volte una revisione accelerata, ha contattato il supporto senza ricevere risposta e ha provato a prenotare un appuntamento per l'App Review, che è stato rifiutato.

    Risoluzione

    Al momento della scrittura, è ancora in attesa.

    Lezione

    Non pianificare il lancio basandoti sulla media di 48 ore. Lascia settimane di margine per una prima versione con abbonamenti e considera le richieste di expedite e gli appuntamenti come opzioni possibili, non garantite.

50. 

    Prompt dei permessi + metadati degli screenshot (regole spesso citate come 5.1.1 e 2.3.7) iOS Linea guida 5.1.1 Guideline 2.3.7

    Launch week: custom Allow screen and prices in screenshots

    Cosa è successo

    Durante la settimana del lancio, l'app è stata rifiutata due volte. La prima volta mostrava una propria schermata con un tasto 'Allow' subito prima del prompt di sistema, cosa che Apple non accetta. Dopo aver corretto il problema, il secondo rifiuto è arrivato perché gli screenshot dell'App Store mostravano i prezzi. Entrambe le correzioni erano minime, ma ogni nuova sottomissione ha comportato circa un giorno di attesa in coda per la revisione.

    Risoluzione

    Lo sviluppatore ha risolto entrambi i problemi e ora tiene entrambe le regole documentate nel progetto per evitare che accada di nuovo.

    Lezione

    Una schermata pre-permesso può spiegare perché serve l'accesso, ma lascia la scelta di 'Allow' esclusivamente al prompt di sistema. Evita di inserire i prezzi negli screenshot e fai un breve controllo prima di ogni sottomissione.

51. 

    Review delay (no guideline cited) iOS Revisione infinita

    Dieci giorni bloccati in revisione, poi approvato mezz'ora dopo il resubmit

    Cosa è successo

    L'app è rimasta in revisione per oltre dieci giorni senza cambiamenti. Lo sviluppatore l'ha inviata nuovamente.

    Risoluzione

    È stata approvata circa 30 minuti dopo il resubmit.

    Lezione

    Una revisione ferma non è sempre un verdetto sulla tua app. Se rimane bloccata ben oltre i tempi consueti, provare a fare il resubmit o richiedere una revisione accelerata può valere la pena, ma non c'è garanzia.

52. 

    4.3(a) Spam iOS Linea guida 4.3

    Sette app template rifiutate per il 4.3 nello stesso minuto

    Cosa è successo

    Un piccolo team ha inviato per la revisione sette app basate sullo stesso template nella stessa settimana. Tutte e sette hanno ricevuto lo stesso rifiuto per spam 4.3(a) nello stesso minuto, incluse due app mai rifiutate prima. Il team ha concluso che Apple abbia giudicato il pacchetto invece delle singole app.

    Risoluzione

    Ora il team invia un'app alla volta.

    Lezione

    Le app che condividono lo stesso codebase possono sembrare un pattern di spam se inviate insieme. Distanzia le submission e rendi ogni app chiaramente distinta per feature, design e metadati.

Questa pagina non costituisce consulenza legale e non prevede le decisioni di Apple per il tuo prossimo invio.