La bocciatura prima di Apple

Cos'è e perché conta

Mandi l'app in revisione, aspetti, e torna indietro. Manca l'accesso con Apple, oppure l'account non si può cancellare, oppure la frase che spiega perché chiedi la fotocamera è troppo vaga. Ogni giro sono giorni persi, e spesso il motivo stava già scritto nei tuoi file.

Greenlight è un programma da terminale che fa quel controllo prima di te. Legge il codice, i file di configurazione e, se glielo dai, l'app già compilata. Poi li confronta con le regole di revisione di Apple e con quelle di Google Play. Ogni problema ha un livello di gravità e cita la regola da cui viene. Il controllo base non chiede account, non carica niente e non usa la rete. Lo fa Revyl, un'azienda che fa test per app, e il codice è aperto su GitHub con licenza MIT: si usa gratis.

È per chi pubblica da solo, senza un team che rilegge le regole di Apple a ogni rilascio. Una cosa va detta subito: è una lista di cose da guardare, non un timbro di approvazione. Legge i file, non usa l'app. Nella sezione 6 trovi cosa non vede.

1. Cosa controlla

Il comando principale si chiama preflight, come il controllo prima del decollo. Lancia insieme cinque controlli, che nella documentazione si chiamano scanner:

• metadata: nome, versione, formato del bundle ID (l'identificativo dell'app), icona, link alla privacy policy e le frasi che spiegano perché chiedi un permesso. Li legge in Info.plist o, per le app Expo, in app.json.
• codescan: 24 regole sul codice Swift, Objective-C, React Native ed Expo. Per esempio chiavi segrete scritte nel codice, login con Google senza l'accesso con Apple, account che si crea ma non si cancella.
• privacy: il manifesto della privacy che Apple chiede (PrivacyInfo.xcprivacy) c'è ed è completo? E se usi SDK di tracciamento, c'è il popup ATT che chiede il permesso di tracciare?
• playscan: solo per i progetti Android. Le regole di Google Play: il livello di API Android da usare come target e le sue scadenze, i permessi che chiedono un modulo di dichiarazione, i servizi in primo piano, la versione di Play Billing per i pagamenti.
• ipa: l'app per iPhone già compilata, il file .ipa. Controlla le chiavi di Info.plist, la schermata di avvio, le icone, il peso dell'app e i manifesti privacy dei framework inclusi. Parte solo se gli passi il file.

Se nella stessa cartella ci sono sia la parte iOS sia quella Android, come in un'app Flutter o React Native, le controlla tutte e due in un solo giro.

2. Installalo e lancia il primo controllo

Si installa da terminale. Su Mac, con Homebrew, il programma che installa altri programmi da terminale. Se invece hai Go, il linguaggio in cui è scritto Greenlight, usa la seconda riga.

brew install revylai/tap/greenlight
go install github.com/RevylAI/greenlight/cmd/greenlight@latest

Poi entra nella cartella principale del progetto e lancia il controllo. Il punto vuol dire «questa cartella». Ci mette meno di un secondo.

greenlight preflight .

Se hai già esportato l'app per l'App Store, aggiungi il file .ipa: così controlla anche l'app compilata, non solo i sorgenti. Per Android c'è lo stesso con --apk o --aab, il file che carichi su Play. Metti il percorso del tuo file al posto dell'esempio.

greenlight preflight . --ipa build.ipa
greenlight preflight . --aab app-release.aab

3. Come leggere il risultato

Ogni problema trovato ha quattro cose: il livello di gravità, la regola di Apple o di Google da cui viene, il file dove l'ha trovato e un suggerimento su come sistemarlo. I livelli sono quattro:

• CRITICAL: la bocciatura, o un'installazione che fallisce, è quasi certa. Si sistema prima di mandare.
• HIGH: una scadenza già pubblicata, una dichiarazione obbligatoria che manca o qualcosa che si rompe mentre l'app gira.
• WARN: è probabile che il revisore se ne accorga e ti chieda spiegazioni.
• INFO: buona pratica. Non blocca niente.

In fondo c'è il verdetto: NOT READY se resta almeno un CRITICAL, NEEDS REVIEW se restano degli HIGH, GREENLIT quando non c'è più nessuno dei due. GREENLIT vuol dire che il controllo sui file è passato, non che Apple ti approverà.

4. Fallo usare a Claude Code

Greenlight c'è anche come plugin di Claude Code. Il plugin non è il programma: è una skill, cioè un foglio di istruzioni che dice a Claude come lanciare il controllo, leggere i risultati, correggere il codice e rilanciare. Dentro Claude Code scrivi:

/plugin marketplace add RevylAI/greenlight
/plugin install greenlight

Il plugin non installa il programma: fallo prima tu, come al punto 2. Poi apri Claude Code nella cartella del progetto e incolla:

