Pubblicare la scheda dello store senza fastlane

fastlane è la risposta predefinita per un buon motivo. È un toolkit gratuito, con licenza MIT, e la sua azione deliver (alias upload_to_app_store) carica screenshot, video App Preview, metadati e binario su App Store Connect con un solo comando. Sul lato Android, supply (alias upload_to_play_store) fa lo stesso per Google Play — metadati, screenshot e APK o app bundle. Esegui uno dei due dalla CI e la tua scheda si rigenera a ogni release, senza mai disallinearsi dall'app.

Quindi la domanda onesta non è "fastlane è valido" — lo è. La domanda è se vuoi gestire la pipeline che lo rende tale, oppure se preferisci aggiornare una scheda senza.

Cosa fanno davvero deliver e supply

Entrambi sono wrapper attorno alle API ufficiali degli store. Dietro le quinte, fastlane fa le stesse chiamate che potresti fare tu.

• deliver (iOS). Carica nome app, descrizione, parole chiave, note di rilascio, URL, categorie e informazioni di revisione, oltre a screenshot localizzati e video di anteprima. Il binario viene caricato tramite iTMSTransporter di Apple; i metadati passano attraverso l'API di App Store Connect. Può anche inviare per la revisione dopo il caricamento.
• supply (Android). Carica metadati, screenshot e APK o AAB su Google Play, scegliendo un track e promuovendo le build. C'è un punto delicato da considerare: gli screenshot caricati sostituiscono quelli esistenti per una lingua invece di aggiungersi.

Entrambi si autenticano con chiavi API — una chiave API di App Store Connect per Apple, un JSON service-account per Google — quindi, una volta configurati, girano senza supervisione nella CI. È tutto il vantaggio: metadati e screenshot come codice, versionati nel tuo repository, distribuiti a ogni build.

Il vero costo di fastlane

fastlane è gratuito da installare ed eseguire. Il costo è la configurazione e la manutenzione, e si paga in tempo di ingegneria.

• Un runtime da mantenere. fastlane è un toolchain Ruby (Ruby 3.0+), di solito gestito con Bundler. Il lavoro iOS richiede Xcode su un Mac; Android richiede il lato Gradle. È macchinari reali da installare e tenere aggiornati.
• File di configurazione da scrivere. Un Fastfile definisce le tue lane; un Deliverfile o la cartella dei metadati Android contiene i dettagli della scheda. Ottenere la prima versione funzionante di solito richiede un giorno o due.
• CI da mettere in piedi. L'automazione ripaga solo dentro una pipeline, il che significa chiavi API, segreti di firma e un runner di build configurato e tenuto in ordine.
• Manutenzione della cattura screenshot, se la usi. snapshot di fastlane guida test UI nel simulatore per catturare screenshot per ogni lingua. Questi test sono fragili: un report comune è che un setup funziona bene per un paio di mesi, poi un cambiamento UI rompe il flusso e il codice del test va riscritto per gestire i nuovi stati. snapshot ritenta di default le esecuzioni instabili, il che copre il non-determinismo dovuto a rete e dati invece di risolverlo. E l'output grezzo non ha didascalie o sfondi — i team spesso finiscono comunque il design in uno strumento separato.

Niente di tutto questo è una critica allo strumento. È lo scambio onesto: fastlane converte una fatica manuale ricorrente in codice, e in cambio tu mantieni codice. Per un team che rilascia ogni settimana con un ingegnere che gestisce l'automazione delle release, è un buon affare. Per un maker solo o un PM che aggiorna una scheda poche volte l'anno, la pipeline può costare più a tenerla viva di quanto faccia risparmiare.

Aggiornare una scheda senza fastlane

Se salti fastlane, hai comunque tre modi per portare metadati e screenshot sugli store.

1. Le console web degli store

