Quanto costa davvero la review dell'App Store ai team

Mostra tutte le 117 storie.

1. 

   4.3(a) Spam iOS Linea guida 4.3

   Un intero portfolio segnalato insieme

   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 solo piccole differenze. Ha deciso di procedere con le app una alla volta.

   Risoluzione

   Ancora in corso al momento della pubblicazione.

   Lezione

   La norma 4.3(a) copre anche la sovrapposizione tra le tue app. Se più app sono nate dallo stesso template, ognuna deve avere un core davvero distinto, non solo una nuova icona e un nuovo nome.

2. 

   4.3(a) Spam iOS Linea guida 4.3

   La stessa lettera due volte in una settimana

   Cosa è successo

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

   Risoluzione

   Non specificato.

   Lezione

   Ripresentare con modifiche cosmetiche raramente cambia un esito 4.3. Cambia il concept o spiega chiaramente nelle note di revisione cosa rende l'app diversa.

3. 

   4.3 Design / Spam iOS Linea guida 4.3

   Sviluppare in una categoria satura

   Cosa è successo

   Uno sviluppatore solitario che documentava una challenge di build quotidiana ha ricevuto un rifiuto 4.3 Design / Spam il quarto giorno e ha iniziato a chiedersi se scegliere una categoria satura fosse stato un errore.

   Risoluzione

   Non specificato.

   Lezione

   Le categorie che Apple considera sature subiscono un controllo più rigoroso. Valuta cosa rende la tua app unica prima di svilupparla, non dopo la revisione.

5. 

   2.1 Informazioni necessarie iOS Linea guida 2.1

   Sette domande per un nuovo account

   Cosa è successo

   La prima submission di un team è stata respinta con la 2.1 Information Needed: sette domande, una richiesta di screen recording e un account demo. Rispondere onestamente ha fatto emergere quattro cose che gli erano sfuggite.

   Risoluzione

   Hanno risolto i problemi e risposto.

   Lezione

   I nuovi account developer devono aspettarselo. Prepara un account demo, una registrazione e note chiare per la review prima di inviare.

6. 

   2.1 Completezza dell'app iOS Linea guida 2.1

   Il revisore non riusciva a usare l'app

   Cosa è successo

   Un developer alla prima esperienza è stato rifiutato due volte prima di andare live. Il primo rifiuto, secondo la 2.1, è arrivato perché il revisore non riusciva a capire come dovesse essere usata l'app.

   Risoluzione

   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 toccare e cosa dovrebbero vedere.

7. 

   Configurazione metadati e acquisti in-app iOS Metadata e IAP

   Due rifiuti per errori già noti

   Cosa è successo

   Uno sviluppatore indie è stato rifiutato due volte per cose che già sapeva. Prima, il build è stato inviato senza gli acquisti in-app collegati e la descrizione non conteneva 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 Revisione infinita

   9 giorni di attesa, poi 8 in revisione

   Cosa è successo

   Un developer ha aspettato nove giorni prima che lo stato passasse da Waiting for Review a In Review, poi è rimasto in revisione per altri otto giorni senza aggiornamenti.

   Risoluzione

   Nessuno al momento del post.

   Lezione

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

9. 

   Tempi della coda di revisione iOS Revisione infinita

   20 giorni nel loop rifiuto, fix, attesa

   Cosa è successo

   Per oltre 20 giorni, uno sviluppatore ha attraversato rifiuto, fix, 'Waiting for Review', rifiuto, fix, e stava ancora aspettando al momento del post.

   Risoluzione

   In sospeso.

   Lezione

   Ogni ciclo può costare giorni. Raggruppa tutti i fix di una nota di rifiuto in un'unica 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 con un'accusa di frode che non diceva cosa avesse fatto, mentre un gioco per imparare le lingue aspettava ancora la primissima revisione. Le sue app esistenti sono sparite e i clienti hanno iniziato a chiedere spiegazioni.

    Risoluzione

    Nessuno segnalato.

    Lezione

    La chiusura di un account rimuove tutte le app in una volta. 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

    Uno sviluppatore indie molto prolifico ha ricevuto un avviso: il suo account sarebbe stato chiuso entro dieci giorni. Apple ha indicato il numero di versioni rifiutate come una delle cause. Dopo l'attenzione pubblica e un ricorso, l'account non è stato chiuso.

    Risoluzione

    Account mantenuto dopo il ricorso.

    Lezione

    I rifiuti si accumulano. Evita di reinviare lo stesso giorno con modifiche di una sola parola e cloni quasi identici delle tue app.

12. 

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

    Registrazione obbligatoria: non sei quell'app così grande

    Cosa è successo

    L'app social di uno sviluppatore è stata rifiutata perché richiedeva la creazione di un account prima di arrivare al feed principale. Quando lo sviluppatore ha spiegato che ogni utente ha bisogno di un handle perché l'app funzioni, e ha citato una grande piattaforma di condivisione foto che fa lo stesso, il revisore ha risposto, in sostanza, che la sua app non era quella piattaforma.

    Risoluzione

    Non specificato.

    Lezione

    Quello che le grandi app si permettono non è un precedente che puoi citare. Se richiedi la registrazione, spiega nelle note di revisione perché la funzione principale non può funzionare senza un account e valuta se mostrare prima un po' di contenuto ai revisori o agli ospiti.

13. 

    4.3 Spam iOS Linea guida 4.3

    Da zero revisioni a quasi tutto rifiutato

    Cosa è successo

    Uno sviluppatore ha visto le sue app restare senza revisione per giorni. Nell'arco di circa una settimana, mentre aspettava, ha creato altre submission. Quando la revisione si è finalmente sbloccata, quasi tutte sono tornate indietro rifiutate per la guideline 4.3 spam.

    Risoluzione

    Non specificato.

    Lezione

    Una coda ferma non è un motivo per inviare altre submission. Accumularle mentre non viene revisionato nulla può far sembrare il tuo account un pattern di spam quando un reviewer le vede finalmente tutte insieme.

14. 

    4.3 Spam iOS Linea guida 4.3

    App non correlate rifiutate insieme

    Cosa è successo

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

    Risoluzione

    Non specificato.

    Lezione

    La 4.3 può essere applicata a livello di account, non app per app. Se diverse app vengono rifiutate insieme, rispondi a ciascuna separatamente e spiega chiaramente nelle note di revisione cosa rende ogni app diversa.

15. 

    Tempi della coda di revisione iOS Revisione infinita

    Un rifiuto, poi due mesi di silenzio

    Cosa è successo

    Dopo un solo rifiuto, l'app di uno sviluppatore è rimasta in review per circa due mesi, con ogni ciclo di revisione della durata di circa un mese. Lo sviluppatore sospettava che i cicli lunghi fossero diventati un modo per tenere fuori le nuove app.

    Risoluzione

    Ancora bloccata al momento del post.

    Lezione

    Dopo un rifiuto, il ciclo successivo può essere molto più lento del primo. Fai in modo che la nuova submission sia completa e ben documentata, per non perdere un altro mese in un secondo giro.

16. 

    Contenuti inappropriati iOS Contenuti inappropriati

    Rifiutato per reinvio senza correzioni

    Cosa è successo

    Un'app di fotoritocco AI è stata rifiutata perché era stata inviata più volte senza risolvere il problema segnalato da Apple, ovvero la presenza di contenuti inappropriati.

    Risoluzione

    Rifiutato.

    Lezione

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

17. 

    4.3 Spam iOS Linea guida 4.3

    Rifiutata nello stesso minuto in cui inizia la revisione

    Cosa è successo

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

    Risoluzione

    Non specificato.

    Lezione

    In nicchie affollate, un 4.3 veloce può arrivare prima che qualcuno guardi davvero. Apri le note di revisione con ciò che è unico e porta il revisore dritto lì.

18. 

    4.2.6 Template iOS Linea guida 4.2.6

    Segnalato per un template mai utilizzato

    Cosa è successo

    Un team si è visto rifiutare l'app ai sensi della linea guida 4.2.6, che riguarda le app create da un template commercializzato o da un servizio di generazione di app, anche se non aveva usato alcun template né servizio di generazione.

    Risoluzione

    Non specificato.

    Lezione

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

19. 

    3.1.2 Abbonamenti iOS Direttiva 3.1.2

    Il prezzo mensile era più evidente dell'importo addebitato

    Cosa è successo

    Il paywall di un developer è stato rifiutato perché mostrava il prezzo mensile calcolato di un abbonamento più lungo in modo più evidente rispetto all'importo effettivamente addebitato. Lo stesso paywall era passato in revisioni precedenti senza osservazioni. Il developer era d'accordo con la regola, ma era frustrato che fosse stato segnalato solo ora, e ha ridisegnato il paywall mettendo in primo piano l'importo addebitato.

    Risoluzione

    Reinviato con il nuovo design.

    Lezione

    Un paywall approvato in precedenza può comunque essere rifiutato in seguito. Rendi sempre l'importo addebitato e il periodo di fatturazione il prezzo più in evidenza; mostra l'eventuale suddivisione mensile più piccola e in secondo piano.

20. 

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

    Due mesi, poi un rifiuto senza motivo

    Cosa è successo

    Un developer ha passato oltre due mesi a provare a iscriversi, 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

    Nessuno al momento del post.

    Lezione

    L'enrollment può richiedere molto più tempo dello sviluppo dell'app. Inizia presto, 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 qualche mese di rilasci rapidi e feedback molto positivi dagli utenti, l'app di una startup è stata rifiutata nel tardo autunno per App Tracking Transparency, la regola sulla privacy di iOS che richiede l'autorizzazione dell'utente prima del tracciamento tra app e siti web. Il fondatore l'ha poi descritta come un rifiuto che ha messo a rischio l'intera azienda.

    Risoluzione

    Non specificato nel post.

    Lezione

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

22. 

    Login (numero della linea guida non specificato) iOS Accedi

    Il revisore non è riuscito ad accedere con Apple o Google

    Cosa è successo

    Per bloccare le iscrizioni 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 con il revisore precedente, che aveva rifiutato l'app per un altro motivo. Il revisore successivo l'ha rifiutata perché non riusciva ad accedere.

    Risoluzione

    Non specificato.

    Lezione

    Se la tua app offre solo il social login, i revisori potrebbero comunque bloccarsi. Fornisci loro un percorso funzionante nelle note di revisione, come 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 della guideline non specificato) iOS Gioco d'azzardo simulato

    Funzione di scommessa in-game su un account individuale

    Cosa è successo

    Un gioco è stato rifiutato per aver incluso scommesse simulate: i giocatori potevano scommettere oggetti in-game l'uno contro l'altro, una meccanica comune nei classici giochi di ruolo online. Poiché lo sviluppatore ha pubblicato con un account individuale anziché aziendale, ha deciso di rimuovere la funzione per ora.

    Risoluzione

    Rimozione della funzione e nuovo invio.

    Lezione

    Le meccaniche in stile gioco d'azzardo vengono esaminate con più attenzione anche senza denaro reale, e parte di ciò che Apple consente dipende dal tipo di account e dalla documentazione. Controlla le regole sul gioco d'azzardo prima di creare funzioni di staking, loot o scommessa, e scegli il tipo di account sviluppatore di conseguenza.

24. 

    Documenti falsi (numero della linea guida non indicato) iOS Documenti falsi

    Un editor PDF accusato per ciò che gli utenti potrebbero fare

    Cosa è successo

    Un'app editor PDF è stata rifiutata perché Apple sosteneva che permettesse di creare documenti falsi e ID 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 specificato.

    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 con AI (numero della guideline non specificato) iOS Condivisione dati con AI

    Nessuna schermata di consenso per la condivisione dati con AI di terzi

    Cosa è successo

    Un team ha ricevuto il primo rifiuto per aver condiviso dati degli utenti 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 costruire una schermata di consenso che passasse 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. Crea quella schermata prima della submission, non dopo il rifiuto.

26. 

    Entitlement Family Controls (numero della guideline non indicato chiaramente) iOS Metadata e IAP

    Cinque rifiuti per una casella non spuntata

    Cosa è successo

    Uno sviluppatore che pubblicava un'app in stile Screen Time è stato rifiutato cinque volte. Le note di revisione vaghe gli avevano fatto pensare che il problema fosse il design stesso. La vera causa era una singola impostazione Family Controls non selezionata nel suo setup developer. Una volta spuntata, l'app è stata approvata.

    Risoluzione

    Approvata dopo aver abilitato l'impostazione Family Controls e inviato di nuovo.

    Lezione

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

27. 

    Linea guida 5.1.1(v) iOS Linea guida 5.1.1 Requisito di login

    Account richiesto per una feature a pagamento che gira sul device

    Cosa è successo

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

    Risoluzione

    Ristrutturazione del codice affinché un acquisto effettuato senza account venga comunque associato al proprietario dopo l'iscrizione opzionale. In corso al momento della pubblicazione.

    Lezione

    Se una feature a pagamento gira sul device e non richiede un'identità lato server, permetti agli utenti di acquistarla e ripristinarla senza un account. Riserva la registrazione solo alle funzioni che ne hanno davvero bisogno, come il backup cloud.

28. 

    Linea guida 1.4.2 Danni fisici iOS Direttiva 1.4.2

    App per il calcolo del dosaggio rimosse in un giro di vite sulle regole

    Cosa è successo

    Un developer si è svegliato scoprendo che due delle sue app erano state segnalate in base alla linea guida 1.4.2, anche se nessuna delle due aveva nulla in revisione. Erano entrambe già live: un calcolatore di dosaggio peptidico standalone e un tracker con lo stesso calcolatore integrato, che insieme erano diventati il suo primo vero successo di ricavi. Altri developer dello stesso settore hanno ricevuto la stessa notifica nello stesso momento. Diceva che le app che calcolano dosi di farmaci, compresi dosaggi e ricostituzione di peptidi, devono essere pubblicate dall'azienda produttrice del farmaco o da un'istituzione riconosciuta come un ospedale, un'assicurazione, una farmacia o un'università.

    Risoluzione

    Nessuna. Il developer ha detto di aver capito il problema di sicurezza e l'ha considerata la fine di quelle app.

    Lezione

    L'approvazione non è permanente. Apple può rivalutare un'app già live quando inasprisce una regola. Se la tua app calcola dosi o fornisce indicazioni sulla salute che potrebbero fare male a qualcuno, leggi la linea guida 1.4 prima di iniziare a sviluppare e metti in conto di pubblicare tramite un'istituzione qualificata oppure lascia fuori il calcolo.

