Screenshot rifiutati dall’App Store: perché e come evitarlo

Apple rifiuta gli screenshot dell’App Store quando non mostrano l’app in modo accurato, in base alla sezione 2.3 (Metadati accurati) delle linee guida per la revisione dell’App Store. I motivi più comuni sono screenshot che non mostrano l’app in uso (2.3.3), screenshot per iPad che in realtà sono immagini di iPhone allargate, immagini o nomi di altre piattaforme come Android (2.3.10), prezzi nell’immagine (2.3.7) e funzioni che l’app in realtà non ha (2.3 e 2.3.1). Uno screenshot rifiutato di solito mette l’app nello stato Metadati rifiutati, che risolvi in App Store Connect rispondendo ad App Review, senza una nuova build.

Qui sotto trovi ogni linea guida che riguarda gli screenshot, con le parole di Apple, i casi che vediamo più spesso, gli errori di caricamento che sembrano rifiuti ma non lo sono, e come rispondere.

Quali linee guida di App Review riguardano gli screenshot?

Stanno tutte nella sezione 2.3 delle linee guida per la revisione dell’App Store di Apple, che si apre così: “assicurati che tutti i metadati dell’app, comprese le informazioni sulla privacy, la descrizione, gli screenshot e le anteprime, riflettano accuratamente l’esperienza principale dell’app.” I punti numerati che contano per gli screenshot:

Per ragioni di spazio la tabella riassume; quando rispondi ad App Review cita il testo esatto della linea guida. I numeri delle linee guida ogni tanto cambiano, quindi prima di citarne una controlla la pagina aggiornata invece di un vecchio articolo di blog (compreso questo).

I motivi di rifiuto più comuni per gli screenshot

1. Lo screenshot non mostra l’app in uso (2.3.3)

La linea guida 2.3.3 dice: “Gli screenshot dovrebbero mostrare l’app in uso, e non semplicemente la schermata del titolo, la pagina di accesso o la schermata iniziale.” Ammette anche “sovrapposizioni di testo e immagini”, quindi uno screenshot progettato con didascalia, sfondo e cornice di dispositivo va benissimo. Quello che viene segnalato è uno screenshot in cui l’app manca o è ridotta a un pretesto: uno slogan su un gradiente, un logo, un modulo di accesso, un carosello di onboarding. Metti un’interfaccia vera e piena di contenuti in ogni screenshot, e cura in modo particolare il primo, perché è il più visibile (abbiamo parlato a parte di cosa mettere nel primo screenshot dell’App Store).

2. Screenshot per iPad che in realtà sono screenshot di iPhone (2.3.3)

È uno dei rifiuti che gli sviluppatori segnalano più spesso sui forum di Apple: lo slot iPad da 13 pollici è riempito con uno screenshot di iPhone allargato, con bordi aggiunti o messo dentro una cornice di iPad. App Review lo considera come non mostrare l’app in uso su iPad. La soluzione è catturare l’app mentre gira su un iPad (o nel simulatore di iPad Pro da 13 pollici) e costruire il set per iPad attorno a quelle catture. Se la tua app non supporta iPadOS, il set per iPad non ti serve proprio.

3. Altre piattaforme nell’immagine (2.3.10)

La linea guida 2.3.10 chiede di non “includere nell’app o nei metadati nomi, icone o immagini di altre piattaforme mobili o di marketplace di app alternativi, a meno che non ci sia una funzionalità interattiva specifica e approvata.” Negli screenshot di solito significa:

• Una cornice di telefono Android, o le barre di stato e di navigazione di Android, spesso perché hai riusato un set di Google Play
• Badge “Disponibile su Google Play” o una didascalia “Disponibile su Android”
• Interfaccia specifica di Android in un’app multipiattaforma catturata sul dispositivo sbagliato

Tieni set separati per ciascuno store. I generatori che li esportano entrambi da un unico progetto lo rendono facile; lo stesso vale per una convenzione di nomi in Figma.

4. Prezzi e affermazioni promozionali (2.3.7)

La linea guida 2.3.7 dice: “Metadati come nomi delle app, sottotitoli, screenshot e anteprime non dovrebbero includere prezzi, termini o descrizioni non specifici per quel tipo di metadato.” Didascalie come “Solo $2.99 al mese”, “Offerta di lancio: 50% di sconto” o un banner con il prezzo della prova gratuita sono casi tipici. Descrivi invece cosa fa l’app; i prezzi li mostra già l’App Store.

5. Funzioni che l’app non ha (2.3, 2.3.1)

Mockup di funzioni in arrivo, un design visibilmente diverso dall’interfaccia effettivamente pubblicata o una cattura da un’altra versione dell’app possono tutti essere considerati fuorvianti. La linea guida 2.3.1 cita espressamente il “promuovere contenuti o servizi che in realtà non offre”. Cattura gli screenshot dalla build che stai inviando.