Il percorso più semplice. In App Store Connect modifichi ogni localizzazione a mano e trascini gli screenshot negli slot per dimensione display; in Google Play Console modifichi la scheda per ogni lingua e carichi lì gli screenshot. Nessun codice, nessuna chiave, niente da mantenere — punti e clicchi. Lo svantaggio è che è del tutto manuale, e farlo su molte lingue una schermata alla volta è lento e soggetto a errori. Va bene per una o due lingue; doloroso a 20.

2. Le API degli store, direttamente

Entrambi gli store espongono le stesse API che chiama fastlane, quindi puoi automatizzarle con i tuoi script senza adottare lo stack Ruby di fastlane. L'API di App Store Connect di Apple è un'API REST autenticata con un JWT a breve durata (ES256, firmato con la tua chiave), con endpoint per creare set di screenshot, riservare e caricare i byte delle immagini e aggiornare i metadati. La Play Developer API di Google usa un modello a "edit" — apri una modifica, cambi schede e immagini, poi la confermi. Questo ti dà pieno controllo e si adatta a una dashboard interna personalizzata, ma ora sei tu a scrivere e mantenere quell'integrazione. È un impegno minore rispetto a una pipeline fastlane completa, non nullo.

3. Uno strumento gestito che prepara la scheda

L'altra strada senza codice è uno strumento che produce la scheda per te, così l'unica cosa che resta è portarla sullo store. È qui che il compromesso si inverte: invece di un ingegnere che gestisce una pipeline, un PM o un designer gestisce la scheda direttamente nel browser. Stai scambiando l'automazione CI per non avere affatto bisogno di un ingegnere.

Dove si colloca Mokbi — onestamente

Mokbi non cerca di sostituire la storia CI di fastlane. Se il tuo obiettivo sono screenshot che si rigenerano a ogni build senza un essere umano nel ciclo, una pipeline fastlane è lo strumento giusto ed è gratuito. Noi siamo per l'altro caso: chi vuole pubblicare una scheda curata senza toccare Ruby, Xcode, un Fastfile o un test UI.

Nel browser progetti gli screenshot, scrivi i testi dello store e traduci l'intera scheda in 50 lingue — nessun simulatore, nessuna CI, nessun codice. Un designer o un PM può gestire l'intera superficie marketing dall'inizio alla fine.

Ecco l'ultimo miglio, e Mokbi lo copre. Progetta gli screenshot e la feature graphic, scrive e traduce l'intera scheda in 50 lingue, poi invia il risultato direttamente a Google Play tramite la Play Developer API e prepara la versione App Store in App Store Connect, pronta perché tu prema Invia — Apple richiede quell'invio finale e la propria revisione, una regola di Apple, non una lacuna nostra. Gli stessi endpoint chiamati da fastlane, meno la pipeline.

Quando scegliere cosa

• Rilasci ogni settimana, hai un ingegnere, vuoi zero disallineamento? fastlane. È gratuito, è automatizzato e tiene screenshot e metadati in perfetta sincronia con l'app. Niente batte questo.
• Aggiorni una scheda poche volte l'anno, niente CI da dedicare? La console web, o uno strumento che prepara la scheda. La manutenzione della pipeline non vale la pena a quel ritmo.
• Ti serve controllo programmatico ma non lo stack di fastlane? Chiama direttamente le API di App Store Connect e Play Developer.
• Vuoi che un designer o un PM gestisca la scheda in molte lingue? Scrivi, traduci e pubblica dal browser — Mokbi invia a Google Play e prepara la versione App Store pronta per l'invio.

fastlane si guadagna il suo posto come alternativa gratuita e automatizzata già affermata. Il percorso senza codice non è "migliore" — è uno scambio diverso: rinunci all'automazione CI, e in cambio nessuno deve costruire o presidiare una pipeline per aggiornare una scheda.

Cosa leggere dopo

• I migliori strumenti per pubblicare schede App Store
• Caricare screenshot con l'API di App Store Connect
• A confronto: Mokbi vs fastlane

Apri l'editor →