29. 

    Linee guida 4.3 Spam e 4.2.6 Servizi di generazione app iOS Linea guida 4.3 Linea 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 aveva già gestito l'ingresso a un evento locale con diverse centinaia di partecipanti. Apple l'ha rifiutata di nuovo con un avviso che combina 4.3 e 4.2.6, sostenendo che potesse 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 che facciano la stessa cosa, e la versione Android era online da circa una settimana.

    Risoluzione

    Al momento del post era ancora rifiutata. Lo sviluppatore ha detto che comunque non puntava a guadagnare 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 è davvero diversa, spiega esattamente in cosa nelle note di revisione e nei primi screenshot, cita l'uso nel mondo reale e dichiara chiaramente che non hai 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 di Apple: il suo account violava il Code di condotta del Developer Program ai sensi della guideline 5.6.4, App Quality. La notifica segnalava un numero eccessivo di richieste di rimborso e di reclami, avvertiva che l'account rischiava la chiusura e che tutti i pagamenti dei guadagni erano sospesi e i trasferimenti delle app disabilitati. Il tasso di rimborso era quasi raddoppiato negli ultimi due mesi. Analizzando i dati, il developer ha visto che 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 che si trasformava in un piano annuale. L'avviso è arrivato proprio mentre un importante redesign dell'app era già in fase di test.

    Risoluzione

    Ancora aperta al momento del post. Il developer ha aggiunto più promemoria durante la prova gratuita, ha reso più evidente il prossimo addebito, ha aggiunto la possibilità di gestire e annullare l'abbonamento dentro l'app, ha completato il redesign con più test e ha messo in pausa tutto il marketing a pagamento con i creator in attesa.

    Lezione

    Apple guarda ai tassi di rimborso e ai reclami, non solo al tuo binario. Una prova gratuita che si trasforma silenziosamente in un addebito annuale può diventare un problema di acquisti non intenzionali su larga scala. Ricorda agli utenti quando la prova sta per finire, mostra chiaramente il prezzo reale, rendi semplice la disdetta e tratta un tasso di rimborso in aumento come un rischio per l'account molto prima che lo faccia Apple.

31. 

    Configurazione metadati e acquisti in-app iOS Metadata e IAP

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

    Cosa è successo

    Uno sviluppatore ha aggiunto un'immagine promozionale a un abbonamento in App Store Connect e si è ritrovato accidentalmente con la stessa immagine aggiunta due volte. Da quel momento, l'immagine non poteva essere eliminata né sostituita, e ogni tentativo falliva con un errore generico che chiedeva di riprovare più tardi. L'app è stata rifiutata tre volte a causa di quella configurazione dell'abbonamento. Ogni volta, lo sviluppatore ha risposto con una registrazione dello schermo del tentativo di eliminazione e dell'errore, e ogni volta sembrava che il revisore la ignorasse. Lo sviluppatore riteneva che la causa principale fosse un bug in App Store Connect stesso.

    Risoluzione

    Ancora irrisolto al momento della pubblicazione, senza correzioni da parte di Apple.

    Lezione

    Quando è App Store Connect stesso a bloccare la soluzione, una risposta nel thread del rifiuto potrebbe non arrivare a chi può risolverla. Carica le immagini degli abbonamenti con attenzione e una sola volta; se la console si rompe, contatta separatamente il supporto per sviluppatori Apple per il bug, mentre rispondi ad App Review.

32. 

    Linea guida 4.3 Spam iOS Linea guida 4.3

    Tre rifiuti per un'app creata per gestire una sola palestra

    Cosa è successo

    Un developer ha creato un'app iOS per gestire 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 in base alla guideline 4.3 Spam. Lo stesso giorno ha risposto a tutte e nove le domande inviate da App Review. Sei giorni dopo, il 19 ottobre, non aveva ancora ricevuto alcun riscontro. La lista delle app su App Store Connect mostrava diverse altre app sullo stesso account anch'esse in stato di rifiuto nello stesso periodo, sia su iOS sia 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 misura la linea guida 4.3. Se un'app è davvero pensata per una singola azienda, un'app non elencata può restare fuori dalla ricerca pur restando accessibile a chiunque abbia il link diretto; la distribuzione Custom App limita la disponibilità a organizzazioni specifiche. Scegli l'opzione che corrisponde al controllo degli accessi richiesto. Per una scheda pubblica, rendi evidente ciò che distingue l'app da quelle esistenti nelle prime schermate, negli screenshot e nelle note di revisione.

33. 

    Linee guida 5.6 Developer Code of Conduct e 2.5.19 Funzionalità nascoste iOS Linea guida 5.6 Developer Code of Conduct Linea guida 2.5.19 Funzionalità nascoste

    Rifiutata per frode per switch di test rimasti attivi

    Cosa è successo

    A settembre 2026 uno sviluppatore si è visto rifiutare un'app iOS in base alla linea guida 5.6 Developer Code of Conduct. Apple ha dichiarato di aver rilevato un pattern di comportamenti che associa alle frodi, in particolare funzionalità che sembravano essere state nascoste di proposito durante la review. Lo sviluppatore ha risalito il problema a tre switch di test lasciati nel release build: una modalità per fare gli screenshot dello store, uno switch che simulava un controllo lento degli entitlement e uno che sbloccava acquisti mock. Nessuno di questi era raggiungibile dagli utenti normali della versione su App Store. Nell'aggiornamento delle App Review Guidelines del 16 ottobre, le funzionalità nascoste, dormienti o non documentate sono diventate una linea guida a sé, la 2.5.19, e Apple avverte che violarla può mettere a rischio l'intero account sviluppatore.

    Risoluzione

    Ora lo sviluppatore controlla le stringhe dentro ogni release archive prima dell'upload. Non è stato precisato se quel build sia stato poi approvato.

    Lezione

    Escludi le code solo per i test dai release build in fase di compilazione, ad esempio con flag DEBUG, invece che dietro un controllo a runtime. Verifica cosa viene effettivamente incluso nel binario archiviato ed elenca ogni switch che rimane nelle note di App Review.

34. 

    2.1 Informazioni necessarie iOS Linea guida 2.1

    Review sospesa in attesa di chiarimenti sul target dell'app

    Cosa è successo

    Uno sviluppatore ha inviato la versione 1.0 di un'app per iPad e la revisione si è fermata sulla Guideline 2.1, Information Needed. Nessun crash report, nessuna funzionalità rotta, nessun fix al binario richiesto. Apple voleva solo una risposta dettagliata a una domanda prima di poter proseguire la revisione: chi avrebbe usato questa app.

    Risoluzione

    Apple ha chiesto una spiegazione del target di utenti prima di proseguire la revisione.

    Lezione

    Considera pubblico e caso d'uso come input per la revisione, non come testo di marketing da completare dopo. Scrivi una risposta chiara sul target di utenti prima di inviare la prima versione.

35. 

    4.3 Design / Spam iOS Linea guida 4.3

    Non abbastanza diversa in una categoria di app audio satura

    Cosa è successo

    Un'app di intrattenimento audio è stata rifiutata in base alla linea guida 4.3(b). Apple ha affermato che lo store conteneva già abbastanza app simili e ha trattato il prodotto come contenuto duplicato in una categoria satura, anche se il team riteneva che funzionalità aggiuntive lo rendessero unico.

    Risoluzione

    Rifiutata per 4.3(b) a causa di una differenziazione insufficiente in una categoria affollata.

    Lezione

    Nelle categorie che Apple definisce sature, la novità deve essere evidente nel primo minuto di revisione. Inizia mostrando ciò che è unico, non con un trucco che i revisori hanno già visto molte volte.

36. 

    Metadata e testo della scheda dello store iOS Metadata e IAP Revisione infinita

    Il loop dei metadata che ha mangiato la launch week

    Cosa è successo

    Un team di produttività per consumatori ha rilasciato una build pulita, poi ha passato più di nove giorni in un ciclo di obiezioni sui metadati. Ogni nuovo invio rispondeva alla nota precedente, ma la risposta successiva si concentrava su un'altra frase, screenshot o spiegazione. Nessun code è cambiato mentre i piani di lancio, stampa e acquisizione a pagamento restavano in attesa dei testi in revisione.

    Risoluzione

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

    Lezione

    Blocca i testi della scheda, gli screenshot e le note di revisione in un'unica passata prima di fissare una data di lancio. I rifiuti per i metadati possono accumularsi anche se il binario non cambia mai.

37. 

    Conformità all'esportazione (App Store Connect) iOS Metadata e IAP

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

    Cosa è successo

    Una build companion per una dashboard B2B ha ottenuto l'approvazione, ma il rilascio è rimasto bloccato quando è riapparso un prompt di compliance, dopo che il team pensava di aver già risposto alle domande sull'export. Il release owner ha fermato il rollout, raccolto i testi legali, aggiornato la risposta su App Store Connect e atteso un altro passaggio di revisione, mentre i clienti vedevano l'annuncio prima che l'app fosse disponibile.

    Risoluzione

    Rilasciato dopo aver risposto di nuovo alla compliance sull'export e aver atteso il passaggio di revisione successivo.

    Lezione

    Tratta la compliance sull'export come un gate di rilascio, non come una checkbox da spuntare una volta sola. 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 Metadata 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 percorso 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 necessaria per il primo rilascio. Un singolo permesso può trasformarsi in una revisione completa delle policy su Google Play.

39. 

    Tempi di revisione della coda di Google Play Google Play Revisione infinita

    L'hotfix rimasto in attesa dietro una coda di policy

    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 salivano mentre lo stato restava in attesa. Hanno prima mitigato lato server, poi hanno visto arrivare l'approvazione del binario quando l'emergenza aveva già bruciato un weekend.

    Risoluzione

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

    Lezione

    La revisione degli store non è un canale di incident response. Mantieni una via di mitigazione alternativa 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 Direttiva 3.1.1 Direttiva 3.1.3

    Un'app companion rifiutata perché la prova scade

    Cosa è successo

    Uno sviluppatore ha rilasciato un'app companion gratuita per iOS per il suo servizio email web a pagamento. L'app non vendeva nulla al suo interno. Ha fatto riferimento all'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 era una vera esperienza stand-alone. Apple ha proposto due soluzioni: dare all'app abbastanza contenuti e funzionalità gratuite da 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 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 acquisti in-app.

    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 travestito una volta terminata la prova. Prima di inviarla, decidi cosa l'utente può ancora fare nell'app gratuitamente dopo la prova, oppure pianifica l'In-App Purchase. Citare altre app che sembrano fare lo stesso raramente fa vincere un ricorso.

41. 

    Linea guida 3.1.1 In-App Purchase iOS Direttiva 3.1.1

    Chiave API "bring your own key" trattata come pagamento fuori dall'App Store

    Cosa è successo

    Uno sviluppatore solo che creava un assistente AI per iPhone lasciava incollare agli utenti la propria chiave API di un aggregatore di modelli di terze parti, così da poter eseguire modelli cloud di grandi dimensioni. Al quarto round di revisione, App Review ha rifiutato l'app ai sensi della guideline 3.1.1, trattando l'opzione bring your own key come un modo per pagare funzionalità fuori dall'App Store. Da come lo sviluppatore ha interpretato il 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 eseguire i modelli interamente on-device e aveva in programma di reintrodurre i modelli cloud più avanti come crediti in-app venduti tramite In-App Purchase. Al momento della scrittura, l'esito di quel nuovo invio non era noto.

    Lezione

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

42. 

    Direttiva 1.2 iOS Direttiva 1.2

    Un confronto tra outfit rifiutato per aver decretato un vincitore

    Cosa è successo

    Uno sviluppatore indie ha rilasciato un'app AI che confronta due outfit. Dopo il confronto, l'app annunciava che un look aveva vinto. App Review l'ha rifiutata in base alla linea guida 1.2, interpretando il risultato come una classifica di persone anziché di vestiti. Lo sviluppatore si è detto d'accordo con la preoccupazione.

    Risoluzione

    Ha rimosso ogni riferimento al vincitore, il badge del vincitore e qualsiasi punteggio più grande o colore in evidenza su una delle due opzioni, così entrambi gli outfit hanno ora lo stesso peso visivo, ognuno riceve il proprio feedback e l'utente decide. Non è stato comunicato se la build corretta sia stata approvata.

    Lezione

    Apple giudica come viene percepita una schermata, non solo cosa fa. Se la tua app assegna punteggi legati all'aspetto delle persone, presenta il feedback senza classifiche e dai per scontata l'interpretazione più severa.

43. 

    Categoria Kids, linea guida 3.1.2 e questioni sulla privacy iOS Categoria Bambini Direttiva 3.1.2 Revisione infinita

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

    Cosa è successo

    Un developer solitario ha creato un'app di storie per bambini dai 4 ai 10 anni, dove i piccoli possono ascoltare storie e fare pause per porre domande. L'app era già online su Android da settimane. È stata inviata all'App Store il 19 settembre 2026. Dopo diversi cicli di rifiuto e riespansione, non era ancora stata approvata circa un mese dopo. Nell'ultimo ciclo, Apple ha richiesto due cose: poiché l'app vende abbonamenti settimanali, mensili e annuali, la pagina dell'App Store doveva contenere un link funzionante ai Termini di Servizio; e poiché l'app rientra nella categoria Kids, la revisione non poteva proseguire finché lo sviluppatore non avesse risposto a quattro domande su analytics di terze parti, pubblicità di terze parti, se vengono condivisi dati con terze parti e dove vengono archiviati, e se vengono raccolti altri dati di utenti o dispositivi e a quale scopo.

    Risoluzione

    Lo sviluppatore ha risolto entrambi i problemi e ha risubito l'app. Al momento della pubblicazione, l'esito è ancora in sospeso.

    Lezione

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

44. 

    Linee guida 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 conclusione dello sviluppatore era che tutti e tre i problemi riguardavano login, acquisto e cancellazione.

    Risoluzione

    Non specificato.

    Lezione

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

45. 

    Linee guida 5.2.3 Download audio/video iOS Linee guida 5.2.3 Download audio/video

    Radio internet vintage bloccata per i diritti audio di terze parti

    Cosa è successo

    L'app radio internet di uno sviluppatore singolo, con un look vintage, alla versione 1.0 e alla quinta build, è stata rifiutata in base alla linea guida 5.2.3, che riguarda le app che riproducono o scaricano audio e video da fonti di terze parti e richiede la prova che lo sviluppatore ne abbia i diritti. Il giorno dopo lo sviluppatore ha risposto nel Resolution Center con una spiegazione sui diritti dei contenuti.

    Risoluzione

    Esito non ancora noto al momento della pubblicazione.

    Lezione

    Se la tua app fa streaming di stazioni o media che non possiedi, procurati le autorizzazioni o usa fonti i cui termini consentano esplicitamente la riproduzione nell'app, e inserisci quella documentazione nelle note di revisione prima di inviare.

46. 

    Direttiva 4.3 (Spam) iOS Linea guida 4.3

    Sei rifiuti, poi l'etichetta spam 4.3 e due settimane di attesa per una call

    Cosa è successo

    Un developer indipendente ha lavorato per mesi alla sua prima app, un tool per rompere il ghiaccio in contesti sociali. È stata rifiutata sei volte, l'ultima per la Guideline 4.3 relativa allo spam, nonostante il developer ritenesse che offrisse di più rispetto alle app simili già presenti sullo store. Ha chiesto ad App Review una call one-to-one. È passata una settimana senza risposta e la call è arrivata solo circa due settimane dopo il rifiuto per la 4.3. Il developer è uscito dalla call con l'impressione che la 4.3 venga ora usata per segnalare app che sembrano cloni generati dall'AI con poco impegno, cosa che la sua app non era.

    Risoluzione

    Il developer ha presentato ricorso. Al momento in cui scriviamo era ancora in sospeso.

    Lezione

    In una categoria affollata, il revisore valuta ciò che mostrano screenshot, descrizione e prima sessione. Rendi lì evidente la differenza rispetto alle app esistenti e richiedi subito la call con App Review, perché ottenerla 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 per un motivo che non c'entrava nulla con l'app. L'account non aveva ancora accettato un nuovo accordo pubblicato su App Store Connect. Lo sviluppatore l'ha accettato e ha inviato di nuovo, ma la submission è tornata in coda per circa un'altra settimana. Il supporto per gli sviluppatori ha risposto solo che era tutto in regola.

    Risoluzione

    Al momento in cui scriviamo è 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 giro completo nella coda di revisione.

