Guida metadata App Store

Checklist metadata App Store 2026

I metadata sono ricerca, promessa prodotto ed evidence di review. Ogni campo deve coincidere con il build inviato.

LaunchLint Academy

11 min di letturaRevisionato dal team editoriale di LaunchLint
Illustrazione di una scheda metadata tra build e pagina App Store
Nome, descrizione, URL, età e versione devono raccontare lo stesso build.
TL;DR

La risposta breve

  • App Store Connect separa proprietà generali e campi della versione, con regole differenti per modifica e localizzazione.
  • Confronta nome, sottotitolo, keyword, descrizione, screenshot, URL, età, review information e What's New con il build esatto.
  • Localizzare non è tradurre parola per parola: ricerca, promessa, immagini, supporto e testi legali devono funzionare nel mercato.
  • Prima dell’approvazione esegui una prova editoriale con una seconda persona e il build di produzione installato. La persona legge la pagina come un nuovo utente, apre supporto e privacy in una sessione anonima, cerca nell’app ogni beneficio dichiarato e verifica prezzi, requisiti, regioni e funzionalità premium. Ripeti il controllo per ogni lingua attiva: una traduzione completa può ancora contenere vecchi screenshot, keyword prive di intento locale o un URL destinato a un altro paese. Archivia poi uno snapshot di tutti i campi insieme a numero di build, data e responsabile. Quando cambiano una funzione, un SDK, l’età prevista, il modello di account o la disponibilità regionale, riapri la matrice invece di copiare automaticamente la release precedente. Questo processo trasforma i metadata in una prova verificabile: il team sa cosa ha ricevuto Apple, quale promessa era sostenuta dal prodotto e quale campo correggere in caso di domanda. I controlli automatici trovano limiti, collegamenti non validi e valori assenti, ma solo un confronto umano conferma che il significato della scheda coincide davvero con l’esperienza consegnata. Infine prova indicazioni per il team di verifica e credenziali su un dispositivo pulito: un testo perfetto non aiuta se il reviewer non può raggiungere la funzione descritta.
  • Verifica anche la coerenza dopo l’approvazione interna: apri l’anteprima completa in App Store Connect e confrontala con il file sorgente approvato. Controlla ordine degli screenshot, ritorni a capo, caratteri speciali, URL, categoria e territori. Salva le differenze come attività concrete prima dell’invio, senza correggere direttamente in console senza aggiornare la fonte editoriale. In questo modo la prossima release non eredita un valore manuale sconosciuto e ogni lingua rimane governabile.

1. Inventariare tutti i livelli

App Store Connect combina informazioni condivise e dati della versione. Nome, lingua, categoria e bundle non hanno lo stesso ciclo di screenshot, descrizione, supporto, What's New e indicazioni per il team di verifica. Considerarli un solo modulo nasconde blocchi.

Crea una matrice con owner, locale, fonte, data, approvazione e build rappresentato. Segna se pubblico, privato per review o derivato dal binario. Un cambio marketing non lascerà informativa sulla privacy, URL o credenziali vecchie.

Matrice:

  • App o versione
  • Pubblico o review
  • Localizzabile
  • Modifica per stato
  • Owner
  • Build

2. Nome, sottotitolo e categoria precisi

Apple limita attualmente nome e sottotitolo a 30 caratteri ciascuno. Devono identificare prodotto e valore senza catene di keyword, marchi terzi o funzioni assenti. Controlla Unicode, troncamento e significato locale.

Scegli la categoria per la funzione centrale. Confronta nome Store, nome installato, onboarding, supporto e informativa sulla privacy. Varianti inspiegate rendono ambiguo il servizio.

Controlli:

  • Limiti
  • Valore chiaro
  • Nessun marchio terzo
  • Categoria
  • Nome installato
  • Senso locale

3. Intento di ricerca senza spam

Nome, sottotitolo, keyword e developer aiutano la discovery. Prioritizza problema, attività e pubblico. Non ripetere parole forti e non usare concorrenti per impression irrilevanti.

Crea un set per lingua. La traduzione letterale spesso manca la query locale. Collega ogni termine a una funzione e messaggio visibile; senza prova può ridurre conversione e risultare ingannevole.

Review:

  • Problema
  • Task
  • Pubblico
  • Lingua locale
  • No ripetizioni
  • Funzione reale

4. Descrizione e Promotional Text allineati

Spiega risultato, percorsi e requisiti a chi non conosce l'app. Claim assoluti su anonimato, offline o tracking richiedono prove da SDK, backend e production.

Promotional Text può cambiare senza versione ma non annunciare funzioni assenti dal build pubblico. Separa messaggio stabile e campagna; verifica abbonamenti, hardware, link e regioni.

Copy:

  • Risultato
  • Limiti
  • Claim verificati
  • Premium
  • Nessun futuro
  • Test build

5. URL come superfici prodotto

Privacy URL apre una informativa sulla privacy pubblica e supporto porta ad aiuto reale. Prova logout, browser privato, mobile e rete esterna. Certificati, redirect, cookie wall o geoblocking possono fermare la review.

La pagina identifica app e responsabile e riflette pratiche correnti. Aggiornala con SDK, account, acquisti e cancellazione. Assegna monitoring e tempo di riparazione.

Preflight URL:

  • HTTPS
  • No VPN
  • App chiara
  • Contatto
  • Privacy attuale
  • Mobile

6. Età, diritti e regioni

L'età considera UGC, WebView, ads, salute, violenza, gioco e web aperto, non solo demo. Contenuti dinamici possono determinare la risposta.

Conferma diritti su marchi, musica, immagini e feed. Alcune regioni richiedono altro. Documenta ogni decisione e riaprila con cambi a moderazione, pubblico o fonti.

informativa sulla privacy:

  • UGC
  • WebView
  • Ads
  • Licenze
  • Pubblico
  • Regioni

7. Versione e What's New concreti

What's New nomina cambi visibili invece di ripetere miglioramenti. Non presentare experiment come garanzia. Collega versione, build, screenshot e release mode.

Review information offre account stabile, contatto e percorsi brevi. Spiega regione, ruolo, hardware, subscription o flag con risultato atteso.

Handoff:

  • Versione/build
  • Cambi
  • Release
  • Contatto
  • Credenziali
  • Condizioni

8. Preflight di una seconda persona

Una persona esterna apre ogni lingua, URL e screenshot, confronta il build e segue le Notes su device pulito. Trova ciò che un validator ignora.

Archivia snapshot, versione, build, data e approvazione. LaunchLint collega file del progetto e rischi ma senza accesso Store non certifica lo stato finale.

prove:

  • Lingue
  • Link
  • Claim
  • Ordine
  • Accesso
  • Snapshot

Domande frequenti

Limite nome e sottotitolo?

Apple documenta oggi 30 caratteri ciascuno. Verifica la fonte corrente.

Posso cambiare screenshot dopo approvazione?

Dipende da campo e stato; gli screenshot approvati richiedono normalmente una nuova versione.

Traduco le stesse keyword?

No. Cerca come il pubblico formula davvero la query nel mercato.

LaunchLint verifica tutta la console?

Solo con valori forniti o integrazione; il file del progetto non sostituisce il controllo finale.

Fonti ufficiali

Questo articolo usa le seguenti fonti primarie ufficiali. Le regole possono cambiare: verifica sempre la versione corrente prima dell’invio.