LaunchLint Academy
Risposta breve
- EAS Submit carica il file finale dell’app, ma non completa scheda, privacy, screenshot o indicazioni per il team di verifica.
- Prima di creare l’app verifica identità, versioni, estensioni e permessi. Poi testa la versione di produzione su dispositivi reali e confronta il flusso con App Store Connect e Play Console.
- Tratta eliminazione account, accesso di prova, acquisti e pratiche sui dati dei servizi esterni come parte di ogni pubblicazione. Un processo tecnico riuscito non equivale all’approvazione.
1. Cosa fa EAS Submit e cosa resta da fare
EAS Submit invia il file iOS o Android allo store. Su iOS arriva in App Store Connect o TestFlight; su Android nel canale configurato. Riduce i passaggi manuali, ma Apple e Google valutano ancora l’app, le informazioni della scheda e le indicazioni fornite.
EAS Build e Submit riusciti provano solo che il file è stato creato e trasferito. Non provano l’accesso di un nuovo revisore, la precisione dei permessi, la correttezza delle dichiarazioni, gli acquisti o le pagine pubbliche.
Dopo il caricamento devi ancora:
- Completare scheda, categoria, età e disponibilità
- Confrontare screenshot e descrizione con la versione di produzione
- Compilare App Privacy e Data Safety
- Fornire contatto, account di prova e passaggi
- Rendere verificabili acquisti e abbonamenti
- Inviare l’app elaborata alla verifica
2. Blocca identità e versioni prima della produzione
Bundle Identifier e package Android collegano binario, scheda, firma, push e spesso OAuth. Verificali prima del primo upload: un’identità pubblicata non si rinomina come il nome visibile.
Separa versione marketing e numero tecnico. Ogni binario iOS richiede buildNumber maggiore; Android usa versionCode. Con app.config dinamica controlla i valori risolti in produzione.
{
"expo": {
"name": "My Production App",
"slug": "my-production-app",
"version": "1.0.0",
"ios": {
"bundleIdentifier": "com.example.myapp",
"buildNumber": "1"
},
"android": {
"package": "com.example.myapp",
"versionCode": 1
}
}
}- Identificatori e schede coincidono
- buildNumber e versionCode crescono
- Domini API, OAuth e deep link sono corretti
- Icona, splash e nome sono finali
- Le variabili d’ambiente sono note
3. Spiega i permessi dal flusso utente
Le librerie Expo possono aggiungere permessi tramite Config Plugin o manifest Android. Inventaria le dipendenze, controlla la configurazione risultante e rimuovi i permessi non usati.
Su iOS il Purpose String deve descrivere una funzione verificabile. Un messaggio generico ripete il dialogo; il motivo legato alla scansione del QR spiega momento e valore. Le modifiche Info.plist richiedono un nuovo binario e non passano via OTA.
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription":
"Use the camera to scan the QR code on an event ticket."
}
},
"android": {
"blockedPermissions": [
"android.permission.RECORD_AUDIO"
]
}
}
}- Chiedere al momento giusto
- Gestire il rifiuto
- Spiegare finalità e valore
- Consentire attivazione successiva
- Rimuovere permessi inutili
4. Allinea file del progetto, comportamento e dichiarazioni privacy
package.json segnala possibili librerie e servizi esterni ma non produce una dichiarazione completa. Servizi di analisi, errori, accesso, pubblicità e pagamenti possono inviare dati; configurazione e uso reale determinano cosa, quando, perché e a chi.
| Livello | Prove utili | Sufficiente? |
|---|---|---|
| File del progetto | Servizi esterni, permessi, estensioni e indirizzi web | No: sono segnali |
| App in esecuzione | Momento, consenso, opzione e invio | No: restano server e fornitori |
| Console | Dati, scopi, condivisione e cancellazione | No: deve coincidere con l’app |
Google include in Data Safety i dati trasmessi dai servizi esterni e lascia allo sviluppatore la responsabilità. Documenta tipo, destinatario, scopo, obbligatorietà, conservazione e cancellazione per ogni servizio, poi confronta l’informativa sulla privacy e i moduli.
5. Testa accesso ed eliminazione come un revisore esterno
Se il nucleo richiede login, ruolo, abbonamento o posizione, fornisci un percorso stabile. Apple chiede account demo attivo o modalità demo completa, senza dati personali o codici temporanei.
- Account dedicato e backend disponibile
- Passaggi brevi alla funzione
- Dettagli per ruoli, QR, hardware o luogo
- Stato demo per acquisti
- Contatto disponibile
L’eliminazione è un flusso completo. Apple richiede l’avvio in-app; Google aggiunge una risorsa web. Testa conferma, riautenticazione, dati collegati, abbonamenti e conservazione spiegata.
6. Confronta screenshot, promesse e acquisti con l’app
Le informazioni della scheda fanno parte della verifica. Rimuovi funzioni assenti o interne, usa screenshot raggiungibili e apri supporto e privacy su mobile senza accedere.
I prodotti digitali devono essere visibili e funzionare durante la verifica. Testa ripristino, errore, abbonamento attivo e reinstallazione. Una libreria di pagamento non prova questi casi.
- Nome e descrizione esatti
- Screenshot reali
- Pagine HTTPS pubbliche
- Acquisti visibili
- Indicazioni brevi per il team
- Nessun testo provvisorio o messaggio interno
7. Il preflight delle 24 ore
Congela brevemente la release, crea il build dal commit previsto e testa esattamente quell’artefatto. Modifiche native, ai permessi o agli SDK richiedono un nuovo binario e un controllo mirato.
- Annotare commit e configurazione
- Installare iOS e Android su dispositivi reali
- Testare avvio, login, rifiuto, nucleo, acquisto ed eliminazione
- Confrontare SDK e privacy
- Rileggere immagini, testi, URL e note
- Validare l’account su altro dispositivo
- Caricare, verificare elaborazione, inviare
Conserva build ID, flusso, risultato atteso, risultato reale e responsabile. Dopo un rifiuto distinguerai più rapidamente difetto del binario, scheda o comunicazione.
8. Cosa offre una verifica statica dei file del progetto
L’analisi statica trova identificatori, servizi esterni, estensioni, spiegazioni dei permessi e segnali di accesso, acquisti o tracciamento in file precisi. Non prova tutto il server, l’account di prova o ogni interazione.
LaunchLint non esegue mai codice altrui. La verifica guida il controllo manuale e collega prove e domande dello store senza sostituire responsabilità o decisione finale.
Domande frequenti prima dell’invio Expo
Un EAS Build riuscito basta per l’invio?
No. Prova solo la creazione del file dell’app; accesso di prova, informazioni della scheda, privacy, acquisti e flussi reali vanno verificati.
Posso correggere un permesso iOS via OTA?
No. Una modifica Info.plist richiede un nuovo binario nativo.
L’account demo deve contenere dati reali?
No. Usa un account dedicato senza dati personali o codici temporanei.
LaunchLint garantisce l’approvazione?
No. Individua rischi e prove nei file del progetto; la decisione spetta ad Apple e Google.