48. 

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

    Rifiutata per un crash su una versione di macOS che lo sviluppatore non aveva installato

    Cosa è successo

    Un'app Mac è stata rifiutata perché andava in crash su macOS 27, una versione che lo sviluppatore non aveva ancora installato e non voleva installare sulla propria macchina principale. Mentre cercava 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, e 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 versioni OS più recenti. Tieni pronta una macchina virtuale con l'ultimo macOS per riprodurre i crash della review senza dover aggiornare il tuo computer principale.

49. 

    Ritardo review (nessuna linea guida citata) iOS Revisione infinita

    Dodici giorni in Waiting for Review dopo due richieste di revisione accelerata

    Cosa è successo

    Uno sviluppatore che aveva già app approvate sullo store ha inviato la versione 1.0 di una nuova app insieme a un gruppo di cinque abbonamenti. Dodici giorni dopo era ancora in Waiting for Review, rispetto all'attesa abituale 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 con l'App Review, che è stato rifiutato.

    Risoluzione

    Ancora in attesa al momento in cui scriviamo.

    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 revisione accelerata e gli appuntamenti come possibili, non garantiti.

50. 

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

    Settimana del lancio: schermata 'Allow' personalizzata e prezzi negli screenshot

    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 nuovo invio costava circa un giorno in coda per la revisione.

    Risoluzione

    Lo sviluppatore ha risolto entrambi i problemi e ora tiene entrambe le regole scritte nel progetto, così non succede più.

    Lezione

    Una schermata pre-permesso può spiegare perché serve l'accesso, ma lascia la scelta 'Allow' esclusivamente al prompt di sistema. Tieni i prezzi fuori dagli screenshot e segui una breve checklist prima di ogni invio.

51. 

    Ritardo review (nessuna linea guida citata) iOS Revisione infinita

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

    Cosa è successo

    L'app è rimasta in revisione per più di dieci giorni senza avanzare. Lo sviluppatore l'ha reinviata.

    Risoluzione

    È stata approvata circa 30 minuti dopo il resubmit.

    Lezione

    Una revisione in stallo non è sempre un verdetto sulla tua app. Se resta bloccata ben oltre i tempi normali, provare a reinviare o a chiedere una revisione accelerata può valere la pena, ma nessuna delle due è garantita.

52. 

    4.3(a) Spam iOS Linea guida 4.3

    Sette app da template rifiutate per 4.3 nello stesso minuto

    Cosa è successo

    Un piccolo team ha inviato in revisione sette app basate sullo stesso template nella stessa settimana. Tutte e sette hanno ricevuto l'identico rifiuto per spam 4.3(a) nello stesso minuto, incluse due app che non erano mai state rifiutate prima. Il team ha concluso che Apple ha valutato il batch anziché ogni singola app.

    Risoluzione

    Ora il team invia un'app alla volta.

    Lezione

    Le app che condividono la stessa codebase possono sembrare un pattern di spam se arrivano insieme. Distanziare le submission e rendere ogni app chiaramente distinta per funzionalità, design e metadati.

53. 

    Direttiva 2.3.6 iOS Direttiva 2.3.6

    Rifiuto per age rating nonostante Connect fosse già corretto

    Cosa è successo

    Un'app è stata rifiutata per via dell'age rating. Lo sviluppatore ha aperto il questionario sull'age rating in App Store Connect e ha visto che ogni risposta corrispondeva già a quanto richiesto dal messaggio di rifiuto.

    Risoluzione

    Non hanno cambiato nulla in Connect, hanno risposto al revisore che le impostazioni erano già corrette e hanno inviato nuovamente l'app. Poche ore dopo, l'app è stata approvata.

    Lezione

    Una nota sulla 2.3.6 può non rispecchiare le tue impostazioni attuali. Controlla App Store Connect prima di cambiare qualcosa e, se è già tutto corretto, dillo chiaramente nella risposta invece di tirare a indovinare una soluzione.

54. 

    Linee guida 2.1: Informazioni necessarie iOS Linea guida 2.1

    Cronologia revisioni limitata: registrazione su dispositivo e demo delle funzioni a pagamento

    Cosa è successo

    Un'app che aveva già superato la revisione di Google Play è stata respinta per la 2.1 Information Needed. Apple ha comunicato che l'account developer aveva una cronologia di revisione limitata e ha chiesto una registrazione dello schermo su un dispositivo reale, una demo delle funzioni a pagamento e una descrizione scritta di cosa fa l'app e a quali servizi esterni si appoggia.

    Risoluzione

    Al momento della pubblicazione, lo sviluppatore stava preparando la registrazione e le risposte. Esito non noto.

    Lezione

    Superare la revisione di Google Play non dice nulla su Apple. Se il tuo account developer è nuovo o ha pochi invii precedenti, prepara una registrazione su dispositivo reale, una demo delle funzioni a pagamento e un elenco dei servizi di terze parti prima di inviare l'app.

55. 

    Guidelines 2.1, 2.3.2 e 5.2.3 iOS Linea guida 2.1 Direttiva 2.3.2 Linee guida 5.2.3 Download audio/video Revisione infinita

    Prima submission: 2.1, poi 2.3.2, poi 5.2.3 in un mese

    Cosa è successo

    La prima submission in assoluto di un developer è rimasta in attesa per sei giorni ed è stata rifiutata per la 2.1. Hanno risposto lo stesso giorno. Dodici giorni dopo è stata rifiutata di nuovo, questa volta per la 2.3.2. Hanno effettuato il resubmit e, nove giorni dopo, è stata rifiutata per la 5.2.3. Hanno risposto ancora lo stesso giorno e, due giorni dopo, erano ancora in attesa. Ogni round ha fatto emergere una guideline diversa dalla precedente.

    Risoluzione

    Ancora in attesa, dopo più di un mese dalla prima submission.

    Lezione

    Ogni round trip può far emergere una nuova linea guida, e ognuna può costare una settimana o più. Prima della prima submission, leggi le regole sui metadati (2.3) e quelle sui diritti di contenuto che ti riguardano (5.2), non solo quelle sulla completezza (2.1), e correggi tutto ciò che puoi trovare in un'unica build.

56. 

    Direttiva 4.2 Funzionalità Minima iOS Linea guida 4.2

    App di preghiera rifiutata: essenzialmente un libro ai sensi della 4.2

    Cosa è successo

    Un'app di preghiera e devozione religiosa è stata rifiutata ai sensi della 4.2 con la motivazione che fosse principalmente un libro. Lo sviluppatore ha fatto notare funzionalità interattive tra cui un calendario, un contatore delle preghiere, un timer per la meditazione, collezioni condivisibili, widget per la Home Screen e ricerca vocale.

    Risoluzione

    Non specificato.

    Lezione

    Se un revisore interpreta la tua app come contenuto statico, le funzionalità interattive potrebbero non essere visibili nei primi minuti di revisione. Mostrale nelle prime schermate e negli screenshot e indicale nelle note di revisione, con i passaggi per raggiungere ciascuna.

57. 

    Linea guida 2.3.10 iOS Linea guida 2.3.10

    Tredici giorni in coda, rifiutata in sette minuti per colpa di Android

    Cosa è successo

    Un developer è rimasto tredici giorni in coda per la revisione, controllando ogni giorno App Store Connect e l'email e aprendo due ticket di supporto. Quando la revisione è finalmente iniziata, l'app è stata rifiutata dopo circa sette minuti perché la descrizione su App Store diceva che il prodotto funzionava in qualsiasi browser su iPhone o Android.

    Risoluzione

    Hanno rimosso il riferimento all'altra piattaforma, una modifica di una riga, e hanno inviato di nuovo. Esito non ancora comunicato.

    Lezione

    Apple rifiuta i metadati che citano altre piattaforme mobile. Controlla descrizione, screenshot e testi promozionali per nomi di piattaforme concorrenti prima di inviare: un piccolo errore di formulazione può costare un'intera attesa in coda.

58. 

    Direttiva 5 (Legale) iOS Direttiva 5: Aspetti legali

    Rifiuto Guideline 5 per riferimento a OpenAI nei metadati per la Cina

    Cosa è successo

    Un'app AI è stata rifiutata ai sensi della Guideline 5 Legal perché i metadati citavano OpenAI. Apple ha spiegato che la Cina richiede una licenza governativa per l'IA generativa e i servizi di deep synthesis, che ChatGPT non ha quel permesso, e che lo sviluppatore deve rimuovere la funzionalità AI e ogni riferimento a OpenAI o ChatGPT da nome, sottotitolo, testo promozionale, descrizione e screenshot per lo storefront cinese, oppure smettere di distribuire in Cina continentale.

    Risoluzione

    Lo sviluppatore consiglia di deselezionare la storefront Cina continentale in Disponibilità prima di inviare un'app che nomina tali servizi, risparmiando un ciclo di revisione.

    Lezione

    Se la tua app si basa su un provider di AI generativa, decidi fin da subito la disponibilità in Cina. Il rifiuto riguarda la storefront e i metadati, non solo il tuo code.

59. 

    Direttiva 3.1.2 iOS Direttiva 3.1.2

    Link ai Termini presente nell'app ma assente dalla descrizione

    Cosa è successo

    La prima versione di un'app in abbonamento è stata rifiutata due giorni dopo l'invio perché il link ai Termini d'Uso non era nella descrizione dell'App Store. Era già presente nell'app, nel paywall e nelle impostazioni, ma non in quel campo dei metadati.

    Risoluzione

    La correzione ha richiesto cinque minuti, ma dopo il nuovo invio il build è rimasto in "Waiting for Review" per oltre dieci giorni senza risposta. Nessuna segnalazione finora.

    Lezione

    Per gli abbonamenti a rinnovo automatico, inserisci i link ai Termini di utilizzo (EULA) e alla Privacy Policy sia nei metadati dell'App Store che nell'app prima del primo invio: un fix rapido può comunque costare una lunga seconda attesa.

60. 

    Chiusura dell'account iOS Chiusura dell'account

    Account chiuso per violazione della norma 3.2(f), pagamenti in sospeso

    Cosa è successo

    L'account Apple Developer di uno sviluppatore è stato terminato ai sensi della sezione 3.2(f) del Developer Program License Agreement. Quasi tre mesi dopo, i guadagni in sospeso non erano ancora stati pagati e lo sviluppatore chiedeva ad altri sviluppatori se qualcuno avesse mai ricevuto i guadagni trattenuti dopo una terminazione.

    Risoluzione

    Nessuno segnalato.

    Lezione

    Una chiusura può congelare i ricavi già maturati, non solo le vendite future. Tieni una riserva di cassa, i registri dei tuoi payout e un tuo canale diretto verso gli utenti, così una sola decisione sull'account non chiude l'attività.

61. 

    Linee guida 2.1 e 5.1.2 iOS Linea guida 2.1 Linee guida 5.1.2 Revisione infinita

    Venticinque giorni in revisione, poi 2.1 e 5.1.2 insieme

    Cosa è successo

    Uno sviluppatore indie ha inviato la prima versione, la 1.0, di un'app iOS. Dopo circa diciassette giorni, la build era ancora in review. Dopo circa venticinque giorni in tutto, App Review l'ha rifiutata con le linee guida 2.1 App Completeness e 5.1.2 Data Use and Sharing nella stessa decisione. App Store Connect ha poi bloccato tutti gli altri elementi della submission finché la versione rifiutata non fosse stata corretta. Lo sviluppatore ha detto che i problemi segnalati erano facili da risolvere; la parte dolorosa era aspettarsi altre due o tre settimane per la resubmission.

    Risoluzione

    Hanno risolto entrambi i problemi e hanno reinviato. L'esito della review successiva non è stato comunicato.

    Lezione

    Quando le code sono così lunghe, ogni rifiuto può costare settimane. Prima di inviare, fai un controllo completo: nessun flusso interrotto, un account demo funzionante, niente placeholder, e assicurati che le risposte sulla privacy e qualsiasi condivisione di dati SDK corrispondano a ciò che l'app fa davvero.

62. 

    Linea guida 2.3.1(a) iOS Linea guida 2.3.1 Metadata e IAP

    Puntate in denaro reale rifiutate come nascoste ai sensi della 2.3.1(a)

    Cosa è successo

    Uno sviluppatore ha creato un tracker di abitudini e disciplina dove gli utenti potevano mettere in gioco del denaro e perderlo se non raggiungevano i propri obiettivi. A metà ottobre 2026, l'App Review lo ha rifiutato secondo la linea guida 2.3.1(a), sostenendo che l'app contenesse funzionalità nascoste, nello specifico scommesse in denaro e perdita delle somme puntate non descritte nei metadati. La lettera includeva anche un avviso di Extended Review, che segnalava come invii ripetuti con questi problemi comportino tempi di revisione più lunghi e che gli account che continuano a violare le regole possono essere rimossi dall'Apple Developer Program. L'app ha subito in totale cinque rifiuti; un altro citava un crash durante la revisione su iPad. Lo sviluppatore, che aveva usato strumenti di AI coding, ha riassunto i punti chiave: leggere le linee guida, allineare i metadati all'app, non nascondere mai funzionalità o raccolta dati, revisionare il code generato e testare su dispositivi diversi.

    Risoluzione

    Non specificato, oltre al rifacimento dell'app dopo cinque rifiuti. Non è stata riportata l'approvazione.

    Lezione

    Qualsiasi funzionalità che muove denaro reale, incluse scommesse o perdite delle somme puntate, deve essere chiara nella descrizione e nelle note per l'App Review. Testa su iPad anche se il target è iPhone, perché i revisori lo fanno.

63. 

    Linea guida 4.3(a) iOS Linea guida 4.3

    Nuove feature, nuovi screenshot e un 4.3(a) in tre minuti con un avviso

    Cosa è successo

    Uno sviluppatore che aveva impiegato circa due mesi per costruire un'app da zero era già stato rifiutato per spam (4.3). Per il tentativo successivo ha aggiunto nuove feature, sostituito ogni screenshot, ottimizzato l'app per più dimensioni di dispositivo e l'ha inviata di nuovo con note di revisione e un account di test premium. Tre minuti dopo l'ingresso in review, l'app è stata rifiutata di nuovo per la Guideline 4.3(a). Questa volta il messaggio terminava con un avviso di revisione esteso: invii ripetuti con questi problemi avrebbero comportato tempi di revisione più lunghi, e gli account che continuano a inviare app simili rischiano la rimozione dall'Apple Developer Program. Temendo che un altro resubmit potesse costare l'intero account, lo sviluppatore era indeciso se abbandonare l'app o chiedere una call ad App Review.

    Risoluzione

    Non risolto al momento della pubblicazione.

    Lezione

    Una volta che appare l'avviso di revisione esteso, un resubmit rapido è la mossa più rischiosa. Chiedi prima una call con App Review e invia di nuovo solo quando sai cosa considerano troppo simile.

