· Publishing · 6 min di lettura
La checklist di pubblicazione: ogni asset per entrambi gli store (2026)
TL;DR. Il pre-flight completo per pubblicare su entrambi gli store. Due account sviluppatore (Apple 99 $/anno, Google 25 $ una tantum), poi per ogni store una pila di asset, testi e risposte legali — e le liste non coincidono. Gli screenshot sono una singola voce qui, non tutto il lavoro. Le regole che rifiutano una build prima ancora che un umano la veda sono i requisiti su SDK e target API, e il gate dei test chiusi di Google. Le date cambiano; verifica ognuna sui documenti Apple e Google il giorno in cui invii.
Hai costruito l'app. Ora entrambi gli store vogliono una pila di asset e risposte prima di lasciarti passare, e le due pile sono diverse. Questo è il superset: ogni asset e ogni campo richiesto da App Store Connect e Google Play Console, per store, con le regole di build 2026 che bloccano il caricamento ancora prima che inizi la review.
Abbiamo già una checklist dedicata solo agli screenshot (linkata in fondo). Questa è la lista più ampia — gli screenshot qui sono una singola voce, accanto a icone, feature graphic, testi della scheda, moduli sulla privacy, classificazioni per età e i requisiti di build che bloccano il caricamento stesso.
Requisiti e scadenze cambiano. Considera ogni regola datata qui sotto come un punto da verificare sulla documentazione ufficiale dello store il giorno dell'invio, non come un dato fisso.
Passo 0: i due account sviluppatore
Non puoi inviare nulla senza un account su ciascuno store, e hanno modelli di prezzo diversi:
- Apple Developer Program — 99 $ all'anno (USD, addebitati in valuta locale). È un abbonamento ricorrente. Se lo lasci scadere, le tue app spariscono dall'App Store finché non rinnovi.
- Google Play Console — 25 $, pagati una volta sola alla registrazione. Una tantum, non rimborsabile, nessun rinnovo.
- Verifica dell'identità in entrambi i casi. Sia gli account personali che quelli organizzativi passano per una verifica. Gli account organizzativi su Google richiedono un numero D-U-N-S; Apple verifica l'entità legale per l'iscrizione come organizzazione. Metti in conto qualche giorno per questo prima di pianificare la pubblicazione.
Apple: cosa chiede App Store Connect
La build:
- Binario dell'app costruito con un SDK aggiornato. Da aprile 2025, le app iOS e iPadOS devono essere compilate con l'SDK di iOS 18 (Xcode 16) o successivo per poter essere caricate. Apple ha annunciato che dal 28 aprile 2026 i caricamenti richiederanno l'SDK di iOS 26 o successivo — verifica quale SDK è in vigore alla data del tuo invio.
- Icona dell'app dentro la build. Apple estrae l'icona dal catalogo asset dell'app; non esiste un caricamento separato dell'icona in App Store Connect. Un'icona mancante o malformata fa fallire la validazione al caricamento.
- Bundle ID univoco, firma valida e risposte sulla conformità export. Le domande su crittografia/esportazione compaiono al caricamento — la maggior parte delle app risponde con un'esenzione standard, ma bisogna comunque rispondere.
Asset visivi:
- Screenshot per iPhone da 6,9 pollici. Almeno uno, fino a dieci. Le dimensioni accettate includono
1320 × 2868,1290 × 2796e1260 × 2736(verticale). Apple riduce automaticamente questo set per gli iPhone più piccoli, quindi il set da 6,5 pollici serve solo se salti del tutto il 6,9 pollici. - Screenshot iPad se l'app supporta iPad. Il set da 13 pollici è
2064 × 2752o2048 × 2732(verticale). Obbligatorio se la tua app gira su iPad. - Video App Preview facoltativo per ogni dimensione di dispositivo, 15–30 secondi.
Testi della scheda:
- Nome dell'app (fino a 30 caratteri) e sottotitolo (fino a 30).
- Parole chiave — un unico campo di 100 caratteri separati da virgola, che non compare mai agli utenti ma guida la ricerca.
- Descrizione (fino a 4.000 caratteri) e testo promozionale (fino a 170, modificabile senza una nuova build).
- URL di supporto, e un URL di marketing se lo desideri.
Legale, privacy e classificazione:
- URL della privacy policy. Obbligatorio per ogni app.
- Risposte App Privacy — l'"etichetta nutrizionale". Dichiari quali dati raccolgono la tua app e i suoi SDK di terze parti, e come vengono usati. Queste risposte sono obbligatorie per l'invio, e vengono mostrate come etichetta privacy sulla pagina del prodotto.
- Classificazione per età. Si risponde tramite un questionario. Apple è passata a un sistema di classificazione più granulare (con fasce 13+, 16+ e 18+) visibile sui dispositivi con iOS 26 e successivi, quindi ricontrolla le tue risposte se hai classificato un'app l'ultima volta con lo schema precedente.
- Categoria principale (e una secondaria facoltativa), più un percorso di eliminazione account in-app se la tua app supporta la creazione di account.
Google: cosa chiede Play Console
La build:
- Un Android App Bundle (.aab), non un APK, per le nuove app.
- Target API level. Le nuove app e gli aggiornamenti devono attualmente puntare almeno ad Android 15 (API level 35). Google ha annunciato che dal 31 agosto 2026 nuove app e aggiornamenti dovranno puntare ad Android 16 (API level 36) — verifica il livello in vigore quando invii.
- Build di release firmata, tipicamente tramite Play App Signing.
Asset visivi:
- Icona dell'app — 512 × 512 px, PNG a 32 bit, sotto 1 MB.
- Feature graphic — 1024 × 500 px, JPEG o PNG a 24 bit senza alfa. È un asset obbligatorio su Play, senza equivalente su Apple, ed è il banner mostrato in cima alla scheda.
- Almeno 2 screenshot per telefono (fino a 8). JPEG o PNG a 24 bit, ogni lato tra 320 e 3.840 px, rapporto d'aspetto 16:9 o 9:16. Gli screenshot per tablet e altri form factor sono facoltativi a meno che tu non ti rivolga a quei dispositivi.
- Video promozionale facoltativo come URL YouTube.
Testi della scheda:
- Nome dell'app (fino a 30 caratteri).
- Descrizione breve (fino a 80) — la prima riga che leggono gli utenti.
- Descrizione completa (fino a 4.000).
Legale, privacy e classificazione:
- URL della privacy policy. Obbligatorio.
- Modulo sulla sicurezza dei dati. L'equivalente Google dell'etichetta privacy Apple — dichiari quali dati raccogli, con chi li condividi e come vengono gestiti. Obbligatorio prima di poter pubblicare, e deve corrispondere al comportamento reale della tua app.
- Questionario sulla classificazione dei contenuti (IARC). Genera classificazioni per età specifiche per regione dalle tue risposte.
- Categoria dell'app, più dichiarazioni su pubblico target e pubblicità. Se anche solo una parte del pubblico è composta da minori, si applicano requisiti aggiuntivi.
Le regole 2026 che rifiutano una build prima della review
Non sono questioni di rifinitura — bloccano del tutto il caricamento o la release, quindi vale la pena verificarle per prime:
- L'SDK minimo di Apple. I caricamenti richiedono l'SDK di iOS 18 (Xcode 16) da aprile 2025, con l'SDK di iOS 26 che diventerà la soglia minima intorno al 28 aprile 2026 secondo l'annuncio di Apple. Se compili con un SDK vecchio, App Store Connect rifiuta il binario al caricamento.
- Il target API level di Google. Oggi le nuove app e gli aggiornamenti puntano ad Android 15 (API 35), con il passaggio ad Android 16 (API 36) dal 31 agosto 2026 secondo il calendario dichiarato da Google. Un target level troppo basso blocca la release.
- Il gate dei test chiusi di Google per gli account personali. Gli account sviluppatore personali creati dopo il 13 novembre 2023 devono eseguire un test chiuso con almeno 12 tester iscritti per 14 giorni consecutivi prima di poter richiedere l'accesso alla produzione. (Google ha abbassato questa soglia da 20 tester a fine 2024.) Gli account organizzativi verificati sono esenti. Questo è quello che sorprende di più gli sviluppatori solo — aggiunge almeno due settimane tra "l'app è pronta" e "l'app è live", quindi avvia il test chiuso presto.
Il pre-flight condiviso (entrambi gli store)
Alcuni controlli valgono per entrambi e sono facili da saltare nella fretta di pubblicare:
- Didascalie degli screenshot nella lingua di ciascun locale. Didascalie in inglese in una scheda tedesca o giapponese vengono segnalate. La lingua delle didascalie deve corrispondere al locale della scheda.
- Asset e testi coerenti con l'app. Se uno screenshot o una descrizione mostra una funzionalità, l'app pubblicata deve averla davvero. Entrambi gli store rifiutano metadati che sopravvalutano l'app.
- Nessun prezzo o URL fuori store impresso negli screenshot. I prezzi vanno sulla pagina dello store, non nell'artwork; le overlay tipo "visita il nostro sito" attirano rifiuti.
- Le dichiarazioni sulla privacy corrispondono alla realtà. Sia l'etichetta privacy Apple che il modulo Data safety di Google devono riflettere ciò che il tuo codice e i tuoi SDK fanno davvero.
- Un account di test funzionante, se l'app è protetta da login, consegnato al revisore nelle note di revisione.
Dove si inserisce Mokbi
La maggior parte di questa checklist tocca a te — l'account, la build, le risposte sulla privacy, le classificazioni. Mokbi copre gli asset visivi e testuali, ovvero la parte che consuma più ore quando la fai a mano per due store e molte lingue.
- Gli asset visivi. Produce gli screenshot per entrambi gli store nelle dimensioni richieste, e la feature graphic di Play, da un unico progetto — così non ritagli lo stesso artwork per ogni classe di dispositivo.
- Il testo della scheda. Redige nome, sottotitolo, descrizione e descrizione breve, poi traduce l'intera scheda in 50 lingue in modo che ogni locale venga pubblicato con didascalie e testi coerenti.
- La pubblicazione della scheda finita. Mokbi invia gli asset e i testi finiti al posto tuo: direttamente su Google Play tramite la Play Developer API, e messi in stand-by su App Store Connect come versione pronta per il tuo invio. Apple richiede che l'ultimo passo di invio e revisione lo faccia tu — è una regola di Apple, non un limite di Mokbi.
Il punto non è sostituire la checklist — è togliere da lì le colonne di asset e traduzione, così il resto diventa un pomeriggio più corto.