Template App Review Notes per Expo

1. A cosa servono le indicazioni per il team di verifica

Apple chiede spiegazioni per funzioni e acquisti non evidenti. Le note private completano contatto, account demo e allegati ed evitano percorsi bloccati.

Non sono una seconda descrizione. ‘Funziona tutto’ non aiuta; ‘Projects > Demo Project > Export apre il PDF senza acquisto’ è verificabile.

2. Informazioni minime

Mantieni nome, telefono, email e necessità di demo aggiornati e monitorati. Un contatto assente rallenta la review.

Inizia con versione e build, poi modifiche e condizioni di quell’artefatto. Elimina percorsi vecchi.

3. Un account demo robusto

Non deve dipendere dal tuo telefono, email temporanea, approvazione manuale o magic link che scade. Tieni backend e media online.

Usa dati fittizi che mostrino gli stati utili. Decidi se un account copre i ruoli e prova fuori dalla rete interna.

4. Descrivere flussi non evidenti

Indica prerequisito, navigazione, azione e risultato. Non far indovinare feature flag, ruolo, QR, posizione, Bluetooth o contenuto approvato. Allega un esempio fittizio se necessario.

Per permessi nomina la funzione; per cancellazione il percorso; per UGC segnala e blocca; per regione quella demo.

5. Acquisti e abbonamenti testabili

Gli IAP devono essere completi, attuali, visibili e funzionanti. Spiega paywall condizionale, prodotto regionale o ruolo richiesto.

Nomina prodotto visibile e percorso. Prova restore, abbonamento attivo, errore e reinstallazione. Se demo è premium, spiega come vedere paywall.

6. Modello pratico

Usa una struttura ripetibile senza boilerplate vecchio. Rimuovi ciò che non serve e aggiorna build, percorsi e account. Inglese semplice è spesso robusto.

BUILD
- Version / build: [1.0.0 / 42]
- Main change: [one factual sentence]

REVIEW ACCESS
- Demo account: [dedicated review account]
- Path: Launch app > Sign in > [feature]
- Required role or setup: [only if applicable]

NON-OBVIOUS FLOWS
- Purchase appears when: [condition]
- Account deletion: Settings > Account > Delete account
- Permission purpose: [feature and user value]

CONTACT
- Name: [responsible person]
- Email / phone: [monitored during review]

Tieni il modello nel processo release, non come secret nel file del progetto. Inserisci credenziali con flusso controllato e verifica numeri vecchi.

7. Rispondere a un rifiuto con prove

Leggi guideline e percorso, riproduci nel build rifiutato e decidi fra metadata o nuovo binario. Puoi rispondere e allegare prove prima del nuovo invio.

Indica causa, modifica e verifica con build e percorso. Chiedi passi esatti se non riproduci.

8. Controllo finale delle Notes

Chiedi a un’altra persona di seguire le Notes parola per parola su un dispositivo senza sessione. Non deve servire una spiegazione orale, VPN interna o diritto admin. Se si blocca, correggi prima prodotto o accesso: il testo non deve nascondere un flusso rotto.

Controlla anche build number, nome visibile del prodotto, menu localizzati, credenziali, regione e dati esempio. Apri ogni allegato e URL da una rete esterna. Il contatto deve conoscere la data di invio e poter rispondere durante la review.

9. Integrare le Notes nel processo di release

Le Notes scritte a memoria pochi minuti prima del submit diventano rapidamente inesatte. Crea una task di release con owner, data e build. Product conferma i percorsi, engineering verifica artefatto e dipendenze, support conosce il periodo in cui può arrivare una domanda. Conserva il testo inviato insieme al changelog per riprodurre esattamente ciò che il reviewer ha letto.

Dopo approvazione o rifiuto registra quale istruzione ha funzionato, dove il reviewer si è fermato e quale stato mancava. Non trasformare il feedback in boilerplate permanente: confronta ogni frase con il build successivo. Se cambiano percorso, ruolo, prodotto IAP, regione o account, aggiorna le Notes e ripeti la prova su un device pulito.

Definisci anche una procedura per le credenziali: chi può ruotarle, come evitare una scadenza durante la review e come verificare che il backend demo resti separato dai dati reali. Il contatto indicato deve avere accesso al contesto della release, non soltanto alla casella email. In questo modo una risposta può essere precisa senza condividere segreti o improvvisare.