# Guideline 2.3.3: screenshot rifiutati da Apple > Guideline 2.3.3: più della metà degli screenshot deve mostrare la vera schermata dell'app in uso. Si corregge senza un nuovo build. Pagina originale: [Guideline 2.3.3: screenshot rifiutati da Apple](https://devoria.fr/it/blog/guideline-2-3-3-screenshot-rifiutati-apple) Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi) Pubblicazione: 2026-11-04 Ultima revisione dei contenuti: 2026-11-04 Un rifiuto «Guideline 2.3.3 - Performance - Accurate Metadata» significa che per Apple i tuoi screenshot non mostrano l'app mentre fa il suo lavoro. **La regola ha un numero preciso: per ogni tipo di dispositivo, più della metà degli screenshot deve mostrare la vera schermata dell'app in uso.** Il rifiuto riguarda la scheda, non il binario: sostituisci gli screenshot e rimandi lo stesso build. Mi è successo il 27 ottobre 2026 con Vigie, la mia app di monitoraggio ASO. I miei screenshot mostravano card d'interfaccia ridisegnate attorno a una mascotte, senza telefono. Apple li ha rifiutati. Questa guida riprende il messaggio ricevuto, cosa intende Apple con «app in use», cosa passa e cosa no, poi la checklist che applico da allora. Le regole citate vengono dalle pagine ufficiali di Apple, rilette il 3 novembre 2026. ## Il messaggio di Apple, parola per parola Il messaggio inizia con il titolo della regola, poi indica la dimensione di dispositivo interessata. Per Vigie, la frase che motivava il rifiuto era questa: ```text The 6.7-inch iPhone screenshots do not show the actual app in use. ``` Altri rifiuti 2.3.3 spiegano nel dettaglio cosa si aspetta il reviewer. Questo è stato [pubblicato sui forum di Apple](https://developer.apple.com/forums/thread/765166) a ottobre 2024 da uno sviluppatore i cui slot iPad mostravano una cornice di iPhone. Ecco il passaggio che elenca i requisiti, parola per parola: ```text Some or all of the provided screenshots do not sufficiently show the app in use. Screenshots should highlight the app's core concept to help users understand the app's functionality and value. - Marketing or promotional materials that do not reflect the UI of the app are not appropriate for screenshots. - The majority of the screenshots should highlight the app's main features and functionality. - Confirm that the app looks and behaves identically in all languages and on all supported devices. - Make sure that the screenshots show the app in use on the correct device, unless they are included to demonstrate that the app can be used on multiple Apple platforms. For example, iPhone screenshots should be taken on iPhone, not on iPad. ``` In italiano: un visual pubblicitario che non mostra l'interfaccia dell'app non va messo tra gli screenshot. La maggior parte deve mostrare le funzioni principali. E ogni screenshot mostra il dispositivo giusto: uno screenshot di iPhone si fa su iPhone, non su iPad, tranne quando serve a mostrare che l'app funziona su più piattaforme Apple. ## Cosa intende Apple con «app in use» Il testo della [guideline 2.3.3](https://developer.apple.com/app-store/review/guidelines/#2.3.3) è breve: «Screenshots should show the app in use, and not merely the title art, login page, or splash screen.» Gli screenshot devono mostrare l'app in uso, non solo il logo, la schermata di login o la schermata di avvio. Lo stesso testo permette testi e immagini aggiunti sopra. La [pagina di aiuto App Review sulla 2.3.3](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) spiega come viene fatta la valutazione. Apple valuta la serie di ogni tipo di dispositivo, e approva solo se più della metà degli screenshot mostra l'app in uso. Ogni lingua viene valutata a parte. La pagina elenca anche cosa evitare: - **screenshot che mostrano solo una pagina di login o una schermata di avvio**; - **un'interfaccia che non corrisponde a quella reale**, o un visual pubblicitario ingannevole; - **grafiche che schiacciano l'app**, o solo l'hardware, senza interfaccia dietro. **In pratica, «in uso» significa: l'interfaccia reale del tuo build, con dei contenuti, mentre fa quello per cui si scarica l'app.** Un titolo breve sopra una schermata vera resta uno screenshot in uso. ## Quanti screenshot devono mostrare l'app Apple fa due esempi: con tre screenshot, due devono mostrare l'app. Con quattro, tre. Il resto si ricava dalla stessa regola, più della metà. | Screenshot inviati | Minimo in uso | Visual marketing possibili | | ------------------ | ------------- | -------------------------- | | 1 | 1 | 0 | | 2 | 2 | 0 | | 3 | 2 | 1 | | 4 | 3 | 1 | | 5 | 3 | 2 | | 6 | 4 | 2 | | 8 | 5 | 3 | | 10 | 6 | 4 | Il conteggio si fa per tipo di dispositivo e per lingua. Basta un solo screenshot per dispositivo, se mostra l'app in uso. Secondo le [specifiche degli screenshot](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), Apple richiede almeno uno screenshot per l'iPhone con Dynamic Island a schermo medio, e ne accetta fino a 10 per dimensione. Se la tua interfaccia è uguale su tutte le dimensioni e in tutte le lingue, basta la risoluzione più alta richiesta: App Store Connect la riduce per le dimensioni più piccole. Le dimensioni esatte sono in [la dimensione degli screenshot App Store](https://devoria.fr/it/blog/dimensioni-screenshot-app-store). ## Cosa passa e cosa no | Screenshot | Esito | Cosa decide | | ------------------------------------------------ | ------------------------ | ----------------------------------------------------------------------------------- | | Schermata vera dell'app, titolo breve sopra | Passa | Il testo aggiunto è permesso dalla 2.3.3 | | Schermata vera dentro un iPhone | Passa | L'interfaccia reale, sul dispositivo giusto | | Solo logo, schermata di avvio o login | Rifiutato | Citato parola per parola dalla regola | | Visual marketing senza interfaccia | Tollerato in minoranza | Solo se la maggioranza mostra l'app | | Card d'interfaccia ridisegnate, senza l'app | Rifiutato | Il mio rifiuto del 27 ottobre 2026 | | Schermata in mockup che non esiste nel build | Rifiutato | Interfaccia che non corrisponde a quella reale | | Telefono vuoto o sfondo senza interfaccia dietro | Rifiutato | Elencato tra le cose da evitare | | Screenshot di iPhone negli slot iPad | Rifiutato | Il dispositivo sbagliato, secondo il rifiuto del forum | | Immagine che si estende su due screenshot | Passa | Permesso, finché l'app resta visibile | | Barra di stato di un'altra piattaforma | Rifiutato, per la 2.3.10 | Apple rimanda alla [guideline 2.3.10](https://devoria.fr/it/blog/guideline-2-3-10-app-rifiutata-metadati) | Apple non impone una cornice di telefono. Uno screenshot a schermo intero dell'app basta. La cornice ha un pregio: rende evidente, al primo sguardo, che l'immagine è l'app. ## Il mio caso: Vigie rifiutata il 27 ottobre 2026 Per la versione 1.1 di Vigie avevo seguito una moda degli studi di screenshot: un affresco continuo, una mascotte e card d'interfaccia fluttuanti al posto di un telefono intero. Le card erano ridisegnate per l'occasione, con app fittizie. Era carino. Non era l'app. Il reviewer ha scritto che gli screenshot dell'iPhone da 6,7 pollici non mostravano l'app in uso. Non ho contestato: aveva ragione. Ho rifatto tutta la serie con una regola semplice: 1. **Ogni pannello mostra un iPhone con uno screenshot nativo del simulatore**, incollato al pixel, senza ritoccare l'interfaccia. 2. **Una card ingrandita compare solo in aggiunta al telefono**, mai al suo posto, ed è ritagliata da quello stesso screenshot. 3. **Lo sfondo resta intorno**, mai sopra lo schermo. Questo rifiuto non richiedeva nessun nuovo build. Ho sostituito gli screenshot e rimandato la stessa versione la sera stessa. Poi ho cambiato build per correggere un titolo nell'app, niente a che vedere con gli screenshot. Vigie 1.1 era in vendita il 29 ottobre con questa serie. > Una card ridisegnata, anche se fedele, non è l'app. Il reviewer vuole vedere la schermata che l'utente avrà tra le mani. ## Correggere senza un nuovo build 1. **Leggi tutto il messaggio.** Dice quale dimensione di dispositivo è interessata, a volte quale lingua. Tutte le serie coinvolte vanno cambiate, non solo la prima. 2. **Rifai gli screenshot dal build inviato.** Simulatore o dispositivo, con contenuti reali. Più della metà in uso, per ogni dispositivo e ogni lingua. 3. **Sostituisci gli screenshot in App Store Connect.** Secondo [l'aiuto sulla gestione degli asset](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets), si può fare quando l'app è in uno di questi stati: Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected o Developer Rejected. 4. **Rimanda, in base allo stato mostrato.** Per Metadata Rejected, la [tabella degli stati](https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses) dice: leggi il messaggio, correggi i metadati, poi rispondi al messaggio di App Review. Se l'invio mostra Unresolved Issues, segui [la procedura di Apple](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/manage-a-submission-with-unresolved-issues/): in Apps, View App Review Issues & Messages, poi Resolve, Edit sull'elemento rifiutato, Add for Review e infine Resubmit to App Review. 5. **Non toccare più gli screenshot dopo l'invio.** Secondo la stessa tabella degli stati, in Waiting for Review non puoi né caricare né modificare screenshot. Ogni elemento rifiutato si modifica una sola volta prima del nuovo invio: controlla la nuova serie prima di cliccare. La risposta che scriverei al reviewer, in inglese: ```text Hello App Review team, Thank you for your feedback regarding Guideline 2.3.3. We replaced the [6.9-inch iPhone] screenshots in all localizations. Each screenshot now shows the actual app interface, captured from the submitted build: [main screen], [key feature], [result screen]. The build is unchanged. Best regards, [Your name] ``` Il tono e la forma di una buona risposta sono spiegati in [rispondere ad App Review](https://devoria.fr/it/blog/resolution-center-apple-rispondere-rifiuto-app-review). ## La checklist prima di inviare gli screenshot - Più della metà degli screenshot di ogni tipo di dispositivo mostra la schermata vera, con contenuti. - La stessa regola vale in ogni lingua, non solo in inglese. - Nessuno screenshot mostra solo il logo, la schermata di avvio o il login. - L'interfaccia mostrata esiste identica nel build inviato. - Titoli e sfondo lasciano leggibile l'interfaccia. - Gli screenshot di iPhone sono fatti su iPhone, quelli di iPad su iPad. - Nessuna traccia di un'altra piattaforma, nemmeno nella barra di stato. - Se la tua app ha una modalità scura, uno screenshot la mostra: lo consiglia la pagina di aiuto di Apple. - I file sono in JPEG o PNG, senza trasparenza. Apple ricorda anche, nella sua [pagina sulla scheda prodotto](https://developer.apple.com/app-store/product-page/), che i primi screenshot possono comparire nei risultati di ricerca. **Per me, uno screenshot che mostra chiaramente l'app al lavoro vende meglio di uno slogan.** Gli altri motivi di rifiuto della scheda sono in [perché Apple rifiuta un'app](https://devoria.fr/it/blog/app-rifiutata-da-apple-perche-casi-reali). ## Screenshot che passano al primo colpo L'[App Store Screenshots Kit](https://devoria.fr/it/kits/app-store-screenshots) raccoglie i miei modelli e lo skill che crea i tuoi screenshot dalle schermate vere della tua app, nelle dimensioni richieste da Apple. Se la tua scheda è appena stata rifiutata, il [Review Kit](https://devoria.fr/it/kits/app-review) contiene la mia checklist prima dell'invio, i miei rifiuti corretti e i modelli di risposta al reviewer. Il percorso completo è nella pagina [app rifiutata da Apple](https://devoria.fr/it/expertise/app-rifiutata-da-apple). Se stai preparando la tua prima uscita, [fai la tua diagnosi gratuita](https://devoria.fr/it/diagnostic): rimette in ordine i passaggi e ti manda la mia checklist anti-rifiuto Apple. ## Domande frequenti ### Cosa significa «Guideline 2.3.3 - Performance - Accurate Metadata»? È il titolo del rifiuto per screenshot che non mostrano l'app in uso. Apple ritiene che troppi screenshot siano visual marketing, schermate di avvio o interfacce che non sono quelle dell'app. Il messaggio spesso indica la dimensione di dispositivo interessata. ### Serve un nuovo build dopo un rifiuto 2.3.3? No. Il rifiuto riguarda la scheda App Store. Sostituisci gli screenshot in App Store Connect, poi rimandi la stessa versione rispondendo al messaggio di App Review. ### Quanti screenshot devono mostrare l'app in uso? Più della metà, per ogni tipo di dispositivo e in ogni lingua. Con tre screenshot, due devono mostrare l'app. Con quattro, tre. Basta un solo screenshot se mostra l'app in uso. ### Si può mettere testo marketing sugli screenshot App Store? Sì. La guideline 2.3.3 permette testi e immagini aggiunti sopra. Non devono nascondere l'interfaccia, e la maggioranza degli screenshot deve comunque mostrare l'app in uso. ### Serve una cornice di iPhone attorno agli screenshot? No, Apple non la richiede: uno screenshot a schermo intero dell'app passa. La cornice aiuta chi guarda a capire che l'immagine è l'app. Deve essere quella del dispositivo giusto: mai una cornice di iPhone su uno screenshot destinato all'iPad. ### Si possono modificare gli screenshot mentre l'app aspetta la review? No. Nello stato Waiting for Review, App Store Connect non permette né di caricare né di modificare screenshot. Per cambiarli, ritira l'invio dalla review o aspetta la decisione. ## Il tuo progetto [Review Kit](https://devoria.fr/it/kits/app-review): La mia checklist per la review dell'App Store, i rifiuti di Apple che ho risolto, quella di Google Play e tre skill per Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone e Android con Claude Code: il codice di partenza delle mie app, il percorso fino agli store e tutti i kit. 99 €. [Diagnosi: cosa ti separa dalla tua app per iPhone](https://devoria.fr/it/diagnostic): 7 domande, 60 secondi: scopri cosa ti blocca davvero nel pubblicare la tua app per iPhone, il tuo percorso in 4 tappe e il kit giusto per te.