64. 

    Linea guida 4.3(b) iOS Linea guida 4.3

    Rifiutata in tre minuti, poi tre settimane di silenzio sull'appello

    Cosa è successo

    L'app di uno sviluppatore è stata rifiutata in base alla linea guida 4.3(b) circa tre minuti dopo l'ingresso in revisione. Ha presentato ricorso all'App Review Board. Tre settimane dopo, ancora nessuna risposta, nessun cambio di stato e nessun messaggio di alcun tipo.

    Risoluzione

    Non risolto.

    Lezione

    Un ricorso può restare in sospeso per settimane senza feedback. Lavora in parallelo su ciò che rende l'app diversa dalla categoria affollata, così non resti bloccato ad aspettare solo il ricorso.

65. 

    Chiusura dell'account iOS Chiusura dell'account

    Un'app sembrava un sito web e decine di app sono scomparse

    Cosa è successo

    Uno studio che pubblicava app da oltre un decennio, più di 80, ha visto il proprio account sviluppatore segnalato per la chiusura. Secondo lo studio, il motivo era che una delle sue app poteva essere considerata simile a un sito web esistente. Nessun preavviso e nessuna possibilità di rimuovere solo quell'app. Tutte le sue app sono state rimosse dall'App Store, comprese app con licenza non correlate realizzate per i clienti, e gli aggiornamenti sono stati bloccati.

    Risoluzione

    Nessuna soluzione. Lo studio ha contestato pubblicamente la decisione.

    Lezione

    Un account sviluppatore è un single point of failure. Se sviluppi app per clienti, pubblicale sotto l'account sviluppatore del cliente, così una disputa su una delle tue app non può far cadere anche le loro.

66. 

    Sezione 3.2(f) (Developer Program License Agreement) iOS Chiusura dell'account

    Un aggiornamento del titolo, poi una notifica di risoluzione 3.2(f)

    Cosa è successo

    Uno sviluppatore indie ha inviato una semplice modifica al titolo di un'app e ha ricevuto un avviso di risoluzione ai sensi della sezione 3.2(f). Tutte le sue app sono state rimosse dallo store. Ha presentato ricorsi ufficiali e, 15 giorni dopo, non aveva ancora ricevuto risposta da una persona.

    Risoluzione

    Non risolto.

    Lezione

    L'aggiornamento che fa scattare un avviso 3.2(f) potrebbe non essere ciò a cui sta reagendo Apple. Prima di presentare ricorso, raccogli prove chiare su chi possiede e gestisce ogni app e metti in conto settimane di attesa.

67. 

    Sezione 3.2(f) (Developer Program License Agreement) iOS Chiusura dell'account

    Una correzione al paywall, poi un avviso di risoluzione 3.2(f) una settimana dopo

    Cosa è successo

    L'app di uno sviluppatore indie era stata rifiutata una volta, per come venivano mostrati i prezzi settimanali e annuali nel paywall. Il paywall veniva da un template copiato da un assistente AI per il coding. Ha sistemato il problema in code, ha inviato una nuova build e ha aspettato circa una settimana. Invece dell'esito della revisione, si è svegliato con un avviso di chiusura imminente ai sensi della sezione 3.2(f). Tutta la sua membership developer è stata segnalata, ogni app che aveva creato in anni è stata rimossa dall'App Store e i pagamenti sono stati congelati. Lo sviluppatore ha dichiarato di non aver cambiato nulla nell'app dopo l'invio, di avere i log a supporto, e ha chiesto pubblicamente se qualcuno fosse mai riuscito a riavere indietro un account.

    Risoluzione

    Non risolto al momento della pubblicazione.

    Lezione

    Considera un rifiuto sul paywall o sui prezzi come un avvertimento, non una formalità. Controlla in code come vengono mostrati prezzi e condizioni di prova in ogni template o paywall generato prima del primo invio, e conserva i log di build e delle modifiche per poter documentare esattamente cosa hai inviato se il tuo account dovesse essere contestato.

68. 

    Linea guida 3.1.1 In-App Purchase macOS Direttiva 3.1.1

    Un client di cloud gaming gratuito rifiutato per la violazione della regola 3.1.1 sugli acquisti in-game

    Cosa è successo

    Uno sviluppatore ha creato un'app gratuita di remote play per il servizio di cloud gaming di un grande produttore di console e l'ha inviata all'App Store. La versione Mac è stata rifiutata in base alla linea guida 3.1.1. App Review ha dichiarato che alcuni giochi in streaming potrebbero portare gli utenti ad acquistare contenuti digitali al di fuori dell'App Store. Secondo lo sviluppatore, il servizio di gaming non consente ai giocatori di completare un pagamento durante una sessione di streaming: alcuni giochi mostrano opzioni di acquisto, ma il pagamento non può andare a buon fine durante lo streaming. Ha fatto notare che diverse app di streaming simili erano già presenti sullo store e ha presentato ricorso.

    Risoluzione

    Ricorso pendente al momento della pubblicazione.

    Lezione

    Per le app di streaming e i client, App Review valuta ciò che gli utenti vedono all'interno del contenuto in streaming, non solo la tua code. Spiega nelle note di revisione esattamente come funzionano gli acquisti all'interno dello stream, con screenshot, prima del primo invio invece di tenerlo da parte per il ricorso.

69. 

    Login su iPad (numero della linea guida non specificato) iOS Accedi

    Terzo rifiuto perché il login su iPad è fallito durante un down del backend

    Cosa è successo

    Un piccolo team che sviluppava un'app di fitness si è visto rifiutare l'app iOS per la terza volta perché il revisore non riusciva a fare login su un iPad. La causa non era nell'app code: il loro provider backend aveva problemi di autenticazione proprio quando il revisore ha provato, quindi il sign in è semplicemente fallito. Il team aveva fornito un account demo con email e password, ma secondo loro il revisore non ha riprovato in seguito. Non avevano un iPad né un Mac su cui fare test. Una volta ripristinato il backend, hanno inviato di nuovo l'app. Apple aveva detto che l'app sarebbe rimasta in revisione accelerata anche in caso di nuovo rifiuto, eppure tre giorni lavorativi dopo era ancora in attesa di revisione.

    Risoluzione

    Inviata di nuovo, ancora in attesa di revisione al momento della pubblicazione.

    Lezione

    I revisori spesso fanno i test su iPad e di solito provano il login una sola volta. Tieni d'occhio lo stato del backend e del provider di auth mentre una build è in revisione, testa l'account demo su uno schermo grande come un iPad prima di inviare e indica nelle note di revisione chi contattare se il sign in fallisce.

70. 

    Guidelines 5.1.1(i) e 5.1.2(i) iOS Linea guida 5.1.1 Linee guida 5.1.2 Condivisione dati con AI

    Il consenso AI sepolto nei termini non è bastato per le linee guida 5.1.1(i) e 5.1.2(i)

    Cosa è successo

    L'app di diario di uno sviluppatore è stata rifiutata su iOS per le linee guida 5.1.1(i) e 5.1.2(i), entrambe relative alla condivisione di dati utente con servizi AI. Il consenso a quel trattamento era già previsto nei termini dell'app, ma l'App Review non l'ha accettato. Lo sviluppatore ha quindi spostato il consenso su una schermata esplicita dentro l'app, mostrata per prima, prima che qualsiasi modello legga una singola voce. Poi ha mappato ogni percorso code in cui le voci raggiungono un modello, subordinando ognuno a quel consenso, così che nessuna richiesta venga nemmeno costruita senza un sì. I job in background ora saltano gli account che non hanno acconsentito e attendono invece di fallire, e un controllo in fase di release fallisce se l'app chiama un host AI che la schermata di consenso non menziona.

    Risoluzione

    Risolto e reinviato. Al momento della pubblicazione il verdetto di Apple non era ancora noto.

    Lezione

    Una riga nei tuoi termini non è un consenso alla condivisione dei dati con l'AI. Chiedi dentro l'app prima della prima richiesta, indica il provider e i dati, e assicurati che ogni percorso code che invia contenuti utente verifichi quella risposta.

71. 

    Sezione 3.2(f) (Developer Program License Agreement), dopo ripetuti rifiuti dei metadati iOS Chiusura dell'account Metadata e IAP

    Una nuova libreria, otto rifiuti, un'app rinominata, poi una notifica di chiusura

    Cosa è successo

    Un developer indie aveva un'app iOS che aveva quasi tre anni, aveva generato sei cifre di fatturato e aveva rilasciato numerosi update con un basso tasso di rimborso. Più di sei mesi fa ha inviato un piccolo aggiornamento la cui unica modifica era una nuova libreria. App Review l'ha rifiutata più di otto volte, ogni volta per problemi di metadati: keyword attive da oltre un anno, un sottotitolo in una localizzazione, poi gli screenshot, poi di nuovo gli stessi punti e infine il nome dell'app stessa, che era la fonte principale del suo traffico di ricerca. Ha chiesto una chiamata con App Review e il revisore gli ha detto che il nome era l'ultimo problema rimasto. Ha rinominato l'intera app e l'ha inviata di nuovo. Tre giorni dopo è arrivato un rifiuto generico che citava ancora i problemi di sottotitolo e screenshot. Ha deciso che l'update non serviva e l'ha abbandonato. Mesi dopo, in quello stesso vecchio thread di revisione è arrivata una notifica di chiusura in sospeso. Diceva che l'account aveva violato ripetutamente le linee guida nel tentativo di eludere il processo di revisione e che i problemi segnalati in precedenza non erano stati risolti. L'app è stata rimossa dallo store e l'intero account è stato segnalato per la rimozione.

    Risoluzione

    Ricorso presentato all'App Review Board, in sospeso al momento della pubblicazione.

    Lezione

    Un invio abbandonato può comunque pesare sul tuo account. Se il ciclo di revisione va avanti, fai confermare per iscritto nel thread di revisione ogni problema rimasto, non solo durante una call; se decidi di ritirare un aggiornamento, rispondi nel thread per dirlo e rimuovi la build dalla revisione, invece di lasciare il rifiuto irrisolto.

72. 

    Linea guida 1.1 Sicurezza: Contenuto offensivo, poi Sezione 3.2(f) iOS Contenuti inappropriati Chiusura dell'account

    Due rifiuti 1.1, una domanda su quale immagine, poi una notifica di terminazione

    Cosa è successo

    L'app iOS di uno sviluppatore che genera foto di coppia con l'AI è stata rifiutata per la linea guida 1.1 sui contenuti inappropriati. Il rifiuto non indicava quale immagine fosse il problema. Ha ammorbidito le immagini di esempio, senza contatti fisici né avvicinamenti, e ha fatto un solo resubmit circa cinque giorni dopo. Quattro giorni dopo è stata rifiutata di nuovo per lo stesso motivo. Invece di inviare una nuova build, ha scritto ad Apple chiedendo quale immagine fosse il problema. Sono passati circa dieci giorni senza risposta, poi l'app è stata rimossa dallo store e lo sviluppatore ha ricevuto un avviso di chiusura imminente. Da quanto aveva capito, Apple considerava il ciclo ripetuto di correzione e nuovo invio un tentativo di aggirare la revisione. I pagamenti sono stati sospesi e ogni app sull'account era a rischio, con 30 giorni per presentare appello. Leggendo thread dei forum di sviluppatori con lo stesso avviso, ha scoperto che la maggior parte degli appelli restava per settimane senza risposta, e l'unico ripristino trovato era arrivato dopo un secondo appello che indicava la causa reale e rivelava tutto il resto.

    Risoluzione

    Appello in preparazione al momento della pubblicazione.

    Lezione

    Due rifiuti per la stessa linea guida possono ora bastare a mettere a rischio un account. Quando un rifiuto per contenuti è vago, chiedi ad App Review di indicare lo schermo o l'asset esatto prima di fare il resubmit, tieni traccia di ogni modifica e considera il secondo rifiuto come un segnale per fermarti, non per riprovare.

73. 

    Linee guida 2.3.7, 5.2.5 e 4.8 iOS Linea guida 2.3.7 Metadata e IAP Requisito di login

    Approvata su Mac, poi rifiutata su iPhone per le linee guida 2.3.7, 5.2.5 e 4.8 nella stessa app

    Cosa è successo

    Un developer che stava creando un client di calendario per un importante servizio di calendario di terze parti ha rilasciato prima la versione Mac. La versione Mac aveva già richiesto un ricorso formale solo per poter dichiarare nella scheda che funziona con quel servizio di calendario, e avevano già spiegato ad App Review perché non servisse Sign in with Apple. Quando hanno aggiunto la versione iPhone, con lo stesso bundle e lo stesso App ID dell'app Mac, è stata rifiutata per tre linee guida contemporaneamente: la 2.3.7 per i prezzi mostrati in un in-app event, la 5.2.5 per una riga che indicava che l'app era per iPhone, iPad e Mac, e la 4.8 per non offrire Sign in with Apple accanto al login del servizio di calendario stesso. La linea guida 4.8 prevede un'eccezione per le app che sono client di un servizio specifico di terze parti, che è proprio il caso di questa app, ma la spiegazione fornita per la versione Mac non è stata ripresa. Ogni target di piattaforma è stato revisionato da zero.

    Risoluzione

    Non specificato al momento della pubblicazione.

    Lezione

    Una nuova piattaforma significa una nuova revisione, anche all'interno dello stesso App ID. Copia ogni spiegazione ed eccezione che hai già ottenuto nelle note di revisione per ogni piattaforma e, prima di inviare, controlla in-app events e descrizioni per prezzi e nomi di dispositivi Apple.

74. 

    Guideline 3.1.2(c), poi il marchio Apple nel testo di Siri (numero della guideline non indicato) iOS Direttiva 3.1.2 Revisione infinita

    Nove giorni di attesa, un rifiuto per paywall 3.1.2(c), poi un binario scartato in 42 secondi per via di Siri text

    Cosa è successo

    Uno sviluppatore con un account nuovo ha inviato la prima versione di un'app per le abitudini di scrittura e ha aspettato circa nove giorni prima che passasse a In Review. Cinquanta minuti dopo è stata rifiutata in base alla guideline 3.1.2(c): nel piano annuale, il prezzo mensile calcolato era mostrato con un font più grande rispetto al prezzo annuale effettivamente addebitato. Hanno sistemato le dimensioni del font nel paywall e caricato una nuova build. Quella build è stata rifiutata automaticamente in 42 secondi, perché il testo di aiuto di una scorciatoia Siri citava un'app Apple con il suo nome commerciale, e il testo nei Siri intent non può usare la parola Apple. L'hanno riformulato per riferirsi genericamente all'app note e hanno caricato di nuovo la build.

    Risoluzione

    Inviata di nuovo, esito sconosciuto al momento della pubblicazione.

    Lezione

    Prima del primo invio, rendi l'importo addebitato il prezzo più in evidenza su ogni piano e cerca i marchi Apple in tutte le stringhe visibili all'utente, inclusi Siri, Shortcuts e il testo dei widget. I controlli automatici li individuano in pochi secondi, ma ogni round ti costa comunque una posizione in coda.

