Rendi un'app pronta per gli store dal tuo agente di coding

Prima di iniziare

Ti servono Claude Code e un account AppFoyer. Il piano gratuito basta: creane uno. Non c'è nessuna chiave da creare: la prima volta che si collega, l'agente ti chiede di approvarlo nel browser.

Nessun agente di coding? Sei campi nel browser ti danno le stesse cinque pagine senza il plugin.

Non usi Claude Code? Il plugin ne ha bisogno, ma le pagine dell'informativa sulla privacy e dei termini no: i loro editor nella dashboard hanno un prompt, compilato con i dati della tua app, che esegui in qualsiasi assistente e di cui incolli la risposta. È riportato per intero nella guida all'informativa sulla privacy e nella guida ai termini.

Installazione

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

Per iniziare non serve un account: l'agente legge la tua build, mostra cosa ha trovato e fa le sue domande sulla tua macchina, e ti chiede di collegarti solo quando c'è qualcosa da salvare. La prima volta che chiama AppFoyer, il browser si apre su una pagina di approvazione: accedi o crea un account gratuito, controlla il nome e dove ritorna il browser, e approva. Claude Code conserva il collegamento e lo rinnova da solo; non si copia nulla e non si salva nulla nella shell. Se il browser non si apre, esegui /mcp, seleziona appfoyer e scegli Authenticate. Nell'app desktop di Claude Code, collegati una volta in questo modo da un terminale, poi avvia lì una nuova sessione: una sessione già in corso non vede il nuovo collegamento. Scollegalo nella pagina Agent della dashboard e la chiamata successiva fallisce subito. Claude Code non aggiorna da solo un marketplace di terze parti: in /plugin → Marketplaces → appfoyer, scegli Enable auto-update per ricevere le nuove versioni.

Nessun browser su quella macchina, come un server remoto, un container o un'esecuzione automatizzata? Usa invece una API key: creane una in Agent → API key — for CI and headless use, installa il plugin come sopra per il flusso di lavoro e aggiungi il server ancora una volta con la chiave nell'intestazione:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

Il plugin legge la chiave solo da quella variabile d'ambiente: la skill non la vede mai, e viaggia solo nell'intestazione Authorization che compila Claude Code.

Un altro client MCP (claude.ai, Claude Desktop, Cursor, VS Code) può collegarsi a https://app.appfoyer.com/mcp allo stesso modo, con la stessa pagina di approvazione. Ottiene gli strumenti; il flusso di lavoro passo per passo che legge i tuoi file di build è incluso nel plugin di Claude Code.

Cosa dire

Eseguili dentro il repository della tua app, non in una cartella vuota:

Esempi

Dillo con parole tue; questi sono i casi che la skill gestisce.

Un'app, prima esecuzione

> Make this app store-ready

• Elenca cosa ha trovato nei file di build (SDK, permessi, bundle id), ciascuno con file e riga.
• Chiede solo ciò che non ha trovato: nome dell'azienda, email di supporto, giurisdizione, link agli store. Al massimo due giri.
• Crea l'app, carica l'icona dal repository e prepara la bozza di tutte e cinque le pagine.
• Termina con un link per la revisione. Niente è pubblico finché non pubblichi lì.

Eseguilo di nuovo dopo una modifica

> Make this app store-ready

• Trova l'app esistente tramite l'application id e confronta i nuovi fatti con quelli salvati.
• Riscrive solo le pagine toccate dalla modifica, come la privacy dopo un nuovo SDK di analisi.
• Lascia stare l'icona e l'indirizzo, a meno che tu non lo chieda.

Più flavor, indicati nel prompt

> Make com.acme.weather.free and com.acme.weather.pro store-ready

• Crea due app e non chiede nulla sulla selezione.
• Legge la cartella, il nome e le dipendenze di ciascun flavor. Un SDK pubblicitario usato solo dal flavor free non finisce nell'informativa sulla privacy del flavor pro.
• Restituisce un link per la revisione e una tabella degli URL per la console per ogni flavor.

Più flavor, non indicati

> Make this app store-ready

• Elenca i flavor con i loro application id, tutti preselezionati, e scegli tu quali avranno un sito.
• I build type come debug e staging vengono elencati come esclusi, non proposti.

Dimensioni marchio × ambiente

> Make every brand store-ready

• Elenca le combinazioni (brandAProd, brandBProd), non i singoli flavor.
• Propone solo l'ambiente di produzione. dev e qa non vengono mai distribuiti in uno store.
• Legge il nome dell'app da Gradle (resValue, manifestPlaceholders) o da source set spostati quando la build lo mette lì.
• Se non riesce a capire se una dimensione rappresenta ambienti o marchi, lo chiede.

Indirizzo personalizzato (Pro e Advanced)

> Make this app store-ready

• Costruisce l'indirizzo dal nome inglese dell'app, per esempio weather-now.
• Se è già preso o troppo simile al nome di un marchio, prova il successivo (weather-now-app, acme-weather) al massimo cinque volte, poi lo chiede a te.
• Con il piano gratuito mantiene l'indirizzo app-… e dice che quello personalizzato arriva con Pro.
• L'indirizzo app-… continua a servire lo stesso sito.