Lancia greenlight preflight e correggi tutto finché passa. Parti dai CRITICAL, poi gli HIGH. Dopo ogni giro di correzioni rilancia il controllo. Se un problema ti sembra un falso allarme, non toccare il codice: fermati e spiegami perché.

Gli HIGH li ho messi apposta. Le istruzioni del plugin considerano finito il lavoro quando non resta nessun CRITICAL. Gli HIGH però restano, e tra questi ci sono proprio l'accesso con Apple che manca e l'account che non si cancella.

Quando un risultato non ti è chiaro, fattelo spiegare prima di toccare qualcosa:

Spiegami questo risultato di Greenlight con parole semplici: [incolla la riga]. Dimmi quale regola di Apple o di Google cita, in quale file l'ha trovato e cosa c'è scritto lì. Poi dimmi se secondo te è un problema vero o un falso allarme, e come lo verifico io.

E quando hai capito che è un falso allarme:

Questo risultato di Greenlight è un falso allarme: [incolla la riga]. Se viene dal controllo del codice (codescan), crea o aggiorna .greenlight.yml nella cartella principale: abbassa la gravità di quella regola o escludi solo il file o la cartella che serve, senza spegnere altri controlli. Scrivi accanto un commento con il motivo. Se viene da un altro controllo, non cambiare niente e dimmelo.

5. Falsi allarmi e controllo automatico

Il file .greenlight.yml

Va nella cartella principale del progetto e regola il controllo del codice, anche quando parte dentro preflight. Per ogni regola puoi cambiare la gravità (info, warn o critical) o spegnerla, e puoi escludere cartelle, file o percorsi.

rules:
  hardcoded-ipv4:
    severity: info
  platform-reference:
    enabled: false
ignore:
  - vendor
  - "*.generated.ts"

Per una riga sola c'è un commento da mettere su quella riga o su quella sopra: // greenlight:ignore seguito dal nome della regola. Senza il nome spegne tutte le regole su quella riga. Meglio scriverlo, così gli altri controlli restano accesi.

let host = "10.1.2.3" // greenlight:ignore hardcoded-ipv4

Il controllo a ogni rilascio

Con --exit-code il comando finisce con un errore se trova un CRITICAL o un HIGH, oppure se uno dei controlli si è bloccato: così un controllo fatto a metà non passa mai per buono. Mettilo nella CI, cioè i controlli automatici che partono a ogni push, per esempio GitHub Actions: un rilascio con un problema grave si ferma da solo.

greenlight preflight . --exit-code

6. Cosa non vede

Greenlight legge testo, non apre mai l'app. Se nel codice c'è un bottone «Elimina account» collegato a niente, vede la parola, la regola passa, e Apple ti boccia lo stesso quando lo tocca.

Poi ci sono i falsi allarmi. Il caso più chiaro è la segnalazione numero 30 sul loro GitHub: in app senza nessuna pubblicità, la regola sugli annunci di Google scatta perché trova «ads» dentro parole normali come loadSdk o downloads. Dà un CRITICAL senza indicare il file e suggerisce di aggiungere il popup ATT, che in un'app che non traccia è proprio la cosa sbagliata. Prima di correggere, guarda sempre cosa c'è davvero nel tuo codice.

E il codice che legge è solo Swift, Objective-C, React Native ed Expo. La nostra app è in Flutter: il codice Dart non lo legge, quindi un login con Google senza Apple scritto in Dart non lo trova. Legge però Info.plist, il manifesto privacy, il manifesto Android, i file Gradle e l'app compilata. Su Flutter passagli sempre i file compilati, e login e cancellazione account provali a mano.

Due comandi facoltativi non sono offline: verify prova alcuni flussi su un telefono in cloud e chiede un account Revyl; scan --app-id controlla la scheda su App Store Connect e chiede il login lì. Questa guida non li usa.

Gli errori più comuni

• Prendere GREENLIT per un'approvazione. Vuol dire che nei file non resta niente di grave, non che l'app funziona.
• Correggere un falso allarme. Prima di aggiungere il popup ATT o cambiare codice, guarda cosa ha trovato davvero e dove.
• Controllare solo i sorgenti. I permessi che aggiungono le librerie si vedono solo nel file compilato: passagli anche .ipa, .apk o .aab.
• Fidarsi del verde su un'app Flutter. Il Dart non lo legge: login e cancellazione dell'account li provi tu, sul telefono.

Checklist

• Greenlight installato, all'ultima versione
• greenlight preflight . lanciato nella cartella principale del progetto
• Controllo ripetuto con il file compilato: .ipa, .apk o .aab
• Zero CRITICAL e zero HIGH, oppure ognuno spiegato
• Ogni falso allarme controllato a mano e segnato in .greenlight.yml o con greenlight:ignore
• greenlight preflight . --exit-code nella CI
• Cancellazione account, ripristino acquisti e accesso con Apple provati sull'app vera

Domande frequenti