75. 

    Sezione 3.2(f) (Developer Program License Agreement), che cita un rifiuto per un vecchio nome iOS Chiusura dell'account Metadata e IAP

    Rifiuto del nome corretto e approvato, poi una notifica di chiusura per frode quasi un anno dopo

    Cosa è successo

    Un singolo sviluppatore, alla guida di un piccolo account aziendale, aveva pubblicato otto app attive in circa un anno e mezzo. Quasi un anno prima, una di quelle app era stata rifiutata perché Apple contestava una parola nel suo nome. Lo sviluppatore ha cambiato il nome, l'app è stata revisionata di nuovo e approvata, e anche un aggiornamento successivo è stato approvato. La cronologia delle revisioni condivisa mostra la versione 1.0 rifiutata per due giorni consecutivi e approvata il giorno dopo, poi un aggiornamento approvato al primo tentativo circa due mesi più tardi. Dopo di che l'app è rimasta intoccata per circa nove mesi. Poi una nuova app dello stesso account è stata rifiutata, ed è arrivato un preavviso di chiusura che citava attività disoneste o fraudolente ai sensi della sezione 3.2(f): le submission avevano violato ripetutamente le linee guida nel tentativo di eludere la revisione, e i problemi delle comunicazioni precedenti erano rimasti irrisolti. Non indicava alcun nuovo problema e non era stata preceduta da avvertimenti o domande. I guadagni di tutte le app sono stati sospesi, comprese quelle che non avevano mai avuto problemi, e l'avviso avvertiva che anche un nuovo account poteva essere chiuso. L'unico modo per rispondere era un modulo web limitato a 2.000 caratteri, che restituiva una conferma automatica e poi silenzio. Lo sviluppatore ha accettato la rimozione delle app segnalate, ha spento i server lo stesso giorno, ha sospeso tutte le submission e ha inviato un ricorso completo il primo giorno.

    Risoluzione

    Ricorso inviato il primo giorno; al momento della pubblicazione solo una conferma automatica.

    Lezione

    Un rifiuto che hai risolto e che è stato approvato può comunque essere citato mesi dopo come parte di un pattern. Conserva ogni messaggio di rifiuto, la modifica esatta che hai fatto e l'approvazione che ne è seguita, così da poter mostrare tutta la cronologia in un breve modulo di ricorso, e non aspettarti tempi definiti una volta inviato.

76. 

    Guidelines 4.3 Spam e 4.2.6 iOS Linea guida 4.3 Linea guida 4.2.6

    Un gioco fatto da solo, rifiutato due volte come spam e come template: nove risposte inviate, nessuna replica

    Cosa è successo

    Un developer che crea giochi da solo la sera ha inviato un gioco originale e se l'è visto rifiutare due volte, a quattro giorni di distanza, all'inizio di ottobre, in base alla guideline 4.3 sullo spam e alla 4.2.6, che riguarda le app create da template commerciali o da servizi di generazione di app. Non c'era nessun template e ogni riga di codice è stata scritta dal developer. Entrambi i rifiuti riportavano lo stesso testo precompilato, e nessuno dei due indicava l'app a cui il gioco avrebbe dovuto assomigliare. Apple ha poi inviato nove domande su come fosse stato realizzato il gioco, e il developer ha risposto a tutte in dettaglio il giorno dopo il secondo rifiuto. Non è arrivata alcuna risposta. Circa nove giorni dopo ha presentato ricorso all'App Review Board, e una settimana dopo era ancora in attesa. La sua ipotesi era che una sola persona che pubblica diversi giochi in pochi mesi sembri una fabbrica di app agli occhi del reviewer. Nel frattempo ha reso il gioco giocabile gratis nel browser.

    Risoluzione

    Ricorso all'App Review Board ancora in sospeso al momento della pubblicazione, circa tre settimane dopo il primo rifiuto.

    Lezione

    Le linee guida 4.3 e 4.2.6 possono essere valutate sull'intero account, non su un singolo binario. Se pubblichi più titoli in poco tempo, mostra cosa rende ciascuno originale fin dalla prima submission, con note di revisione su come è stato costruito e un breve video di gameplay, perché quando il testo del rifiuto è un template, le risposte dettagliate possono restare non lette per settimane.

77. 

    Linea guida 2.1 Completezza dell'app, poi linea guida 5 Legale (disponibilità in Cina) iOS Linea guida 2.1 Direttiva 5: Aspetti legali Revisione infinita

    Una licenza gratuita per il revisore ha nascosto il paywall, poi sei giorni in coda e un rifiuto legato all'AI in Cina

    Cosa è successo

    Uno sviluppatore ha inviato la sua prima app iOS, uno strumento di finanza personale per tenere traccia dei pagamenti ricorrenti, e gli è stata rifiutata in base alla linea guida 2.1 Completezza dell'app. La causa è stata un favore che si è rivelato controproducente: aveva fornito all'indirizzo email del revisore una licenza a pagamento, così il revisore ha saltato il paywall e non ha mai visto il flusso di acquisto. Lo sviluppatore ha creato una guida PDF passo-passo con screenshot per il revisore e ha inviato di nuovo, questa volta insieme le versioni per iOS e Mac. La nuova submission è rimasta in attesa sei giorni prima di passare a In Review, per poi essere rifiutata di nuovo, questa volta a causa di un riferimento a ChatGPT mentre l'app era disponibile in Cina continentale.

    Risoluzione

    Ancora rifiutata al momento della pubblicazione, mentre una build più recente era stata offerta ai tester tramite TestFlight.

    Lezione

    Fai vedere ad App Review esattamente ciò che vede un nuovo utente, paywall incluso. Fornisci al revisore un account demo o sandbox funzionante e note chiare, anziché una licenza gratuita che nasconde il flusso di acquisto. Se l'app o la sua scheda menziona un provider AI come ChatGPT, verifica se la Cina continentale è tra i territori disponibili prima di inviare, poiché ogni nuovo round può costare giorni in coda.

78. 

    Linea guida 2.3.10 Metadati accurati iOS Linea guida 2.3.10 Metadata e IAP Revisione infinita

    Dieci giorni per la prima revisione, una menzione di Google Play, poi altre due settimane di attesa

    Cosa è successo

    Un developer con un account developer appena creato ha inviato un'app nuova di zecca all'inizio di ottobre. È un'app dove gli utenti possono caricare pubblicamente le proprie immagini, cosa che il developer si aspettava attirasse un controllo extra sulla moderazione dei contenuti. La prima revisione è arrivata dieci giorni dopo, su iPad, ed è finita con un rifiuto per la guideline 2.3.10 Accurate Metadata: l'app o i suoi metadati menzionavano una piattaforma di terze parti, e il passo successivo era rimuovere i riferimenti a Google Play. Il developer ha rintracciato la menzione nel testo che descriveva un acquisto in-app. Dopo la correzione l'app è tornata in coda e, due settimane dopo, era ancora in attesa di revisione: 24 giorni dalla prima submission e ancora non online.

    Risoluzione

    Ancora in attesa di revisione al momento della pubblicazione, 24 giorni dopo la prima submission.

    Lezione

    Controlla ogni campo di testo che invii, incluse le descrizioni degli acquisti in-app, cercando nomi di altri store e piattaforme prima della prima submission. Con un account nuovo ogni ciclo può costare una settimana o più in coda, quindi una sola parola può ritardare il lancio di settimane.

79. 

    Guideline 2.1 App Completeness (Informazioni necessarie) iOS Linea guida 2.1 Revisione infinita

    24 giorni in coda, poi un rifiuto 2.1 con richiesta di una registrazione completa dello schermo

    Cosa è successo

    Un developer ha inviato la versione 1.0.0 di una nuova app iOS insieme a un gruppo di abbonamenti e due abbonamenti, annuale e mensile. Dopo 24 giorni di attesa, Apple l'ha esaminata e rifiutata in base alla guideline 2.1 App Completeness, lasciando il developer confuso. Poiché la versione dell'app è stata rifiutata, anche gli abbonamenti inviati con essa non hanno potuto essere approvati e sono rimasti in stato Ready for Review. Il messaggio alla base del rifiuto era una richiesta 2.1 Information Needed, la prima che il developer avesse ricevuto. Chiedeva una registrazione dello schermo su un dispositivo fisico con l'ultimo sistema operativo, a partire dal lancio e mostrando il tipico user flow: registrazione, login ed eliminazione dell'account, eventuali contenuti generati dagli utenti con i relativi strumenti di segnalazione e blocco, e l'accesso ai contenuti a pagamento. Chiedeva anche una descrizione dello scopo e del pubblico di riferimento, istruzioni di setup con credenziali di accesso, un elenco dei servizi esterni su cui l'app si basa, inclusi i servizi AI, eventuali differenze regionali e la documentazione per settori regolamentati o materiale protetto di terze parti. Le risposte dovevano inoltre essere aggiunte alle note di revisione in App Store Connect per le future submission.

    Risoluzione

    Al momento della pubblicazione, il developer era tornato a preparare la registrazione e le risposte. Esito non noto.

    Lezione

    Una richiesta Information Needed dopo settimane in coda costa un altro giro completo di revisione. Registra quel walkthrough su un dispositivo reale e scrivi quelle risposte nelle note di revisione prima di inviare una nuova app, soprattutto se ha abbonamenti, account o contenuti utente, dato che una versione rifiutata blocca anche tutto ciò che viene inviato con essa.

80. 

    Sezione 3.2(f) (Developer Program License Agreement) Apple Developer Program Chiusura dell'account Revisione infinita

    Sei aggiornamenti approvati di fila, poi un aggiornamento di routine e la chiusura ai sensi della 3.2(f)

    Cosa è successo

    Uno sviluppatore indie ha visto approvati sei aggiornamenti consecutivi. La cronologia delle revisioni che ha condiviso mostra l'ultimo invio In Review e tutti i precedenti contrassegnati Review Completed. Poi a metà ottobre ha inviato un aggiornamento di routine, che è rimasto bloccato in revisione. Invece di un esito della revisione, l'intero account sviluppatore è stato chiuso ai sensi della sezione 3.2(f). In App Store Connect, un messaggio datato il giorno di quell'invio era associato a più versioni e contrassegnato come problemi non risolti. Lo sviluppatore ha descritto le sue app come native, con un record pulito di aggiornamenti approvati, e ha detto che il supporto Apple sta esaminando il suo ricorso.

    Risoluzione

    Ricorso in fase di analisi al momento della pubblicazione.

    Lezione

    Una serie di approvazioni senza intoppi non ti protegge da una terminazione 3.2(f). Tieni un registro datato di ogni submission, messaggio di review e approvazione, e controlla la sezione Messages in App Store Connect dopo ogni review, così da poter inviare lo storico completo appena un ricorso diventa possibile.

81. 

    Richiesta di informazioni da parte dell'App Review (account demo e screen recording) iOS Accedi

    L'account demo cancellato cinque minuti dopo la submission, poi una richiesta di screen recording che ha evitato un secondo rifiuto

    Cosa è successo

    Un'agenzia ha inviato l'app di un cliente con un account demo per l'App Review. Cinque minuti dopo la submission, l'App Review aveva cancellato quell'account demo. Apple ha poi chiesto uno screen recording dell'app. Durante la registrazione, il team ha trovato nell'app del testo di vendita che gli era sfuggito e che avrebbe causato un altro rifiuto.

    Risoluzione

    Esito finale non condiviso al momento della pubblicazione.

    Lezione

    Un revisore potrebbe eliminare l'account demo che fornisci, ad esempio mentre verifica che la cancellazione dell'account funzioni, quindi assicurati di poterlo ricreare o forniscine più di uno. Registra il tuo walkthrough di revisione prima di inviare: guardare l'app con gli occhi di un revisore è il modo più semplice per scovare testi che potrebbero causare il prossimo rifiuto.

82. 

    Sezione 3.2(f) (Developer Program License Agreement) Apple Developer Program Chiusura dell'account Metadata e IAP

    Cinque rifiuti iniziali, quattro update approvati, poi una notifica 3.2(f) dopo oltre un anno

    Cosa è successo

    Uno sviluppatore iOS indipendente, con quasi dieci anni di app alle spalle, ha inviato una nuova app AI image-to-video nell'aprile 2025. Gli utenti caricavano le proprie foto, ricevevano la prima generazione gratis e potevano poi acquistare crediti tramite acquisti in-app una tantum, senza abbonamenti. Il primo invio è stato rifiutato cinque volte, principalmente per screenshot e metadati: screenshot giudicati troppo orientati al marketing, e uno screenshot che mostrava una coppia che si baciava, poi sostituito da uno con una proposta di matrimonio, è stato segnalato per la linea guida sui contenuti discutibili. Dopo aver modificato gli screenshot, i relativi testi e la build, l'app è stata approvata e sono seguiti quattro aggiornamenti senza un solo rifiuto, l'ultimo ad agosto 2025. Dopo non è stato inviato più alcun aggiornamento. Più di quattordici mesi dopo, è arrivato un avviso di chiusura imminente (Pending Termination Notice) che diceva che gli invii dell'account avevano ripetutamente violato le linee guida nel tentativo di eludere la revisione, con violazioni ancora irrisolte dopo numerosi reinvii, e l'avviso era allegato a tutte e cinque le versioni. Lo sviluppatore ha detto che App Store Connect non mostrava più dettagli sufficienti per ricostruire i vecchi rifiuti. Ha presentato ricorso circa 30 minuti dopo l'arrivo della notifica, intorno a mezzanotte, entro il limite di 2.000 caratteri, e in seguito avrebbe voluto aspettare per scriverlo in modo più chiaro.

    Risoluzione

    Ricorso pendente al momento della pubblicazione.

    Lezione

    Un'approvazione non chiude la pratica. Conserva una tua copia di ogni messaggio di rifiuto, la linea guida citata, le modifiche apportate e la data di approvazione, perché App Store Connect potrebbe non mostrare i vecchi dettagli in seguito. Se arriva una comunicazione, prenditi il tempo per scrivere un ricorso chiaro che rispetti il limite di caratteri, invece di inviarne uno entro la prima ora.