Cambiare un indirizzo che usi già

> Change the address to weather-radar

• Prima chiede. Il vecchio indirizzo personalizzato viene liberato subito, e una scheda dello store che lo indica ancora smette di funzionare.
• Lo cambia solo dopo il tuo sì.

Aggiornare l'icona

> Update the app icon

• Trova l'icona del launcher: l'icona Play da 512, l'immagine mipmap più grande o l'immagine marketing dell'AppIcon iOS, prima quella del flavor stesso.
• Se supera i 512 KB, ne rimpicciolisce una copia in una cartella temporanea. Il tuo repository non viene toccato.
• Ti dice quale file ha caricato. Su un'app pubblicata la nuova icona è subito online.

Un'app con annunci

> Make this app store-ready. AdMob publisher id pub-0000000000000000

• Scrive app-ads.txt dalle righe che fornisci. L'ID publisher non è nel tuo codice, quindi non lo indovina mai.
• Ti ricorda di impostare il sito come sito web dello sviluppatore nella scheda dello store.
• AdMob ha verificato file app-ads.txt sui nostri indirizzi; lasciagli fino a 24 ore per la scansione.

Tenere le pagine allineate alla build

> Add the AppFoyer drift check

• Ogni esecuzione di “make this app store-ready” scrive appfoyer.json nella radice del repository: gli SDK, i tipi di dati e i permessi da cui sono state scritte le pagine. Lo scrive lo stesso scanner usato dal controllo, mai a mano.
• Questo prompt mostra un workflow GitHub per l'action gratuita appfoyer/check-action e scrive .github/workflows/appfoyer.yml quando dici di sì. Non sovrascrive mai uno che hai già.
• Da quel momento ogni pull request elenca cosa ha aggiunto o rimosso da quando sono state scritte le pagine, con file e riga. Rieseguire il plugin aggiorna le bozze e appfoyer.json.
• Niente viene committato al posto tuo. La guida su come tenere l'informativa sulla privacy allineata alla build ha i dettagli e la configurazione per altri sistemi di CI.

Controllare senza cambiare nulla

> Is this app store-ready?

• Esegue la checklist per ogni app corrispondente e riporta cosa manca. Non scrive nulla.
• Un flavor che non ha ancora un'app viene segnalato come mancante.

Mettere i link nell'app

> Wire the store-ready links into the app

• Richiede pagine pubblicate.
• Propone un diff per i link alla privacy e al supporto nella schermata delle impostazioni o nelle stringhe. Lo applica solo quando dici di sì, e non fa mai commit.

Cosa esce dalla tua macchina

Solo fatti ricavati:

• il nome dell'app, la piattaforma e il bundle id o application id;
• i nomi degli SDK e dei permessi trovati nei tuoi file di build;
• le risposte che confermi: nome dell'azienda, email di supporto, giurisdizione, URL degli store;
• il testo delle pagine preparato dall'agente, salvato nel tuo account come bozza;
• l'icona dell'app, inviata una sola volta tramite un link di caricamento monouso.

Nessun altro file, mai codice sorgente, mai segreti o chiavi trovati nel repository. Ciò che l'agente invia è ciò che un'informativa sulla privacy deve comunque dichiarare.

Un solo file viene scritto nel tuo repository e ci resta: appfoyer.json, il registro di ciò da cui sono state scritte le pagine, creato dallo scanner incluso nel plugin. Non viene inviato da nessuna parte. L'agente non lo committa mai, né committa altro: lo fai tu.

Cosa l'agente non può fare

Che si colleghi tramite il browser o con una API key, il plugin ha una credenziale da agente, quindi la pubblicazione non gli è proprio disponibile. Lo impone il server, non una gentile richiesta all'agente:

• Non esiste uno strumento per pubblicare. L'agente scrive bozze; le tue pagine online non cambiano.
• Due cose non hanno bozza: l'icona e l'indirizzo personalizzato. Su un'app pubblicata cambiano subito il sito online, e l'agente ti dice quando li ha impostati. Non può sostituire un indirizzo personalizzato che usi già senza il tuo sì.
• La route REST che pubblica una pagina rifiuta del tutto le credenziali da agente: solo sessione.
• Ogni pagina passa comunque al momento della pubblicazione lo stesso controllo dei contenuti di una modifica scritta a mano.
• Ogni chiamata dell'agente viene registrata nel log di audit dell'account con il collegamento o la chiave che l'ha fatta.

Quindi il caso peggiore per un collegamento o una chiave compromessi sono bozze da scartare, un'icona sbagliata o un nuovo indirizzo, non una pagina che diventa pubblica a tuo nome.

Gli strumenti che riceve

Il plugin si collega a un endpoint MCP che espone esattamente questi:

Quando qualcosa va storto

Una cosa che questo non cambia

Le bozze sono modelli completati a partire dal tuo codice, non consulenza legale. Che un agente le scriva in fretta non le rende vere: leggi ciò che ha scritto prima di pubblicare, soprattutto l'elenco di ciò che la tua app raccoglie. Lo store considera responsabile te.

Domande: support@appfoyer.com.