---
title: "Test da eseguire prima della pubblicazione di una nuova release di un’app Flutter per iOS & Android"
id: "544"
type: "post"
slug: "test-release-app-flutter-per-ios-android"
published_at: "2026-08-27T15:25:46+00:00"
modified_at: "2026-08-27T15:25:46+00:00"
url: "https://pierluigipapeschi.com/test-release-app-flutter-per-ios-android/"
markdown_url: "https://pierluigipapeschi.com/test-release-app-flutter-per-ios-android.md"
excerpt: "Ad ogni release è bene strutturare una serie di controlli che ci fanno evitare di pubblicare un’app con bug banali o gravi. La lista è pensata per iOS e Android con Flutter, ma molti controlli sono di carattere generale. Se..."
taxonomy_category:
  - "Flutter"
---

Ad ogni release è bene strutturare una serie di controlli che ci fanno evitare di pubblicare un’app con bug banali o gravi. La lista è pensata per iOS e Android con Flutter, ma molti controlli sono di carattere generale. Se cerchi un articolo che spieghi come pubblicare una nuova app, leggi [questi articoli](https://pierluigipapeschi.com/pubblicazione-di-un-app-su-app-store-1/)
. Andiamo veloci in modo schematico:

## **1. Build e configurazione**

- Eseguire `flutter analyze` per verificare che non ci siano errori o warning.
- Eseguire tutti gli unit test con `flutter test` se ne abbiamo fatti.
- Verificare che la build nel modo Release compili correttamente su Android e iOS
- Controllare `version` e `build number` in `pubspec.yaml`.
- Verificare che ambiente, API URL e configurazioni siano quelli di produzione.
- Controllare che non siano rimasti flag di debug, mock, dati fasulli o endpoint necessari solo per le fasi di staging.
- Verificare che eventuali chiavi e configurazioni sensibili non siano incluse impropriamente nell’app.
- Controllare che logging e strumenti di debug non espongano dati sensibili. Meglio evitare ogni log in produzione.

## **2. Installazione e aggiornamento**

- Installare l’app da zero su un dispositivo Android e iOS reale.
- Verificare il primo avvio.
- Aggiornare una versione precedente dell’app alla nuova versione senza disinstallarla.
- Controllare che dati locali, preferenze e sessioni vengano mantenuti correttamente dopo l’upgrade.
- Verificare eventuali migrazioni di database.
- Verificare il comportamento dopo chiusura forzata e nuovo avvio.

## **3. Autenticazione (opzionale)**

- Registrazione nuovo account.
- Login con credenziali corrette.
- Login con credenziali errate.
- Logout.
- Recupero password.
- Cambio password, se previsto.
- Scadenza della sessione/token.
- Refresh automatico del token.
- Avvio dell’app con sessione già autenticata.
- Cancellazione account, se prevista.
- Verificare che un utente non possa accedere a schermate protette dopo il logout.

## **4. UX parti principali dell’app**

Per ogni funzionalità importante verificare almeno:

- Input vuoti.
- Input non validi.
- Errori restituiti dal backend.
- Dati mancanti o incompleti.
- Liste vuote.
- Liste molto lunghe.
- Loading lento.
- Operazioni ripetute rapidamente.
- Doppio tap sui pulsanti di conferma.
- Navigazione avanti/indietro durante un’operazione.

Eseguire manualmente tutti i principali percorsi che l’utente può fare, per esempio:

- Login → Home → dettaglio → modifica → salvataggio.
- Creazione di un nuovo elemento.
- Modifica di un elemento esistente.
- Eliminazione.
- Ricerca.
- Filtri e ordinamento.
- Paginazione/infinite scrolling.
- Upload/download, se presenti.
- Checkout/pagamento, se presenti.

## **5. Connessione di rete e API**

- App con Wi-Fi stabile.
- App con rete mobile.
- App senza connessione.
- Perdita della connessione durante una richiesta.
- Ripristino della connessione.
- Connessione molto lenta.
- Timeout API.
- Risposta API con dati incompleti o inattesi.
- Verificare retry e messaggi di errore.
- Controllare che uno stesso comando non venga inviato più volte accidentalmente.

## **6. Navigazione**

- Tutte le schermate principali sono raggiungibili.
- Back button Android funziona correttamente.
- Swipe-back iOS funziona dove previsto.
- Bottom navigation mantiene correttamente lo stato.
- Tab navigation mantiene lo stato.
- Apertura di modal e bottom sheet.
- Chiusura delle modal tramite gesture/back.
- Universal Links iOS.
- App Links Android.
- Apertura di una notifica verso la schermata corretta.

## **7. Lifecycle**

Testare l’app quando:

- Passa in background.
- Torna in foreground.
- Rimane in background per diversi minuti.
- Viene terminata dal sistema.
- Viene terminata manualmente dall’utente.
- Viene riaperta dopo essere stata terminata.
- Lo schermo viene bloccato e successivamente sbloccato.
- Arriva una telefonata o un’altra interruzione.
- L’utente cambia applicazione durante un’operazione.

Verificare soprattutto che non vengano perse operazioni o dati inseriti.

## **8. UI e responsive layout**

Testare almeno:

- Smartphone piccolo.
- Smartphone grande.
- Tablet & Watch, se supportati.
- Android con differenti densità dello schermo.
- iPhone con notch/Dynamic Island.
- Dispositivi con bottom gesture indicator.
- Orientamento portrait.
- Orientamento landscape, se supportato.

Controllare:

- Overflow Flutter.
- Testi tagliati.
- Pulsanti fuori schermo.
- SafeArea.
- Tastiera che copre input o pulsanti.
- Scroll delle schermate con molti contenuti.
- Dialog su schermi piccoli.
- Bottom sheet con tastiera aperta.

## **9. Accessibilità e impostazioni di sistema**

- Font di sistema normale.
- Font di sistema molto grande.
- Modalità chiara.
- Modalità scura.
- Contrasto sufficiente.
- Elementi interattivi sufficientemente grandi.
- Screen reader almeno sui flussi principali.
- VoiceOver su iOS.
- TalkBack su Android.
- Label semantiche corrette sui controlli importanti.
- Layout ancora utilizzabile con dimensione testo elevata.

## **10. Tastiera e form**

- Tastiera corretta per email.
- Tastiera numerica per numeri.
- Tastiera telefonica per numeri di telefono.
- Next/Done funzionano correttamente.
- Focus passa correttamente tra i campi.
- Tastiera può essere chiusa.
- Validazione viene mostrata correttamente.
- Errori vengono rimossi quando il valore diventa valido.
- Copy/paste funziona dove previsto.
- Autofill funziona dove previsto.
- Password manager funziona dove previsto.

## **11. Permessi**

Provare ogni permesso almeno in questi stati:

- Permesso concesso.
- Permesso negato.
- Permesso negato definitivamente.
- Permesso revocato successivamente dalle impostazioni di sistema.

Verificare, se utilizzati:

- Fotocamera.
- Microfono.
- Foto/galleria.
- Localizzazione.
- Bluetooth.
- Contatti.
- Calendario.
- Notifiche.

L’app non deve bloccarsi se un permesso viene negato.

## **12. Push notification**

- Richiesta del permesso notifiche.
- Token push registrato correttamente.
- Ricezione con app in foreground.
- Ricezione con app in background.
- Ricezione con app terminata.
- Tap sulla notifica.
- Navigazione verso il contenuto corretto.
- Payload incompleto/non riconosciuto.
- Aggiornamento del push token.
- Logout rimuove/disassocia correttamente il token, se necessario.

Separare i test APNs e FCM quando possibile.

## **13. Salvataggio locale**

- SharedPreferences.
- Secure Storage.
- Database locale.
- Cache.
- File salvati localmente.
- Dati mantenuti dopo riavvio.
- Dati mantenuti dopo aggiornamento app.
- Dati eliminati correttamente al logout quando richiesto.
- Dati sensibili non salvati in storage non sicuro.

## **14. Performance**

- Tempo di cold start accettabile.
- Tempo di warm start accettabile.
- Navigazione fluida.
- Liste lunghe senza evidenti rallentamenti.
- Immagini grandi senza bloccare l’interfaccia.
- Scroll fluido.
- Assenza di freeze durante chiamate API.
- Assenza di operazioni pesanti sul main isolate.
- Consumo RAM ragionevole.
- Consumo CPU ragionevole.
- Consumo batteria ragionevole.
- Nessuna crescita anomala della memoria dopo uso prolungato.

Eseguire queste verifiche utilizzando una build Release/Profile e non solamente Debug perché i sistemi hanno una gestione diversa su in debug o release mode.

## **15. Error handling**

- Nessun errore mostra stack trace all’utente.
- Errori API hanno messaggi comprensibili.
- Errori non recuperabili hanno una schermata/stato coerente.
- Pulsanti Retry funzionano.
- Loading indicator viene sempre rimosso.
- Non esistono schermate bloccate permanentemente in loading.
- Flutter error non gestiti vengono registrati dal sistema di crash reporting.
- Errori async non gestiti vengono registrati.
- Errori del codice nativo Android/iOS vengono registrati.

## **16. Crash reporting e analytics**

Se utilizzati strumenti come [Firebase Crashlytics](https://firebase.google.com/docs/crashlytics)
 o Sentry:

- Verificare che gli eventi arrivino dall’ambiente di produzione.
- Generare un crash di test.
- Controllare simbolicazione degli stack trace.
- Verificare dSYM iOS.
- Verificare mapping/deobfuscation Android.
- Controllare versione/build associata al crash.
- Verificare gli eventi analytics principali.
- Controllare che analytics non raccolga dati personali non previsti.
- Evitare eventi duplicati.

## **17. Android specifico**

- Test su almeno una versione Android relativamente vecchia ancora supportata.
- Test sull’ultima versione Android supportata.
- Test su dispositivo fisico.
- Back button.
- Gesture navigation.
- Notification channels.
- Runtime permissions.
- App Links.
- Condivisione verso l’app.
- Condivisione dall’app.
- Apertura tramite intent.
- Installazione tramite bundle equivalente alla distribuzione Play Store.
- Verificare `applicationId`.
- Verificare signing Release.
- Verificare `minSdk`, `targetSdk` e `compileSdk`.
- Verificare icona launcher.
- Verificare nome app.
- Verificare splash screen.
- Verificare adaptive icon.

## **18. iOS specifico**

- Test su almeno una versione iOS relativamente vecchia ancora supportata.
- Test sull’ultima versione iOS supportata.
- Test su iPhone fisico.
- Gesture back.
- Safe Area.
- Dynamic Island/notch.
- Push APNs.
- Universal Links.
- Sign in with Apple, se presente.
- Condivisione.
- Apertura tramite URL Scheme.
- Verificare Bundle Identifier.
- Verificare provisioning profile.
- Verificare certificati.
- Verificare icona.
- Verificare splash screen.
- Verificare stringhe di spiegazione dei permessi in `Info.plist`.
- Testare una build distribuita tramite TestFlight.

## **19. Sicurezza**

- Nessuna password salvata in chiaro.
- Nessun access token nei log.
- Nessuna API key privata inserita impropriamente nel client.
- HTTPS utilizzato per le comunicazioni sensibili.
- Sessione invalidata correttamente al logout.
- Dati appartenenti ad altri utenti non accessibili modificando ID lato client.
- Endpoint protetti realmente lato server.
- Input potenzialmente malevoli non causano comportamenti inattesi.
- Dati sensibili non finiscono negli analytics.
- Clipboard utilizzata con cautela per informazioni sensibili.
- Screenshot/app switcher non espongono schermate sensibili, se questo è un requisito dell’app.

## **20. Store e distribuzione**

### **Google Play**

- AAB Release generato correttamente.
- Signing corretto.
- Version Code incrementato.
- Version Name corretta.
- Target API compatibile con i requisiti Play.
- Data Safety aggiornata.
- Permessi dichiarati coerenti con l’utilizzo reale.
- Screenshot aggiornati, se necessario.
- Release notes corrette.
- Test tramite Internal/Closed Testing.

### **App Store**

- Archive Release corretto.
- Bundle ID corretto.
- Build Number incrementato.
- Marketing Version corretta.
- Signing corretto.
- Privacy Manifest/configurazioni privacy corretti.
- Descrizioni dei permessi corrette.
- App Privacy aggiornata.
- Screenshot aggiornati, se necessario.
- Release notes corrette.
- Test tramite TestFlight.

## **21. Smoke test sulla build realmente candidata alla pubblicazione**

La build verificata deve essere esattamente quella che verrà pubblicata.

- Installare la Release Candidate Android dal canale di testing Play.
- Installare la Release Candidate iOS da TestFlight.
- Login.
- Eseguire il flusso principale.
- Eseguire almeno una scrittura verso il backend.
- Verificare notifiche/deep link.
- Chiudere e riaprire l’app.
- Logout.
- Controllare crash reporting e log server.
- Confermare numero di versione e build visualizzati/installati.

## **Criterio minimo di go/no-go**

Non pubblicare se esiste almeno uno di questi problemi:

- Crash riproducibile in un flusso principale.
- Perdita o corruzione dei dati.
- Login/logout non affidabile.
- Migrazione dalla versione precedente non funzionante.
- Pagamento non affidabile.
- Problema di sicurezza noto.
- Funzionalità principale inutilizzabile.
- Backend di produzione configurato in modo errato.
- Signing/versioning errato.
- Build candidata diversa da quella effettivamente testata.

Naturalmente questo è un elenco esteso e non tutti questi controlli sono sempre necessari, ma tanti sì (prossimamente scriverò un articolo dove riassumo i testi principali, soprattutto in caso di minor release).