83. 

    Sezione 3.2(f) (Developer Program License Agreement) Apple Developer Program Chiusura dell'account Metadata e IAP

    Una parola chiave nel titolo, una risoluzione 3.2(f) e un ricorso basato su riferimenti allo streaming

    Cosa è successo

    Un developer indie ha visto chiudere l'intero account developer ai sensi della sezione 3.2(f). Secondo la sua versione, è successo senza preavviso e senza rifiuti precedenti dei metadati, e riteneva che la causa fosse un errore in una keyword del titolo di un'app. Ha presentato ricorso. L'App Review Board ha risposto che l'indagine aveva confermato violazioni delle linee guida: una delle app del developer includeva riferimenti fuorvianti che portavano gli utenti a credere che offrisse servizi di streaming, cosa che Apple ha definito grave. La lettera descriveva un pattern di comportamenti manipolatori o ingannevoli, ha mantenuto sospesi i pagamenti dei guadagni e ha detto che, una volta formalizzata la chiusura, il developer avrebbe potuto presentare istanza all'App Review Board per il ripristino, spiegando i motivi e i miglioramenti pianificati.

    Risoluzione

    Appello respinto. È possibile presentare una richiesta di riattivazione dopo la cessazione formale.

    Lezione

    Parole nel titolo o nelle keyword che suggeriscono un servizio non offerto dall'app, come lo streaming, possono essere lette come fuorvianti anziché come un semplice errore di metadati, e questo può portare direttamente alla cessazione senza un precedente rifiuto. Verifica ogni titolo, sottotitolo e keyword rispetto a ciò che l'app fa realmente prima di inviare.

84. 

    Linea guida 4.1(a) Copycats iOS Revisione infinita

    15 giorni di revisione, poi 4.1(a) Copycats per poster di film da un API pubblico

    Cosa è successo

    Un sviluppatore ha creato un'app iOS che aiuta le persone a scegliere un film. Mostra titoli e poster presi da un database pubblico di film API, citato all'interno dell'app, e il pulsante Guarda apre l'app di streaming ufficiale invece di fare streaming in proprio. Dopo 15 giorni di revisione, Apple l'ha rifiutata in base alla linea guida 4.1(a) Copycats, trattando i poster come contenuto di terze parti e chiedendo prova dei diritti d'uso oppure la loro rimozione. La stessa app con gli stessi poster era stata approvata su Android e su uno store di app per TV.

    Risoluzione

    Non risolto al momento del post. Lo sviluppatore chiedeva ad altri sviluppatori se i termini di API fossero stati accettati come prova o se i poster dovessero essere rimossi.

    Lezione

    I crediti all'interno dell'app e l'approvazione su altri store non contano come diritti per l'App Review. Se la tua app mostra poster, artwork o loghi di un API, procurati prima dell'invio una prova scritta che ti autorizzi a mostrarli, oppure pianifica una versione senza.

85. 

    Rifiuto dei metadati (parola chiave localizzata) iOS Metadata e IAP

    L'IA ha tradotto l'app in cinque lingue e ci ha infilato una parola chiave che l'ha fatta rifiutare

    Cosa è successo

    Uno sviluppatore ha usato un modello di IA per tradurre la propria app in altre cinque lingue. In una di queste lingue la traduzione ha aggiunto una parola chiave che poteva essere fraintesa, e l'invio è stato rifiutato per questo. Una settimana dopo lo sviluppatore era ancora in attesa di una risposta e, dopo una settimana di storie di account chiusi per la 3.2(f) raccontate da altri sviluppatori, temeva che anche una correzione approvata potesse poi essere usata contro l'account.

    Risoluzione

    In attesa di una risposta da Apple al momento della pubblicazione.

    Lezione

    Fai controllare da un madrelingua ogni keyword, titolo e sottotitolo localizzati prima dell'invio. La traduzione automatica è veloce, ma l'App Review valuta i testi di ogni locale come se li avessi scelti tu.

86. 

    Metadati dell'anteprima app (riferimento al prezzo) iOS Metadata e IAP

    Un'anteprima app indicava la disponibilità di una prova gratuita e l'update è stato rifiutato

    Cosa è successo

    Un developer indie ha inviato un update il cui video di anteprima conteneva le parole 'prova gratuita disponibile'. Apple ha rifiutato l'update, considerando qualsiasi menzione di 'gratis' nell'anteprima come un riferimento al prezzo. Il developer ha rimontato il video e lo ha inviato di nuovo.

    Risoluzione

    Video rimontato e ripresentato. Esito finale non condiviso al momento della pubblicazione.

    Lezione

    Evita prezzi e la parola "gratis" nelle anteprime dell'app, anche se il trial è reale. Mostra i termini del trial all'interno dell'app, sul paywall.

87. 

    Linea guida 2.5.1 Requisiti software (HealthKit) iOS Revisione infinita

    Sei giorni di attesa, poi 2.5.1 perché la sincronizzazione Health non aveva il badge Apple Health

    Cosa è successo

    Un sviluppatore indie ha inviato un aggiornamento importante che aggiungeva per la prima volta la sincronizzazione con Apple Health. È rimasto in "In attesa di revisione" per sei giorni. Solo allora ha notato un nuovo contratto per sviluppatori in attesa di firma nel suo account. L'ha firmato e l'aggiornamento è entrato in revisione quello stesso pomeriggio, anche se non sapeva dire se le due cose fossero collegate. L'aggiornamento è stato poi rifiutato in base alla linea guida 2.5.1 perché la funzione Health non era chiaramente identificata nell'interfaccia dell'app. Lo sviluppatore non sapeva dell'esistenza del badge Apple Health.

    Risoluzione

    Ho aggiunto il badge Works with Apple Health accanto all'interruttore di sincronizzazione, una nota di revisione e una registrazione dello schermo fatta su un dispositivo reale. Approvata alla submission successiva.

    Lezione

    Se la tua app legge o scrive dati Health, mostralo chiaramente nell'interfaccia con il badge Apple Health fin dalla prima submission. E quando una revisione resta ferma per giorni, controlla App Store Connect per un accordo non firmato prima di ogni altra cosa.

88. 

    Linea guida 1.1 Contenuti inappropriati iOS Contenuti inappropriati

    Attiva da oltre un anno senza rifiuti, poi rimossa ai sensi della 1.1 senza preavviso

    Cosa è successo

    Uno sviluppatore indie aveva un'app sull'App Store da più di un anno. Non era mai stata rifiutata e generava un modesto reddito da abbonamento mensile. Senza alcun preavviso, Apple ha inviato un messaggio dicendo che l'app era stata rimossa dallo store per violazione della guideline 1.1 Objectionable Content.

    Risoluzione

    Lo sviluppatore ha detto ad Apple che non avrebbe risubito, ha abbandonato l'app e l'intera nicchia, perché non voleva mettere a rischio il proprio account sviluppatore.

    Lezione

    Uno storico di revisioni pulito non protegge un'app dal rischio di rimozione successiva, e le regole sui contenuti possono essere applicate a un'app approvata da molto tempo. Se la tua app opera in una nicchia sensibile, verifica i contenuti e gli screenshot rispetto alla direttiva 1.1 ora, non dopo una notifica di rimozione.

89. 

    Rifiuto per bug (direttiva non specificata) iOS Revisione infinita

    Un timeout di matchmaking di 100 secondi segnalato come bug, poi sei giorni in attesa di una risposta

    Cosa è successo

    Uno sviluppatore ha inviato un gioco multiplayer. Il revisore lo ha rifiutato per un bug, ma ciò che ha riscontrato non era un crash: il gioco smette di cercare dopo 100 secondi di attesa per abbinare il giocatore a un avversario, e il revisore ha interpretato quel timeout come un comportamento errato. Lo sviluppatore ha risposto al revisore spiegando come funziona il matchmaking e ha anche rimosso il timeout dal gioco. Sei giorni dopo erano ancora in attesa di una singola risposta.

    Risoluzione

    Ho spiegato in una risposta e rimosso il timeout. Al momento del post, sto ancora aspettando una risposta.

    Lezione

    Un revisore spesso gioca da solo e in orari strani, quindi è probabile che la coda di matchmaking sia vuota. Dai al team di revisione un modo per accedere a una partita reale, ad esempio un avversario bot o una modalità demo, e spiegalo nelle note di revisione prima di inviare.

90. 

    Rifiuto dei metadati (link a Termini e Privacy) iOS Metadata e IAP

    Code riutilizzato da un'altra app, e i link a Termini e Privacy puntavano ancora a quella vecchia

    Cosa è successo

    Un developer ha creato una nuova app riutilizzando parti di una sua app precedente. I link ai Termini di utilizzo e alla Privacy Policy puntavano ancora alla vecchia app, e l'App Review ha rifiutato la submission per questo motivo. Il developer ha detto che il messaggio di rifiuto indicava esattamente cosa andava cambiato.

    Risoluzione

    Link sistemati e app reinviata. Lo sviluppatore ha detto che una revisione accelerata di solito si concludeva in circa un giorno, ma va usata con moderazione.

    Lezione

    Prima di inviare un'app creata da un vecchio progetto, controlla ogni link, nome del bundle e pagina legale che si porta dietro. Leggi bene il messaggio di rifiuto: spesso dice esattamente cosa correggere.

91. 

    Linee guida 2.1: Informazioni necessarie iOS Linea guida 2.1

    Nessun bug nel report, solo 2.1 Information Needed, a cui hanno risposto con una registrazione di 89 secondi.

    Cosa è successo

    Un developer ha inviato la sua seconda app, che è tornata indietro con la guideline 2.1 Information Needed senza alcun bug segnalato. App Review voleva una screen recording e risposte su a chi è rivolta l'app, come viene usata, da quali servizi esterni dipende e in quali regioni è disponibile. Il developer ha registrato 89 secondi sul simulatore, dal lancio fino a un uso completo della funzione principale e al paywall, ha risposto a ogni domanda nelle note e ha inviato di nuovo lo stesso giorno.

    Risoluzione

    Registrazione e risposte inviate lo stesso giorno. Esito finale non condiviso al momento della pubblicazione.

    Lezione

    Per una nuova app, aspettati una richiesta di informazioni 2.1 e preparati. Prepara una breve registrazione del flusso principale e risposte scritte su pubblico, utilizzo, servizi esterni e regioni nelle note di revisione prima di inviare, così che la prima revisione non si blocchi per delle domande.

92. 

    Linea guida 2.5.4 Requisiti software (modalità background) iOS Revisione infinita

    Rifiutata per una casella rimasta spuntata, la modalità audio in background, e poi dieci giorni per l'aggiornamento successivo

    Cosa è successo

    Un piccolo team ha inviato un aggiornamento a un'app già live. App Review lo ha rifiutato in base alla linea guida 2.5.4 per una sola impostazione: la modalità audio in background era attiva nell'app, e l'app non ne aveva bisogno. Il team ha rimosso la modalità background e ha inviato di nuovo lo stesso giorno, perdendo circa un giorno. Il loro aggiornamento successivo è poi rimasto in revisione per circa dieci giorni.

    Risoluzione

    Ho rimosso l'audio background mode e ho reinviato lo stesso giorno. L'aggiornamento successivo è rimasto in review circa dieci giorni.

    Lezione

    I background modes sono consentiti solo per lo scopo previsto. Prima di ogni invio, apri la capability Background Modes e rimuovi tutto ciò che l'app non usa davvero: una checkbox dimenticata basta per un rifiuto, e non puoi prevedere quanto durerà la prossima review.

93. 

    Linea guida 4.3(a) Spam iOS Linea guida 4.3

    Una web app in un wrapper ha ricevuto un rifiuto per spam 4.3(a), così lo sviluppatore l'ha ricostruita come app nativa

    Cosa è successo

    Uno sviluppatore ha inviato la prima versione della sua app come web app dentro un wrapper nativo. L'App Review l'ha rifiutata in base alla guideline 4.3(a), la regola sullo spam. Lo sviluppatore ha ammesso che Apple aveva ragione. Ha ricostruito l'app come una vera app nativa, ha spostato il backend su un relay server gestito da lui e ha pubblicato il codice sorgente code.

    Risoluzione

    Ricostruita come app nativa con un server relay self-hosted. I risultati della versione ricostruita non sono stati condivisi nel post.

    Lezione

    Un wrapper sottile attorno a un sito web è facile da leggere come spam per l'App Review. Se pubblichi sull'App Store, offri all'app un valore nativo reale fin dalla prima submission, invece di sperare che un sito avvolto passi.

94. 

    Rifiuto per contenuto inappropriato (screenshot, poi sottotitolo) iOS Contenuti inappropriati Metadata e IAP

    Screenshot segnalati come inappropriati, poi il sottotitolo, per un gioco senza nulla di adulto

    Cosa è successo

    Un piccolo studio crea semplici giochi narrativi per iOS, senza temi adulti, gambling o crypto. Un gioco, in cui il giocatore è una celebrità che cerca di affermarsi a Hollywood, è stato rifiutato per contenuto inappropriato negli screenshot. Gli screenshot mostravano solo personaggi completamente vestiti del gioco. Lo studio ha sostituito ogni screenshot e ha risubmitto. Il rifiuto successivo era per contenuto inappropriato nel sottotitolo, che descriveva semplicemente il gioco come un gioco di vita e drammi da celebrità. Ogni review ha richiesto settimane.

    Risoluzione

    L'app è stata inviata per la prima volta a settembre e non era ancora stata approvata a fine ottobre.

    Lezione

    Quando App Review segnala i metadati come inappropriati senza dire il motivo, chiedi in App Store Connect quale sia l'elemento esatto che crea il problema e perché, prima di rifare tutto. Controlla insieme screenshot, sottotitolo e parole chiave prima di reinviare, perché sistemarne uno può far emergere il successivo.

95. 

    Linea guida 5.2.5 Legale, Proprietà intellettuale iOS Direttiva 5: Aspetti legali Metadata e IAP

    Rifiutata ai sensi della 5.2.5 perché gli screenshot mostravano un dispositivo che sembrava un iPhone

    Cosa è successo

    A uno sviluppatore è stata rifiutata un'app in base alla linea guida 5.2.5. App Review ha detto che i metadati contenevano immagini simili a un iPhone negli screenshot, che potevano confondere gli utenti con i prodotti Apple. I dispositivi mostrati non erano Apple, ma solo simili, e lo sviluppatore è rimasto sorpreso perché un'altra sua app era già stata approvata con lo stesso tipo di immagini di dispositivi.

    Risoluzione

    L'esito finale non è stato condiviso al momento della pubblicazione. Un altro sviluppatore, rispondendo, ha fatto notare che App Review può contestare anche cornici di dispositivo che non corrispondono alla piattaforma o render che sembrano diversi dai veri iPhone.

    Lezione

    L'approvazione di un'app non stabilisce un precedente per la successiva. I mockup di dispositivi che sembrano quasi un iPhone possono essere considerati simili ai prodotti Apple tanto da confondere. Usa screenshot semplici o solo cornici di dispositivo fornite da Apple per il marketing, assicurandoti che corrispondano alla piattaforma.

96. 

    Linee guida 2.1: Informazioni necessarie iOS Linea guida 2.1

    Prima app iOS: richiesta di informazioni 2.1, risolta rendendo tutto facilmente reperibile

    Cosa è successo

    Uno sviluppatore solo, la cui versione Android era già live su Google Play, ha inviato la sua prima app iOS. Conteneva tre acquisti in-app e contenuti generati dagli utenti. L'App Review non l'ha respinta subito, ma ha inviato una richiesta di informazioni ai sensi della linea guida 2.1. Lo sviluppatore ha riletto la linea guida 2.1, che richiede che ogni acquisto in-app sia visibile e funzionante per il revisore, e ha controllato anche le regole per i contenuti generati dagli utenti (1.2) e la cancellazione dell'account (5.1.1(v)). Il giorno successivo ha inviato una nuova build con un'opzione di segnalazione e blocco visibile su ogni contenuto utente, le regole della community che gli utenti accettano prima di pubblicare, il logout e il cambio account, e una registrazione dello schermo che mostra dove si trovano gli acquisti, gli strumenti di sicurezza e i controlli dell'account.

    Risoluzione

    Nuova build inviata il giorno dopo la richiesta. Esito non noto al momento della pubblicazione.

    Lezione

    Tratta la revisione come un test di usabilità con uno sconosciuto e poco tempo a disposizione. Ogni acquisto, opzione di segnalazione e blocco e controllo dell'account deve essere reperibile in pochi secondi, e una registrazione nelle note di revisione dovrebbe indicare ognuno di essi. Essere live su Google Play non dice nulla sul superamento dell'App Review.