6. Funzioni a pagamento mostrate senza dire che sono a pagamento (2.3.2)

La linea guida 2.3.2 chiede che “descrizione, screenshot e anteprime dell’app indichino chiaramente se elementi in evidenza, livelli, abbonamenti, ecc. richiedono acquisti aggiuntivi.” Se il tuo screenshot principale mostra una funzione Pro, una piccola etichetta “Pro” o “Premium” nell’interfaccia o nella didascalia, più una formulazione chiara nella descrizione, evita il problema.

7. Dati reali, contenuti su licenza e interfaccia non finita

La linea guida 2.3.9 chiede dati dell’account fittizi invece dei dati di una persona reale, e ti rende responsabile dei diritti su tutto ciò che mostri. Foto di celebrità, loghi di squadre sportive o locandine di film in un feed dimostrativo sono un rischio, a meno che tu non ne abbia i diritti. A parte questo, la linea guida 2.1 chiede che gli invii siano versioni definitive, senza testo segnaposto e altri contenuti provvisori, quindi menu di debug, “Lorem ipsum” e banner dell’ambiente di test non devono finire nemmeno negli screenshot. La nostra guida agli screenshot puliti da simulatore ed emulatore spiega come preparare dati demo e una barra di stato in ordine.

Errori di caricamento che non sono rifiuti

Alcuni problemi con gli screenshot non arrivano mai ad App Review, perché App Store Connect rifiuta il file già al caricamento. Si risolvono più in fretta, ma bloccano allo stesso modo.

Le specifiche degli screenshot di Apple elencano ogni dimensione accettata per gruppo di dispositivi, e il nostro riferimento sulle dimensioni degli screenshot raccoglie le più comuni in un’unica tabella.

Come rispondere al rifiuto di uno screenshot

1. Leggi il messaggio in App Store Connect

I dettagli del rifiuto compaiono nella sezione App Review della pagina della tua app in App Store Connect (molti sviluppatori la chiamano ancora Centro risoluzioni, il suo vecchio nome). Apple include il numero della linea guida e di solito una nota su quali screenshot e quale dimensione di dispositivo hanno causato il rifiuto. Leggilo con attenzione: “i tuoi screenshot per iPad da 13 pollici” e “i tuoi screenshot per iPhone” richiedono correzioni diverse.

2. Correggi i metadati, non la build

Per lo stato Metadati rifiutati, il riferimento sugli stati di Apple dice: “Leggi il messaggio di App Review, modifica i metadati per risolvere il problema e rispondi al messaggio di App Review.” Sostituisci gli screenshot segnalati in ogni localizzazione che li contiene; una correzione solo in inglese non risolve un problema che c’è anche nel tuo set in tedesco. Controlla anche le dimensioni ridimensionate in Gestione media.

3. Rispondi in modo breve e specifico

Di’ cosa hai cambiato e dove. Qualcosa del genere:

Thanks for the review. We've replaced the 13-inch iPad screenshots
in all 6 localizations with captures of the app running on iPad Pro
(13-inch). The previous images were scaled iPhone screenshots.
The build is unchanged.

4. Se non sei d’accordo, spiega o fai ricorso

Se pensi che il revisore abbia frainteso lo screenshot (per esempio, una funzione che non ha trovato è dietro un accesso), rispondi con i passaggi per raggiungerla e inserisci i dati di un account demo in Informazioni per la revisione dell’app. Se non basta, la pagina di App Review di Apple descrive il ricorso all’App Review Board: indica motivi specifici per cui l’app rispetta le linee guida, presenta un solo ricorso per ogni invio rifiutato e rispondi prima alle domande ancora aperte. Apple offre anche appuntamenti di 30 minuti con App Review per parlare delle linee guida prima dell’invio.

Una checklist prima dell’invio

• Ogni screenshot mostra un’interfaccia reale e piena di contenuti, presa dalla build che stai inviando
• Gli screenshot per iPad sono vere catture da iPad, oppure non ci sono perché l’app non supporta iPadOS
• Nessuna cornice Android, interfaccia di sistema Android, badge di Google Play o nome di altre piattaforme
• Nessun prezzo, sconto o prezzo della prova nelle immagini
• Le funzioni a pagamento sono indicate come tali da qualche parte nella scheda
• Le immagini sono adatte a un pubblico 4+ e ne hai i diritti
• I dati demo sono fittizi; niente testo segnaposto o interfaccia di debug
• Dimensioni in pixel esattamente tra quelle accettate, PNG o JPEG, senza trasparenza, fino a 10 per dimensione
• Correzioni applicate a ogni localizzazione, non solo alla lingua principale

Per i problemi di design che non ti fanno rifiutare ma ti costano installazioni, vedi gli errori comuni negli screenshot delle app, e per l’intero processo dalla build al caricamento, come creare gli screenshot per l’App Store.