In questa guida
Una build veloce non è un problema per il revisore. Ciò che fa rimandare indietro le app è ciò che una build veloce spesso lascia incompiuto: contenuti di test rimasti, funzioni scarne, informazioni sulla privacy mancanti. Questa pagina collega questi punti alla formulazione ufficiale, così puoi controllarli tu prima di inviare. Non sappiamo come lavorano internamente i revisori e non facciamo congetture.
L'autocontrollo, collegato alle linee guida
1. Testo segnaposto e contenuti temporanei
Apple, linea guida 2.1 (App Completeness): le versioni "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission." (dovrebbero essere versioni finali con tutti i metadati necessari e URL pienamente funzionanti; testo segnaposto, siti vuoti e altri contenuti temporanei devono essere eliminati prima dell'invio.)
Verifica: cerca nel progetto "lorem", "TODO", "test", "example.com". Apri ogni link nell'app e nella scheda (URL di supporto, URL della privacy, URL di marketing) su un telefono.
2. Crash e problemi tecnici evidenti
Stessa linea guida: "Make sure your app has been tested on-device for bugs and stability before you submit it... We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." (Assicurati che la tua app sia stata testata sul dispositivo per bug e stabilità prima di inviarla... Rifiuteremo bundle e binari incompleti che si bloccano o mostrano problemi tecnici evidenti.)
Verifica: installa la build di release, non quella di debug, su un telefono reale. Passa il primo avvio, la registrazione, il flusso principale e un riavvio. Vedi test su dispositivo reale e leggere i report di crash.
3. Login senza un modo per entrare
La linea guida 2.1 chiede anche di "include demo account info (and turn on your back-end service!) if your app includes a login." (includere le informazioni di un account demo, e attivare il tuo servizio back-end!, se l'app ha un login.)
Verifica: crea un account demo, inserisci i dati nelle note per il revisore e conferma che il back end è attivo quando invii.
4. Informativa sulla privacy mancante
Linea guida 5.1.1(i): "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." (Tutte le app devono includere un link alla propria informativa sulla privacy nel campo dei metadati di App Store Connect e nell'app, in modo facilmente accessibile.) L'informativa deve dire quali dati vengono raccolti e come vengono usati.
Verifica: il link funziona, è raggiungibile dentro l'app e corrisponde a ciò che l'app raccoglie davvero, inclusi i dati raccolti da librerie o servizi che hai aggiunto. Nessuna consulenza legale qui; chiedi a un professionista se hai dubbi.
5. App troppo poca cosa
Linea guida 4.2 (Minimum Functionality): l'app "should include features, content, and UI that elevate it beyond a repackaged website." (dovrebbe includere funzioni, contenuti e UI che la elevino oltre un sito web riconfezionato.)
Verifica: chiedi a qualcun altro cosa fa l'app che una pagina web non potrebbe fare. Se la risposta è scarna, aggiungi l'unica funzione reale prima di inviare.
6. Google Play
La guida "Sicurezza dei dati" di Google dice che tutti gli sviluppatori con un'app pubblicata su Google Play devono compilare il modulo Sicurezza dei dati, che le dichiarazioni devono corrispondere al comportamento reale dell'app inclusi librerie e SDK di terzi, e che un'informativa sulla privacy è obbligatoria. Se la tua app permette di creare un account, la guida di Google sull'eliminazione degli account chiede un percorso di eliminazione nell'app e un link web per le richieste di eliminazione. Anche Apple chiede l'eliminazione dell'account nell'app (linea guida 5.1.1(v)). Controlla le pagine attuali di Google prima di inviare.
Prima di premere invia
- Build di release su un telefono reale, percorso completo fatto
- Nessun contenuto segnaposto, tutti i link si aprono
- Link all'informativa sulla privacy nella scheda e nell'app
- Account demo nelle note per il revisore, back end attivo
- Una risposta di una frase a "cosa fa questa app?"
Per saperne di più sul controllo stesso, vedi motivi di rifiuto di App Store e come testare. Se arriva comunque un rifiuto, trattalo come un feedback: leggilo, correggi il punto indicato e usa questo modello di prompt se lavori con un assistente di coding.
Dove si inserisce AppReviewX
La maggior parte dell'elenco qui sopra viene trovata più in fretta da qualcuno che non ha costruito l'app. AppReviewX ti dà feedback privato e strutturato da altri sviluppatori: un feedback che scrivi ti fa guadagnare un credito, e i crediti servono per ricevere feedback sulla tua app; i nuovi account partono con 0 crediti. Per Android ci sono gruppi di test per il requisito di Google Play di 12 tester per 14 giorni consecutivi.
Correlati: Hub del vibe coding, ciclo di feedback con il tuo assistente di coding.
Le policy cambiano; controlla le linee guida collegate. Non è una consulenza legale.