97. 

    Linea guida 4.3(a) Design, Spam iOS Linea guida 4.3 Revisione infinita

    Ventisette giorni in coda per una nuova app, poi un rifiuto per spam 4.3(a)

    Cosa è successo

    Uno sviluppatore ha inviato un'app completamente nuova e ha aspettato 27 giorni che App Review la esaminasse. Quando il risultato è finalmente apparso in App Store Connect, era un rifiuto per la linea guida 4.3(a), Design, Spam. Lo sviluppatore ha poi chiesto ad altri sviluppatori se qualcuno fosse mai riuscito a superare un rifiuto 4.3(a).

    Risoluzione

    Al momento del post non era stata condivisa alcuna soluzione. Lo sviluppatore cercava consigli da chi avesse già affrontato un rifiuto 4.3(a).

    Lezione

    Un'attesa lunga non significa che l'app sia al sicuro. Con code di revisione così lente, un rifiuto 4.3(a) dopo settimane costa un intero mese. Prima di inviare una nuova app, sii onesto su ciò che la distingue dalle app già presenti nella stessa categoria e specificalo chiaramente nelle note di revisione e nei metadati.

98. 

    Linea guida 4.3(a) Design, Spam macOS Linea guida 4.3

    L'app per iPhone era già online, ma la versione per Mac è stata rifiutata come spam

    Cosa è successo

    Uno sviluppatore aveva già un'app iPhone pubblicata sull'App Store e aveva creato una versione desktop nativa per Mac. App Review ha rifiutato l'app per Mac citando la guideline 4.3(a). Il messaggio diceva che l'app condivideva binari, metadati o concetti simili con app inviate da altri sviluppatori, con solo differenze minime, e suggeriva di inviare un'app unica con contenuti e funzionalità distinti. Lo sviluppatore ha chiesto alla community cosa avesse funzionato per altri alle prese con il 4.3.

    Risoluzione

    Al momento del post non era stata condivisa alcuna soluzione.

    Lezione

    Ogni piattaforma ha la sua revisione e l'approvazione di un'app iPhone non vale per il Mac. Un messaggio 4.3(a) confronta la tua app con quelle di altri sviluppatori; quindi, quando rispondi, spiega concretamente cosa fa la tua app che le app simili non fanno, evidenziando le funzionalità esclusive.

99. 

    Revisione infinita iOS Revisione infinita

    Oltre quattordici giorni di revisione sono finiti con un rifiuto, e la nuova sottomissione ha dovuto aspettare altre due settimane

    Cosa è successo

    Un sviluppatore ha raccontato che la sua revisione precedente ha richiesto più di quattordici giorni ed è finita con un rifiuto. Ha inviato di nuovo il 21 ottobre e, quasi due settimane dopo, la submission era ancora in Waiting for Review, mentre Apple afferma che la maggior parte delle revisioni richiede da 24 a 48 ore.

    Risoluzione

    Ancora in attesa di revisione al momento della pubblicazione.

    Lezione

    I tempi medi di revisione non descrivono il caso peggiore, e un rifiuto ti rimanda in fondo a una coda lenta. Pianifica i lanci con settimane di margine e rendi la prima submission la più completa possibile, così un rifiuto non raddoppia l'attesa.

100. 

     Requisito di cancellazione dell'account (linea guida 5.1.1(v)) iOS Linea guida 5.1.1

     Rifiutato per mancata cancellazione dell'account, dopo che il primo revisore aveva già cancellato diversi account

     Cosa è successo

     Un developer con un'app basata su contenuti pubblici generati dagli utenti si è visto rifiutare l'app alla seconda review per l'eliminazione dell'account mancante. I log mostravano che durante la prima review il revisore aveva creato ed eliminato diversi account senza problemi. Il developer aveva l'impressione che il rifiuto dipendesse più dalla categoria severa che dall'assenza effettiva della funzionalità.

     Risoluzione

     Al momento del post non era stata condivisa alcuna soluzione.

     Lezione

     Anche quando una funzionalità funziona, il revisore deve trovarla in fretta. Inserisci il percorso di eliminazione dell'account nelle note per la review con gli schermi esatti da toccare e allega una breve registrazione. Per le app con contenuti generati dagli utenti, mostra anche segnalazione, blocco e moderazione, perché quelle categorie vengono esaminate più da vicino.

101. 

     Linea guida 2.1(a) Completezza dell'app macOS Linea guida 2.1

     App Mac rifiutata per la 2.1(a) per aver letto il keychain di login, e le note di rifiuto precedenti sono scomparse

     Cosa è successo

     Un developer ha inviato un'app Mac e App Review l'ha rifiutata per la linea guida 2.1(a), perché l'app leggeva dal login keychain. La correzione è arrivata con un solo update. Quello che ha colto di sorpresa il developer è stato App Store Connect stesso: mostra solo gli ultimi dieci invii, quindi i vecchi messaggi di rifiuto spariscono silenziosamente dalla cronologia.

     Risoluzione

     Risolto con un solo update. Ora il developer copia ogni messaggio di rifiuto nel commit che contiene la fix.

     Lezione

     Non fare affidamento su App Store Connect come storico dei rifiuti passati, perché gli invii più vecchi non sono più visibili. Salva il testo completo del rifiuto insieme alla fix, nel commit, nel ticket o nelle release notes, così da avere il testo esatto se lo stesso problema dovesse ripresentarsi.

102. 

     Guideline 1.4.1 Physical Harm (salute e ambito medico) iOS Revisione infinita

     Dieci giorni di review per un'app per la salute, poi un rifiuto 1.4.1 risolto con una pagina delle fonti in un pomeriggio

     Cosa è successo

     Un developer indie che stava sviluppando un'app per la salute ha aspettato più di dieci giorni per la revisione dell'App Store. Il verdetto è stato un rifiuto ai sensi della linea guida 1.4.1, che copre le app per la salute e mediche. La correzione era minima: il developer ha aggiunto una pagina delle fonti che cita da dove provengono le informazioni sanitarie nell'app, e ci è voluto un solo pomeriggio per implementarla.

     Risoluzione

     Ha aggiunto una pagina delle fonti con citazioni, impiegando un pomeriggio. Nel post non è stato detto se la nuova submission sia stata approvata.

     Lezione

     Le app per la salute sono soggette a standard più elevati, e un'attesa lunga può finire con una richiesta che avresti potuto soddisfare prima di inviare. Se la tua app mostra informazioni sanitarie o mediche, aggiungi citazioni chiare nell'app prima della prima submission. Un developer che è intervenuto ha notato che un promemoria visibile di consultare un medico è un'altra richiesta comune.

103. 

     Acquisto in-app troppo difficile da raggiungere per il revisore (numero di linea guida non specificato) iOS Metadata e IAP

     Un aggiornamento di un gioco rifiutato perché il paywall era troppo nascosto, poi approvato in 26 ore dopo aver spostato lo sblocco sulla schermata iniziale.

     Cosa è successo

     Un sviluppatore indie ha impiegato 33 giorni e due rifiuti per far approvare la versione 1.0 del suo gioco iOS. Anche il primo aggiornamento, 1.0.1, è stato rifiutato perché il paywall era troppo nascosto nel gioco per essere raggiunto dal revisore. Lo sviluppatore ha aggiunto un pulsante di sblocco nella schermata iniziale e ha risubito. Questa volta l'intero processo ha richiesto circa 26 ore, con solo circa 12 minuti effettivamente in revisione.

     Risoluzione

     Aggiunto un pulsante di sblocco nella schermata iniziale. L'aggiornamento è stato approvato circa 26 ore dopo la risubmissione.

     Lezione

     Un revisore non giocherà per venti minuti per trovare ciò che vendi. Metti ogni acquisto dove può essere raggiunto in pochi secondi, oppure descrivi il percorso esatto nelle note di revisione, così il revisore può testarlo senza doverlo cercare.

104. 

     Incongruenza dei metadati dell'In app purchase (numero della direttiva non specificato) iOS Metadata e IAP

     Rifiutato perché il paywall indicava 1 mese gratuito mentre Apple mostrava l'addebito annuale

     Cosa è successo

     Un developer è passato da settimane su TestFlight al lancio pubblico sull'App Store e ha avuto una build rifiutata a causa del paywall. Il paywall prometteva 1 mese gratis, ma la schermata di acquisto di Apple mostrava l'addebito annuale che iniziava lo stesso giorno. Il revisore non riusciva nemmeno a trovare il piano settimanale. Il developer ha corretto il testo del paywall e la visibilità dei piani, ha inviato un'altra build e ha atteso di nuovo la revisione.

     Risoluzione

     Corretto il paywall in modo che la dicitura del trial gratuito corrispondesse alla schermata di acquisto e il piano settimanale fosse raggiungibile. L'app è poi andata live sull'App Store.

     Lezione

     Ciò che il tuo paywall promette deve corrispondere a ciò che mostra la schermata di acquisto di Apple, inclusa la durata del trial e l'inizio della fatturazione. Metti ogni piano di cui il revisore ha bisogno per i test in un punto raggiungibile con un paio di tap, e verifica quel percorso su un'installazione pulita prima di inviare.

105. 

     Linea guida 2.1 Completezza dell'app (crash all'avvio) iOS Linea guida 2.1

     Un resubmit con fix di performance extra è crashato all'avvio e ha costato un giorno intero

     Cosa è successo

     Dopo un primo rifiuto dell'App Store che era solo una richiesta di informazioni, lo sviluppatore ha deciso di includere i fix di performance nella stessa nuova submission. Era così sicuro da rimuovere anche un gate hardware pensato per i dispositivi di fascia gaming. App Review ha rifiutato di nuovo la build perché andava in crash all'avvio, senza crash log, solo un messaggio automatico. Lo sviluppatore ha pensato a un kill di memoria, ha rimesso il gate e ha passato la giornata a ridurre gli asset, rimandare i caricamenti e liberare risorse senza perdere performance.

     Risoluzione

     Ha ripristinato il gate hardware, ridotto il footprint di memoria e preparato una terza submission per il giorno successivo. L'esito finale dopo il terzo round non è stato condiviso nel post.

     Lezione

     Non accumulare fix non correlati in una nuova submission pensata per rispondere a una richiesta della review. Rilascia la modifica più piccola che risponde al rifiuto, mantieni i gate di stabilità per il dispositivo meno recente che dichiari di supportare e fai un cold start su quel dispositivo prima di fare un nuovo upload.

106. 

     Linea guida 4.3(a) Spam di design iOS Linea guida 4.3

     Diversi piccoli giochi inviati insieme sono tutti incappati nella 4.3(a), poi due ricorsi sono stati accolti

     Cosa è successo

     Uno sviluppatore ha inviato diversi piccoli giochi all'App Store più o meno nello stesso periodo. Tutti sono stati rifiutati in base alla direttiva 4.3(a) per spam. Dopo quell'ondata ha cambiato processo e ora invia un solo gioco alla volta. Due di questi rifiuti sono stati successivamente annullati dopo un appello all'App Review Board.

     Risoluzione

     Passato a un invio alla volta. Due dei rifiuti 4.3(a) sono stati annullati in appello all'App Review Board.

     Lezione

     Raggruppare app simili nella stessa finestra di revisione porta a una segnalazione di spam su tutto il set. Invia un'app alla volta e, se un rifiuto 4.3(a) sembra ingiustificato, fai appello all'App Review Board spiegando chiaramente in cosa ogni app è distinta.

