Rifiuti metadati App Store: come risolvere 2.3.x, 2.3.7, 4.3 e 5.2.1
Ti è appena arrivata l'email. Lo stato è passato a Metadata Rejected e la nota del Resolution Center cita un numero di linea guida che hai dovuto cercare. La buona notizia è che un rifiuto per metadati è tra i più veloci da risolvere: non devi ricaricare una build, devi modificare la scheda della versione e reinviare.
La prima cosa da controllare è il numero di linea guida nel messaggio del Resolution Center, perché ti dice esattamente quale campo correggere. Questo articolo copre le quattro linee guida che è più probabile incontrare in un rifiuto della scheda. I numeri delle linee guida cambiano nel tempo, quindi quelli qui riportati riflettono le App Store Review Guidelines attuali.
Prima di tutto: cosa significa davvero "Metadata Rejected"
Uno stato Metadata Rejected punta alla tua scheda sullo store — nome dell'app, sottotitolo, keyword, descrizione, screenshot, anteprime, URL — non all'app compilata. Poiché la segnalazione riguarda i metadati, non serve un nuovo binario. Modifichi il campo citato in App Store Connect, mantieni la build esistente collegata alla versione e reinvii.
Vale la pena chiarire due cose. Primo, il reinvio ti rimette comunque in coda per la review, quindi non serve una nuova build ma non eviti una nuova revisione — un revisore umano o automatico la riesamina. Secondo, correggere il singolo campo citato da Apple non mette al riparo il resto della scheda. I revisori possono segnalare un'altra linea guida al passaggio successivo. Sistema tutta la scheda mentre ci sei, non solo la frase che ti hanno riportato.
Linea guida 2.3.3 — gli screenshot devono mostrare l'app in uso
Cosa la fa scattare. I tuoi screenshot non mostrano l'app all'opera. Il caso classico è un primo slot che è una splash screen, una pagina di login, o un'illustrazione con uno slogan e nessuna interfaccia vera. Scatta anche quando uno screenshot mostra una funzione che l'app non ha, o fa riferimento a un dispositivo o un'interfaccia di un'altra piattaforma.
Prima: lo slot uno è il tuo logo centrato su un gradiente con la scritta "il modo più intelligente di organizzare la tua settimana", senza alcuna interfaccia dell'app.
Dopo: lo slot uno è una schermata reale di un flusso principale — una vista settimanale con voci effettive inserite — con una breve didascalia che indica il vantaggio sopra il dispositivo. I revisori (e gli utenti) capiscono cosa fa l'app dalla miniatura. Mantieni le didascalie promozionali e le cornici del dispositivo, ma assicurati che l'interfaccia sottostante sia autentica e aggiornata.
Questa è una modifica ai metadati: sostituisci le immagini nella scheda della versione, reinvia, nessuna nuova build.
Linea guida 2.3.7 — le keyword devono descrivere la tua app, non fare da esca alla ricerca
Cosa la fa scattare. È la linea guida sull'uso improprio delle keyword. Scatta quando i tuoi metadati sono riempiti di termini che non descrivono la tua app: marchi che non possiedi, i nomi di app più grandi o popolari, informazioni sul prezzo nel campo sbagliato, nomi di celebrità o figure pubbliche inseriti per visibilità, o frasi generiche infilate per intercettare ricerche. Il campo keyword da 100 caratteri è il punto più critico, ma anche sottotitolo e nome vengono segnalati. I nomi delle app sono limitati a 30 caratteri, e il linguaggio su prezzo o promozioni non ha posto nel nome, nel sottotitolo o negli screenshot.
Prima (campo keyword): un elenco che include i nomi di tre app più grandi nella tua categoria, il nome di un creator noto e un paio di parole di tendenza non correlate, nessuna delle quali descrive una funzione che hai effettivamente realizzato.
Dopo: keyword che corrispondono a ciò che un utente cercherebbe davvero per trovare la tua funzione — i compiti che svolge, il problema che risolve, i sostantivi tratti dalle tue stesse schermate. Ogni termine dovrebbe indicare qualcosa che l'app fa realmente.
Prima (sottotitolo): una frase di confronto che ti posiziona rispetto a un'app rivale specifica.
Dopo: un sottotitolo che indica in termini semplici il risultato che la tua app offre, senza il nome di nessun altro brand. Il sottotitolo serve a dare contesto sulla tua app, non a intercettare il traffico di qualcun altro.
Linea guida 4.3 — spam e app quasi duplicate
Cosa la fa scattare. La 4.3 riguarda la somiglianza. Scatta quando pubblichi più app quasi identiche con bundle ID separati (una build diversa per città, per team, per cliente, invece di un'unica app con quelle varianti al suo interno), oppure quando un invio è difficile da distinguere da qualcosa già ampiamente disponibile. Spesso è un problema concettuale, ma è la scheda a rendere visibile la duplicazione — descrizioni e screenshot identici tra le tue app sono un segnale evidente.
Prima: cinque app nel tuo account con lo stesso layout, lo stesso elenco di funzioni, e testi che differiscono solo per il nome di una città o di un team.
Dopo: un'unica app che gestisce quelle varianti come opzioni o acquisti in-app, con una scheda che descrive ciò che è davvero distintivo. Se hai davvero prodotti separati, fai in modo che ogni scheda mostri cosa è effettivamente diverso negli screenshot e nella descrizione, non solo un trova-e-sostituisci su un nome proprio.
La 4.3 può richiedere più di una modifica ai metadati se l'app sottostante è davvero un clone superficiale. Ma dove il problema è che le tue schede sembrano cloni l'una dell'altra, differenziare testo e screenshot è una correzione ai metadati.
Linea guida 5.2.1 — proprietà intellettuale altrui nei tuoi metadati
Cosa la fa scattare. Usare materiale di terzi protetto senza averne i diritti — marchi, opere protette da copyright, nomi imitativi — in qualsiasi punto del bundle, del nome sviluppatore o dei metadati. Una variante comune è una discrepanza tra l'app o il brand nella scheda e l'entità che l'ha effettivamente inviata, cosa che spinge Apple a chiedere chi possiede il nome.
Prima: un nome di brand o piattaforma che non possiedi inserito nel titolo, nel sottotitolo o nel campo keyword della tua app per intercettarne il traffico di ricerca.
Dopo: il tuo nome di prodotto nel titolo, nel sottotitolo e nelle keyword. Se ti integri davvero con una piattaforma di terze parti e devi dichiararlo, mantieni qualsiasi menzione fattuale di compatibilità nella descrizione dove è consentita, e fuori dal nome e dal sottotitolo. Se hai realizzato l'app per un cliente che possiede il marchio, invia l'app dall'account dell'entità che lo possiede, oppure fatti aggiungere al suo team, così che il nome del venditore e il brand coincidano.
La parte senza build, ribadita
Per tutte e quattro le linee guida, se la correzione risiede nella scheda della versione — testo e immagini — la modifichi in App Store Connect e reinvii lo stesso binario. Non incrementi un numero di build né aspetti l'elaborazione. Questa è la corsia veloce che un rifiuto per metadati ti offre. Il compromesso è che torni comunque in review, quindi conviene rileggere l'intera scheda alla luce di queste quattro linee guida prima di reinviare, invece di risolverle una alla volta a ogni rifiuto.
Dove Mokbi aiuta (e dove no)
La maggior parte dei problemi con la 2.3.7 nasce già in fase di scrittura, quando un campo keyword o un sottotitolo viene riempito per inseguire visibilità. L'AI di Mokbi redige i testi della scheda — nome, sottotitolo, keyword, descrizione — a partire da ciò che l'app fa davvero, allontanandoti dalle abitudini di riempimento e di brand presi in prestito che fanno scattare un rifiuto per keyword. Dopodiché localizza quei testi in 50 lingue, così non devi riscrivere a mano un campo keyword per ogni mercato reintroducendo la stessa trappola in ognuno.
È bene essere chiari sui limiti. Questo riduce le probabilità di una segnalazione 2.3.x o 5.2.1 sul testo; non può promettere l'approvazione, e non decide cosa c'è dentro la tua build. La revisione è una decisione di Apple. Un testo conforme e coerente con l'app elimina i motivi facili e autoinflitti per essere respinti. Mokbi non pubblica automaticamente sulla tua scheda: produce i testi e gli screenshot, tu li rivedi e li invii.