Cosa puoi cambiare senza una nuova versione dell'app: Apple vs Google
Prima di toccare una scheda store, c'è una domanda che vale la pena farsi: questa modifica mi costerà un invio completo, oppure può uscire senza clamore? Sbagliare significa finire in coda di revisione senza averlo previsto, oppure pensare che una modifica sia già attiva quando è ancora in attesa di approvazione. I due store rispondono a questa domanda in modi opposti, ed è proprio questa differenza il motivo per cui tenere le schede sincronizzate tra entrambi è così fastidioso.
Ecco la versione onesta, campo per campo — si parte dalla matrice, poi la logica dietro le regole di ciascuno store, così puoi prevedere i casi che questa tabella non specifica.
La matrice
Ogni campo comune della scheda, e cosa richiede ciascuno store quando lo modifichi. "Nuova versione / release" significa che lo store tratta la modifica come parte di un invio da inviare; "revisionato" significa che una persona o un controllo automatico interviene prima che vada online.
| Icona dell'app | L'icona principale è integrata nel binario — cambiarla richiede una nuova build. Revisionata insieme a quella build. | L'icona dello store è un asset della scheda. Nessuna nuova release. Revisionata. |
Due cose saltano all'occhio. Apple incanala quasi tutto attraverso un record di versione. Google lascia muovere l'intera scheda da sola. Nessuno dei due store salta la revisione sugli asset che contano — la parola "revisionato" compare in quasi ogni cella. Quindi la vera domanda raramente è "questo verrà revisionato", ma "questa modifica trascina con sé un invio".
Apple: un nuovo record di versione non è la stessa cosa di una nuova build
Questa è la distinzione che manda in confusione. Sull'App Store, modificare screenshot, nome, sottotitolo, campo keyword o descrizione crea una nuova versione della tua scheda. Sembrerebbe dover costringere a tornare su Xcode. Non è così. Apple riporta automaticamente i metadati attuali nella nuova versione, e una modifica solo ai metadati non richiede nuovo codice dell'app — associ una build (App Store Connect la richiede comunque sulla versione) e non cambi nulla di ciò che l'app fa. Modifichi i campi in coda, invii, e un solo ciclo di revisione copre tutto.
Quindi "nessun codice nuovo, ma comunque revisionata" è il modo corretto di tenerla a mente. Nessuna compilazione e nessuna nuova funzionalità — ma la modifica entra comunque in App Review e aspetta il suo turno prima di diventare pubblica. Raggruppa le modifiche: dato che un singolo record di versione può contenere nuovi screenshot, una descrizione riscritta, un sottotitolo aggiornato e keyword nuove tutti insieme, non c'è motivo di consumare un ciclo di revisione separato per ognuno.
L'icona dell'app è l'eccezione che richiede davvero una build. La tua icona principale è integrata nel binario e viene tratta da esso, quindi una nuova icona reale significa una nuova build. Lo stesso vale per le icone alternative — devono essere incluse nell'app per essere utilizzabili, quindi aggiungerne una è una build, non una modifica alla scheda.
Le due vie di fuga di Apple
Testo promozionale. È l'unico campo che puoi cambiare senza versione e senza revisione. Sono 170 caratteri, si trova sopra la descrizione, e si aggiorna quando vuoi — comodo per una promozione, una nota di lancio o un testo legato al tempo. Non influisce sul posizionamento nelle ricerche e non fa parte di nessun invio, ed è proprio per questo il campo più veloce da cambiare sullo store. Se ti serve qualcosa attivo oggi stesso, è questo il campo che può farlo.
Product Page Optimization. PPO ti permette di testare fino a tre varianti di screenshot, App Preview e icona rispetto alla pagina prodotto attiva — senza pubblicare una nuova versione dell'app. È la cosa più vicina, per Apple, a cambiare gli elementi visivi fuori da un normale invio. Due avvertenze da tenere presenti: i metadati della variante devono comunque essere approvati prima che il test parta (quindi è revisionata, non istantanea), e qualsiasi icona vuoi testare deve già far parte del binario attuale dell'app. PPO cambia cosa vedono i visitatori; non salta la revisione.
Google Play: pubblica la scheda senza una release
Play funziona al contrario. La tua scheda store — titolo, descrizione breve, descrizione completa, screenshot, feature graphic, icona, video promozionale — è modificabile e pubblicabile da sola, senza nessuna nuova release dell'app associata. Fai le modifiche, e compaiono nella panoramica Publishing tra le modifiche pronte per essere inviate in revisione. Le invii, passano per la revisione di Google, e diventano attive indipendentemente da qualsiasi build.
Alcune cose da tenere precise per non esagerare. Le modifiche vengono comunque revisionate — la revisione di Play interviene anche sulle modifiche alla scheda, ed elementi come il nome dell'app e l'icona vengono controllati, quindi non è uno scambio istantaneo e silenzioso. E la scheda non può esistere slegata da un'app pubblicata: Play richiede che l'app abbia già un rilascio precedente prima che ci sia una scheda pubblica da modificare. Non puoi pubblicare una pagina store autonoma per qualcosa che non è mai stato rilasciato. La pubblicazione gestita aggiunge un'altra sfumatura da conoscere — se è attiva, le modifiche approvate attendono che tu le pubblichi attivamente, il che è una funzionalità, non un ritardo, una volta che te lo aspetti.
L'asimmetria, e perché ti costa tempo
Metti a confronto i due modelli e la divisione è netta. Apple lega quasi ogni modifica a testo e immagini a un record di versione e a un passaggio di revisione, con testo promozionale e PPO come uniche vie d'uscita. Google scollega completamente la scheda dalla release, revisiona le modifiche, e le pubblica secondo i propri tempi purché l'app esista già.
Quell'asimmetria costa cara, silenziosamente, quando gestisci entrambi gli store. Lo stesso aggiornamento di screenshot è un invio con record di versione su uno store e un aggiornamento autonomo della scheda sull'altro. Una riscrittura della descrizione è una versione revisionata su Apple e una modifica alla scheda revisionata su Google. Il contenuto è lo stesso; i meccanismi no, quindi una modifica che su Play è una sola azione diventa un'azione diversa sull'App Store — ed è facile pubblicarne una e dimenticare l'altra, o pensare che qualcosa sia già attivo su Apple quando è ancora in revisione.
Dove si inserisce Mokbi
Questa asimmetria tra store è proprio il motivo per cui uno strumento di pubblicazione si guadagna il suo posto. Mokbi è nato come editor di screenshot, ma una scheda è testo e immagini insieme — quindi progetta il set di screenshot e redige i testi della scheda per entrambi gli store in un unico posto: nome, sottotitolo, campo keyword e descrizione per l'App Store; titolo, descrizione breve e descrizione completa per Play. Ottieni i campi che ogni store effettivamente indicizza, adattati a quello store, invece di un unico blocco di testo che incolli due volte.
Poi traduce l'intera scheda — screenshot e testi — in 50 lingue, così una modifica che fai una volta sola finisce nel campo giusto in ogni mercato invece di restare in inglese in una scheda localizzata ovunque altrove. E la pubblica: Mokbi invia la scheda finita direttamente su Google Play tramite la Play Developer API, e la prepara su App Store Connect pronta per l'invio — Apple richiede comunque il Submit finale e il passaggio di revisione dal suo lato, che è una regola di Apple ed è esattamente l'asimmetria tra store di cui parla tutto questo articolo. Quell'ultima revisione è anche il punto da cui iniziano a scorrere gli orologi di cui parla questo articolo.