107. 

     Direttiva 1.1 Sicurezza, contenuti discutibili (metadati dell'app) iOS Contenuti inappropriati Metadata e IAP

     Un'app di recupero è stata rifiutata in base alla 1.1 perché il marketing citava l'abitudine che aiuta a smettere

     Cosa è successo

     Un'app creata per aiutare le persone a superare la pornografia e la lussuria è stata rifiutata ai sensi della linea guida 1.1. App Review ha dichiarato che il marketing dell'app faceva riferimento a contenuti inappropriati nei metadati, tra cui descrizione, screenshot e parole chiave. Quando lo sviluppatore ha chiesto dettagli, App Review ha indicato una parola chiave, porn, ha detto che l'elenco non era esaustivo, ha avvertito che l'app sarebbe stata sottoposta a una revisione completa alla nuova sottomissione e ha precisato che inviarla di nuovo con lo stesso marketing, o come nuova app con lo stesso concetto, avrebbe comportato le stesse violazioni o più. Lo sviluppatore ha fatto notare che app simili già presenti sullo store pubblicizzano apertamente l'aiuto contro la tentazione sessuale.

     Risoluzione

     Non risolto al momento del post. App Review ha chiesto di rimuovere ogni riferimento a contenuti inappropriati dai metadati prima di una nuova revisione completa, e lo sviluppatore ha contestato pubblicamente perché app simili venissero trattate in modo diverso.

     Lezione

     Le app che aiutano le persone a smettere con qualcosa di adulto vengono giudicate in base alle parole nel loro marketing, non alle loro intenzioni. Descrivi l'obiettivo, come il recupero o l'autocontrollo, invece di citare il vizio nelle parole chiave, nella descrizione e negli screenshot, e chiedi ad App Review quali termini esatti hanno fatto scattare il rifiuto prima di inviare di nuovo, perché il prossimo invio riceverà una revisione completa.

108. 

     Icona dell'app segnalata come inappropriata (numero della linea guida non specificato) iOS Contenuti inappropriati Metadata e IAP

     Un'icona dell'app già approvata è stata rifiutata per mostrare troppa pelle

     Cosa è successo

     Un'app AI utilizzava un personaggio illustrato come icona, con un crop top che mostrava parte del petto e dell'addome. La stessa icona aveva superato l'App Review in precedenza. In un successivo invio, Apple l'ha rifiutata perché petto e pancia erano troppo scoperti. Lo sviluppatore ha ridisegnato il personaggio con un top intero che copriva entrambe le aree e ha reinviato l'app.

     Risoluzione

     Ha ridisegnato l'icona in modo che il top coprisse il petto e l'addome. Il post non specificava quanto tempo ha richiesto la nuova revisione.

     Lezione

     Un'approvazione precedente non blocca la tua icona o gli screenshot, poiché ogni invio può essere valutato di nuovo. Se un personaggio nei tuoi disegni mostra la pelle, assumi che un revisore più severo potrebbe segnalarlo e tieni pronta una variante più coperta, così la correzione sarà un semplice scambio e non una ridisegnazione.

109. 

     Flusso di annullamento dell'abbonamento (numero della linea guida non indicato) iOS Metadata e IAP

     Rifiutata per un passaggio extra "sei sicuro?" al momento dell'annullamento, una settimana prima che Apple lanciasse i messaggi di retention

     Cosa è successo

     Un'app di abbonamento mostrava la propria schermata "sei sicuro?" quando gli utenti andavano ad annullare. App Review ha rifiutato l'app per questo. Meno di una settimana dopo, App Store Connect ha annunciato i messaggi di retention, che permettono agli sviluppatori di mostrare agli abbonati un messaggio, con un'immagine opzionale o un'offerta di retention, quando provano ad annullare l'abbonamento.

     Risoluzione

     Il post non diceva come è stato risolto il rifiuto. La nuova funzione di App Store Connect ora offre un modo approvato da Apple per mostrare un messaggio al momento dell'annullamento.

     Lezione

     Non aggiungere ostacoli tuoi prima dell'annullamento dell'abbonamento. Lascia che gli utenti raggiungano direttamente il flusso di annullamento e, se vuoi un'ultima possibilità per trattenerli, usa i messaggi e le offerte di retention di Apple invece di una schermata personalizzata.

110. 

     Linee guida 5.6 Developer Code of Conduct e 2.5.19 Funzionalità nascoste iOS Linea guida 5.6 Developer Code of Conduct Linea guida 2.5.19 Funzionalità nascoste

     Rifiutata per la 5.6 a causa di funzionalità nascoste che si sono rivelate un checkout code incluso in un abbonamento SDK

     Cosa è successo

     Un developer solitario ha visto la sua app iOS per il tracciamento degli obiettivi rifiutata sette volte prima del lancio. Un rifiuto precedente riguardava scommesse con denaro reale. L'ultimo è arrivato sotto la Developer Code of Conduct: l'App Review ha affermato che l'app conteneva funzionalità nascoste o fuorvianti e ha chiesto la rimozione di tutte le funzionalità nascoste, senza specificare quale. L'app non aveva flag di funzionalità remoti, nessun code scaricato e nessun comportamento speciale per i revisori. Invece di indovinare, lo sviluppatore ha scansionato il proprio binario di rilascio e ha trovato un checkout web code di un provider di pagamento che non aveva mai scritto. Era incluso nel loro SDK di abbonamento per quella piattaforma web SDK, e l'app iOS non lo utilizzava mai. Dato il precedente rifiuto per scommesse con denaro, lo sviluppatore ha sospettato che sembrasse un percorso di pagamento nascosto.

     Risoluzione

     Senza modificare alcun code, lo sviluppatore ha risposto ad App Review con semplici fatti: cosa fa e cosa non fa l'app, che non ci sono interessi finanziari reali, da dove proviene il code del checkout, che il SDK web code non utilizzato e un permesso per la libreria foto non utilizzato verranno rimossi nella prossima build, e una richiesta di specificare la schermata segnalata. Circa nove ore dopo, App Review ha dichiarato che avrebbe proseguito la revisione e l'app è andata live.

     Lezione

     Conosci tutto ciò che il tuo binario distribuisce, inclusi gli code che i tuoi SDK introducono per altre piattaforme, perché App Review giudica ciò che è nella build, non come lo chiami. Dopo un rifiuto 5.6, non indovinare e risubmettere. Rispondi con calma, con dettagli specifici e chiedi quale schermata o comportamento sia stato segnalato.

111. 

     Linea guida 2.3.4 Metadati accurati (Anteprime dell'app) iOS Metadata e IAP

     Un'Anteprima dell'app approvata a ottobre è stata rifiutata sotto la 2.3.4 per il suo framing un mese dopo

     Cosa è successo

     Uno sviluppatore ha inviato un aggiornamento per la sua app iOS e è stato rifiutato sotto la linea guida 2.3.4. App Review ha affermato che il video dell'Anteprima dell'app aveva un framing attorno alla cattura dello schermo. Lo stesso video era stato approvato il mese precedente. Lo sviluppatore ha sottolineato che altre app sullo store, inclusa una nota il cui anteprima mostra una persona anziché l'app, utilizzano Anteprime dell'app con poco o nessun footage dell'app stessa.

     Risoluzione

     Lo sviluppatore ha rimosso completamente il video di App Preview e ha risubito l'aggiornamento. Il post non specificava come è andata la nuova revisione.

     Lezione

     Un App Preview che ha superato la revisione una volta può comunque essere rifiutato in un aggiornamento successivo, poiché ogni submission viene riesaminata. Mantieni le anteprime come semplici screen capture dell'app, senza cornici decorative attorno alla cattura, e se una viene segnalata, rimuoverla è il modo più rapido per sbloccare l'aggiornamento mentre la riprogetti.

112. 

     Sezione 3.2(f) (Developer Program License Agreement) macOS Chiusura dell'account Revisione infinita

     Un aggiornamento macOS per correggere un problema di icone è rimasto in revisione per circa 45 giorni, poi è arrivata una notifica 3.2(f)

     Cosa è successo

     Uno sviluppatore indipendente aveva un'app per macOS che App Review aveva segnalato per problemi di branding. Il 15 settembre 2026, ha inviato un aggiornamento che affrontava il feedback, inclusa un'icona dell'app completamente ridisegnata. L'aggiornamento è poi rimasto In Review per circa 45 giorni senza una decisione, e lo sviluppatore ha inviato due richieste di revisione accelerata attraverso i canali ufficiali. Il 30 ottobre 2026, mentre quell'aggiornamento corretto era ancora in attesa, è arrivata una notifica di sospensione imminente dell'account sviluppatore ai sensi della sezione 3.2(f).

     Risoluzione

     Appello in sospeso al momento della pubblicazione. Lo sviluppatore ha presentato un appello formale e ha contattato separatamente il Developer Support, senza ricevere una risposta nel merito.

     Lezione

     Una correzione in coda non sospende l'applicazione delle regole sulle submission precedenti. Tieni un registro datato di ogni rifiuto, di ogni modifica fatta in risposta e di ogni richiesta di revisione accelerata, così un appello può mostrare esattamente cosa hai corretto e quando.

113. 

     Linea guida 3.2.2 Modelli di business inaccettabili iOS Linea guida 3.2.2

     Un'app a pagamento con sfide è stata rifiutata per la 3.2.2 e una chiamata con App Review ha confermato che l'intero modello era fuori

     Cosa è successo

     Un team che gestiva già un'app fitness con migliaia di utenti ha creato una seconda app iOS basata su sfide di passi a pagamento: gli utenti pagano una quota per partecipare a una sfida di camminata, lo stesso modello base di diverse app fitness già presenti sullo store. App Review l'ha rifiutata in base alla linea guida 3.2.2. La spiegazione era che qualsiasi modello basato su penalità non è consentito, indipendentemente dal fatto che gli utenti paghino prima dell'inizio della sfida o vengano addebitati dopo aver mancato l'obiettivo. Il team ha incontrato App Review per chiedere cosa modificare e si è sentito rispondere che il concetto stesso non era consentito, non una specifica schermata o un passaggio del flusso.

     Risoluzione

     Il team ha deciso di non fare appello perché non voleva mettere a rischio il proprio account sviluppatore. Al momento della pubblicazione, l'app non era presente sullo store e non capivano ancora perché altre app con lo stesso modello restassero attive.

     Lezione

     Le app simili già presenti sullo store non sono un precedente che App Review accetterà, poiché la tua build viene valutata in base a come la guideline viene interpretata oggi. Se il denaro cambia di mano in base al raggiungimento di un obiettivo da parte dell'utente, verifica quel modello rispetto alla 3.2.2 prima di costruire l'intero prodotto attorno ad esso, ad esempio chiedendo direttamente ad App Review.

114. 

     Linea guida 5.6 Developer Code of Conduct iOS Linea guida 5.6 Developer Code of Conduct

     Un aggiornamento rifiutato sotto la 5.6 per funzionalità nascoste ha ricevuto esattamente lo stesso rifiuto dopo una seconda revisione durata quasi tre settimane

     Cosa è successo

     Un sviluppatore ha inviato un aggiornamento per la sua app iOS e è stato rifiutato in base al Developer Code of Conduct. La notifica indicava che App Review aveva riscontrato un modello di comportamento insolito, comunemente associato ad attività fraudolente, in particolare funzionalità che sembravano essere state nascoste intenzionalmente durante la revisione. Lo sviluppatore ha dichiarato che nulla nell'app era nascosto e che non venivano utilizzati trucchi o comportamenti fuorvianti. Ha ricaricato l'app con una spiegazione dettagliata di ciò che fa, poi ha atteso quasi tre settimane per la seconda revisione. Il verdetto è stato lo stesso identico rifiuto, ancora una volta senza specificare alcuna funzionalità o schermata.

     Risoluzione

     Non risolto al momento della pubblicazione. Lo sviluppatore ha dichiarato che presenterà un ricorso.

     Lezione

     Una notifica generica 5.6 che non nomina alcuna funzionalità raramente viene superata con la stessa build più una spiegazione. Chiedi ad App Review nel thread quale schermata o comportamento sia stato segnalato, verifica cosa contiene ogni SDK nel tuo binario e usa il ricorso formale se le risposte non portano a nulla.

115. 

     Linea guida 4.3(a) Spam iOS Linea guida 4.3

     Un nuovo gioco di una serie indie è stato rifiutato in base a 4.3(a) per essere troppo simile ai giochi precedenti dello stesso sviluppatore

     Cosa è successo

     Un sviluppatore indipendente stava preparando il rilascio iOS di un nuovo gioco della propria serie, mentre lo traduceva anche in altre lingue. App Review ha rifiutato la versione iOS come spam ai sensi della linea guida 4.3(a), sostenendo che fosse troppo simile ai giochi precedenti dello sviluppatore. Lo sviluppatore aveva modificato profondamente il sistema di combattimento principale, ma ha ammesso che alcune parti riprese dalla serie, come l'interfaccia di base, le icone e il logo, sembravano ancora molto simili ai titoli precedenti. App Review ha inviato solo il messaggio di rifiuto standard e, una settimana dopo aver chiesto maggiori dettagli, lo sviluppatore non aveva ancora ricevuto risposta.

     Risoluzione

     Non risolto al momento della pubblicazione. Lo sviluppatore stava spiegando ad App Review cosa rende il nuovo gioco diverso dai titoli precedenti e ha dichiarato di non poter dire quando, o se, la versione iOS sarebbe uscita.

     Lezione

     Ai sensi della 4.3(a), il tuo stesso catalogo storico è il termine di paragone, quindi un sequel che riutilizza l'interfaccia, le icone e il branding dei giochi precedenti può sembrare un duplicato anche se il gameplay è cambiato. Rendi evidenti le novità nella build e negli screenshot, ed elencale nelle note per il revisore prima di inviare.

116. 

     Linee guida 5.2.5 e 2.3.10 iOS Direttiva 5: Aspetti legali Linea guida 2.3.10

     Un'app per creare screenshot per lo store è stata rifiutata perché la sua icona mostrava il logo dell'App Store

     Cosa è successo

     Un developer ha creato un'app che aiuta le persone a generare screenshot per App Store e Google Play. La sua prima build iOS è stata rifiutata per due linee guida. Secondo la 5.2.5, l'icona dell'app mostrava il logo di App Store accanto a quello di Google Play, e il sottotitolo nella scheda iniziava con le parole App Store. Secondo la 2.3.10, Google Play appariva nella build iOS stessa, nel binario, nell'icona e negli screenshot. Il developer aveva guardato quell'icona ogni giorno per settimane senza notare alcun problema.

     Risoluzione

     Il developer ha ridisegnato l'icona, riscritto il sottotitolo e aggiunto un interruttore che nasconde Google Play ovunque nella versione iOS, dall'onboarding all'export, fino alle impostazioni e ai messaggi di errore, lasciando intatti i progetti salvati e mantenendo entrambi gli store su Android. Ha spiegato la modifica in una riga nelle note di revisione. Al momento della pubblicazione, la seconda build era in attesa di revisione da almeno tre giorni.

     Lezione

     Apple revisiona l'icona e il sottotitolo con la stessa severità delle schermate. Anche se la tua app riguarda gli app store, tieni i marchi Apple fuori dall'icona e dalla scheda, e assicurati che nessun altro nome di store compaia da qualche parte nella build iOS, screenshot inclusi.

117. 

     In app purchase failure (guideline non specificata) iOS Metadata e IAP Revisione infinita

     Un gioco è stato rifiutato tre giorni dopo la data di lancio annunciata perché un acquisto è fallito mentre il revisore era offline

     Cosa è successo

     Un sviluppatore indipendente aveva già annunciato la data di uscita del suo gioco. La build è rimasta in revisione per poco più di una settimana e si è sbloccata solo dopo una richiesta di revisione accelerata. È stata infine rifiutata tre giorni dopo la data annunciata. Dallo screenshot allegato al rifiuto, risulta che il revisore non aveva connessione internet quando ha provato a effettuare un acquisto in-app. L'app mostrava un errore che segnalava il fallimento dell'acquisto, ma il messaggio era vago.

     Risoluzione

     Lo sviluppatore ha fatto appello e non ha ancora ricevuto risposta nemmeno un mese dopo. Nel frattempo ha ridisegnato l'interfaccia, riscritto i messaggi di errore per spiegare più chiaramente cosa è andato storto e pianificato di risottomettere la versione migliorata.

     Lezione

     Anche i revisori possono incontrare reti instabili. Prova ogni acquisto senza connessione e con una richiesta al store che fallisce, assicurandoti che l'app mostri un messaggio chiaro e un modo per riprovare. Evita di annunciare una data di lancio prima che la build sia approvata.

118. 

     Rifiuti per Crash, abbonamenti, EULA e paywall (numeri delle linee guida non specificati) iOS Linea guida 2.1 Direttiva 3.1.2 Revisione infinita

     Il primo app iOS ha richiesto 37 giorni e quattro rifiuti, con ogni revisione che segnalava un nuovo problema

     Cosa è successo

     Un sviluppatore ha inviato la sua prima app iOS, che vende abbonamenti, il 1° ottobre. Otto giorni dopo è stata rifiutata a causa di un crash. Ha risubito il giorno successivo e, circa due settimane dopo, è stata rifiutata per i problemi con gli abbonamenti. La risubmissione successiva è stata rifiutata due giorni dopo per la EULA. Il quarto rifiuto, il 5 novembre, riguardava i link sul paywall e le anteprime. Ogni ciclo ha fatto emergere un problema non menzionato nelle revisioni precedenti.

     Risoluzione

     Approvata il 7 novembre, 37 giorni dopo la prima submission. Lo sviluppatore era felice di lanciare, ma ha detto che la revisione potrebbe essere più veloce e trasparente per gli sviluppatori indie.

     Lezione

     Un rifiuto non elenca sempre tutti i problemi nel build. Prima della prima submission, verifica il lancio su un dispositivo reale, i dettagli dell'abbonamento, il link ai Termini di Servizio (EULA) e i link del paywall insieme, perché ogni round aggiuntivo può costare una settimana o più.

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