Linee guida App Review 2026: checklist di prima pubblicazione per Apple e Google Play

Risposta rapida: Linee guida per la revisione delle app sono le regole che Apple e Google applicano prima del rilascio della tua app. Quelle di Apple Linee guida per la revisione dell'App Store sono suddivise in Sicurezza, Performance, Business, Design e Legale. Google Play esamina il tuo rilascio rispetto alle Politiche del Programma per Sviluppatori e ai requisiti di Play Console, come la classificazione dei contenuti e la Data safety. Tempi di revisione: Apple dichiara che l'App Review è attiva 24/7 e solitamente completa almeno il 50% delle richieste entro 24 ore e 90% entro 48 ore (Revisione dell'app). Google says some accounts may wait fino a sette giorni o anche di più in casi eccezionali (Pubblica la tua app). Anche i nuovi account personali Play Console potrebbero richiedere almeno 12 tester che rimangano iscritti per 14 giorni consecutivi nel closed testing, con almeno 12 ancora iscritti al momento della richiesta per la produzione. I primi rifiuti spesso derivano da 2.1 Completezza dell'app (crash, link interrotti, account demo non funzionanti), 2.3 Accuratezza dei metadati, e 5.1 Privacy su iOS, oltre a policy Play incomplete o passaggi di test su Android. Per le linee guida 4.2 e 4.3 strategia, leggi come superare la revisione dell'App Store nel 2026. Per le classificazioni e il parental control, consulta la guida alle classificazioni d'età dell'app store. Per le tariffe di iscrizione, vedi costo per pubblicare un'app sull'App Store.

Inviare la tua prima app all'App Store o al Play Store può sembrare un'impresa enorme. Con linee guida in continua evoluzione e controlli più severi nel 2026, ottenere l'approvazione richiede grande attenzione ai dettagli. Questa checklist ti guida su ciò che i revisori controllano al primo invio, sia per iOS che per Android; per playbook più approfonditi sui rifiuti di Apple, consulta la nostra come superare la revisione dell'App Store nel 2026 guida quando hai bisogno di dettagli più approfonditi rispetto a questa panoramica.

Comprendere il processo di revisione nel 2026

Sia Apple che Google hanno inasprito significativamente i loro processi di revisione negli ultimi anni, con un focus particolare su privacy, sicurezza ed esperienza utente. Comprendere questi cambiamenti è fondamentale per chi pubblica la prima app.

Tempistiche di revisione dell'App Store iOS

Apple pubblica le tempistiche nella sua pagina Revisione dell'app :

• Tempi tipici: Almeno il 50% degli invii viene revisionato in meno di 24 ore e il 90% in meno di 48 ore
• Invio incompleti: La revisione potrebbe subire ritardi o fallire se mancano metadati, accessi demo o risposte sulla compliance
• App complesse: Apple notes that apps needing greater scrutiny can take longer (Dopo l'invio)
• Revisione accelerata: Disponibile per bug critici o eventi con scadenza dopo l'invio tramite App Store Connect e l'invio della richiesta tramite il modulo di richiesta revisione accelerata di Apple

Pianifica in base alle medie pubblicate, non ai picchi sporadici, e considera ogni nota mancante nelle recensioni come un rischio di ritardo.

Stati di App Store Connect che vedrai

• Preparazione all'invio: Il tuo build o i metadati sono ancora in fase di preparazione
• In attesa di revisione: Apple ha messo la tua sottomissione in coda
• In revisione: Il team di revisione sta analizzando l'app
• In attesa di rilascio da parte dello sviluppatore: Approvata, in attesa della tua scelta di rilascio manuale
• Rifiutata / Problemi non risolti: Apple richiede modifiche prima dell'approvazione

Tempi di revisione Google Play Store (Update 2026)

Google documenta i tempi di revisione per Pubblica la tua app:

• Pubblicazione standard: Gli update vengono elaborati e pubblicati il prima possibile dopo la revisione
• Revisione prolungata: Per alcuni account developer, Google potrebbe impiegare fino a sette giorni o più in casi eccezionali
• Fase di closed testing: Gli account personali creati dopo il 13 novembre 2023 richiedono almeno 12 tester che rimangano iscritti continuamente per almeno 14 giorni consecutivi di closed testing, e almeno 12 tester devono essere ancora iscritti al momento della richiesta di accesso alla produzione
• Dopo il testing: La revisione per la produzione segue comunque le policy di Play prima del rilascio

Update importante: Google ora richiede test molto più rigorosi per alcuni nuovi account Play Console, di cui parleremo nel dettaglio qui sotto.

Configurazione dell'account Apple Developer

Prima del tuo primo rilascio iOS, assicurati che il lato Apple sia configurato correttamente:

• Iscriviti all' Apple Developer Program
• Attiva l'autenticazione a due fattori per l'Apple Account usato per l'iscrizione
• Scegli il tipo di membership corretto:
  • Persona fisica / Ditta individuale: il tuo nome legale diventerà il nome del venditore sull'App Store
  • Organizzazione: richiede un'entità legale, un numero D-U-N-S, un sito web pubblico e una persona autorizzata a vincolare l'azienda agli accordi Apple
• Usa nomi legali durante l'iscrizione. Alias o nomi aziendali nei campi nome/cognome possono ritardare l'approvazione
• Una volta approvata l'iscrizione, accedi ad App Store Connect e crea il record dell'app con il bundle ID finale, il nome dell'app, lo SKU e la lingua principale

Importante: Apple aggiorna periodicamente i requisiti minimi di SDK. A partire dal 28 aprile 2026, le app caricate su App Store Connect devono utilizzare iOS & iPadOS 26 SDK o versioni successive.

Il requisito critico per i test su Android

Questo è il cambiamento che coglie impreparati la maggior parte dei nuovi publisher Android:

Requisito di 12 tester per nuovi account Android personali

Se il tuo account developer Google Play è un account personale creato dopo il 13 novembre 2023, è necessario completare un periodo di testing chiuso prima di passare alla produzione:

Requisiti:

• Minimo 12 tester: devi avere almeno 12 tester che rimangano iscritti in modo continuo
• Periodo di testing di 14 giorniI tester devono rimanere iscritti durante il periodo di closed testing per un minimo di 14 giorni consecutivi
• Richiesta di accesso alla produzione: al momento della richiesta, almeno 12 tester devono essere ancora iscritti dopo il testing chiuso
• Raccolta feedback: Dovresti documentare i problemi riscontrati, le correzioni apportate e come i tester hanno usato l'app

Come configurare il tuo testing track

Perché Google ha implementato questa funzione

Google ha introdotto questo requisito per:

• Riduci lo spam di app di bassa qualità
• Garantire che le app siano testate adeguatamente prima di arrivare agli utenti
• Identifica app malevole tramite pattern di utilizzo reali
• Migliora la qualità complessiva del Play Store

Un bagno di realtà: Questo aggiunge almeno 2-3 settimane alla timeline di lancio. Pianifica di conseguenza e inizia presto a reclutare tester.

Requisiti di autenticazione e login

Una delle cause più comuni di rifiuto è l'implementazione errata dei sistemi di autenticazione, specialmente il social login.

Requisito Apple Sign-In (critico per iOS)

Regola di Apple: Se la tua app offre opzioni di social login di terze parti (Google, Facebook, Twitter, ecc.), tu devi offrono anche Sign in with Apple come opzione.

Questo si applica a:

• Google Sign-In
• Facebook Login
• Login con Twitter/X
• Login con LinkedIn
• Qualsiasi altro servizio di autenticazione di terze parti

Questo NON si applica a:

• Autenticazione solo tramite email/password
• Sistemi di identità governativa
• Sistemi SSO aziendali (se l'app è dedicata a quell'azienda)
• Sistemi di autenticazione di enti formativi

Implementare Sign in with Apple

Se usi il social login, ecco cosa devi implementare:

import { SignInWithApple } from '@capacitor-community/apple-sign-in';

async function signInWithApple() {
  try {
    const result = await SignInWithApple.authorize({
      clientId: 'com.yourapp.service',
      redirectURI: 'https://yourapp.com/auth/callback',
      scopes: 'email name',
      state: '12345',
      nonce: 'nonce',
    });

    // result contains:
    // - identityToken
    // - authorizationCode
    // - email (may be null if user previously authorized)
    // - givenName
    // - familyName

    // Send to your backend for verification
    await verifyAppleToken(result.identityToken);

  } catch (error) {
    console.error('Apple Sign In failed:', error);
  }
}

Considerazioni importanti:

1. Privacy dell'Email: Gli utenti possono scegliere di nascondere la propria email. Apple fornisce un indirizzo tramite relay privato (es. abc123@privaterelay.appleid.com). La tua app deve saperlo gestire.

2. Nuovi utenti vs Utenti ricorrenti: Apple fornisce i dettagli dell'utente (nome, email) solo al primo login. Salva queste informazioni, poiché i successivi non le includeranno.

3. Design del pulsante: Apple impone linee guida rigorose per il pulsante Sign in with Apple. Usa i loro asset ufficiali.

4. Verifica Backend: Verifica sempre l'identity token sul tuo server backend; non fidarti mai solo dei token lato client.

Requisiti per il Social Login su Android

Sebbene Android non richieda un provider specifico come iOS, Google ha delle linee guida:

Requisiti per Google Sign-In:

• È necessario usare l'SDK ufficiale di Google
• Bisogna seguire le linee guida di branding di Google
• Dovrebbe essere l'opzione principale se la offri

Best Practice per il Cross-Platform: Offri le stesse opzioni di login su entrambe le piattaforme per coerenza:

• Email/password
• Sign in with Apple (solo iOS, o su Android se supporti il login Apple via web)
• Accedi con Google
• Altre opzioni social (Facebook, Twitter, ecc.)

Requisiti per l'account demo

Fondamentale per la Review: Se la tua app richiede il login, devi devi fornire credenziali demo funzionanti nelle App Review Notes.

Demo Account Information:

Username: reviewer@demo.com
Password: ReviewTest123!

OR

Test Phone: +1 555-0123
Test OTP: 123456 (static for review)

Notes:
- This account has full premium features enabled
- All payment flows work in sandbox mode
- Account will reset daily

Errori comuni:

• Fornire credenziali scadute
• L'account demo non ha accesso a tutte le funzionalità
• Non indicare come bypassare la verifica telefonica
• Dimenticare i dettagli dei pagamenti in sandbox

Privacy Policy e requisiti legali

Entrambi gli app store ora richiedono privacy policy e termini di servizio accessibili prima la tua prima submission viene approvata.

Requisiti per la Privacy Policy

La tua privacy policy deve:

1. Essere accessibile pubblicamente

   • Essere ospitata su un URL pubblico (senza login)
   • Essere caricabile dai browser standard
   • Essere disponibile nelle stesse lingue della tua app

2. Coprire questi argomenti obbligatori:

   • Quali dati raccogli (sii specifico)
   • Come utilizzi i dati raccolti
   • Se i dati vengono condivisi con terze parti
   • Durata della conservazione dei dati
   • Diritti dell'utente (accesso, cancellazione, portabilità)
   • Contatti per richieste sulla privacy
   • Privacy dei minori (se l'app è per utenti <13/16 anni)

3. Link all'interno dell'app

   • Accessibile dalle impostazioni o dall'account
   • Deve essere a un solo tap (non nascosto nei menu)
   • Deve aprirsi nel browser predefinito o in-app

Dove ospitare l'informativa sulla privacy

Opzione 1: Il tuo sito web (Consigliato)

https://yourapp.com/privacy-policy
https://yourapp.com/terms-of-service

Opzione 2: Pagine GitHub (Gratis)

https://yourusername.github.io/app-privacy-policy

Opzione 3: Generatori di Privacy Policy (Guida rapida)

• Termly
• PrivacyPolicies.com
• FreePrivacyPolicy.com

Importante: I generator sono utili per iniziare, ma assicurati che la policy rifletta fedelmente il tuo trattamento dati. I template generici non coerenti con l'app verranno segnalati.

Requisiti per i Termini e Condizioni

Anche se non sempre obbligatori, i Termini e Condizioni sono caldamente raccomandati e necessari se:

• Offri acquisti in-app o abbonamenti
• Hai contenuti generati dagli utenti
• Offri servizi oltre le funzioni base dell'app
• Vuoi una protezione legale

Da includere:

• Politica d'uso accettabile
• Condizioni di chiusura dell'account
• Limitazione di responsabilità
• Diritti di proprietà intellettuale
• Procedura di risoluzione delle controversie
• Politica di rimborso (specialmente per IAP)

Implementazione in-app

// Settings or Account Screen
function LegalLinks() {
  return (
    <div className="legal-section">
      <h3>Legal</h3>
      <a
        href="https://yourapp.com/privacy-policy"
        target="_blank"
        rel="noopener noreferrer"
      >
        Privacy Policy
      </a>
      <a
        href="https://yourapp.com/terms-of-service"
        target="_blank"
        rel="noopener noreferrer"
      >
        Terms of Service
      </a>
      <a
        href="https://yourapp.com/contact"
        target="_blank"
        rel="noopener noreferrer"
      >
        Contact Us
      </a>
    </div>
  );
}

Requisiti dei metadati App Store

Entrambi gli store richiedono l'URL della privacy policy durante l'invio dell'app:

iOS - App Store Connect:

• Informazioni sull'app > Informazioni generali > URL dell'informativa sulla privacy
• Deve essere HTTPS (HTTP verrà rifiutato)
• Verrà visualizzato sulla tua pagina App Store
• Aggiungi un URL di supporto con recapiti reali per gli utenti
• Completa il questionario sulla classificazione dell'età prima dell'invio

Android - Google Play Console:

• Presenza nello store > Impostazioni dello store > Informativa sulla privacy
• Obbligatorio per tutte le app rivolte ai bambini
• Fortemente raccomandato per tutte le app

Etichette nutrizionali per la privacy (iOS)

iOS richiede informative dettagliate sulla privacy nel formato “nutrition label”:

Categorie da dichiarare:

• Info di contatto: Email, nome, numero di telefono
• Dati finanziari: Info di pagamento, carta di credito, conto bancario
• Posizione: Posizione precisa o approssimativa
• Contenuti dell'utente: Foto, video, audio, messaggi
• Identificatori: ID utente, ID dispositivo, ID pubblicitario
• Dati di utilizzo: Interazione con il prodotto, dati pubblicitari, crash logs
• Diagnostica: Dati sui crash, dati sulle performance

Per ogni tipo di dato, specifica:

• Se viene raccolto
• Se è collegato all'identità dell'utente
• Se viene usato per il tracking
• La finalità della raccolta

Errore comune: Dichiarare di non raccogliere dati quando la tua SDK lo fa. Verifica la raccolta dati di tutti gli SDK di terze parti.

Sezione Sicurezza dei dati Google Play

Come su iOS, anche Android richiede una dichiarazione sulla sicurezza dei dati:

Passi:

1. Vai su Play Console > Contenuto app > Sicurezza dei dati
2. Rispondi alle domande sulla raccolta dei dati
3. Specifica le tipologie di dati raccolti
4. Spiega le pratiche di sicurezza (crittografia, ecc.)
5. Inserisci il link alla privacy policy

Critico: Queste informazioni hanno valore legale. Dichiarazioni false possono causare la rimozione dell'app e la sospensione dell'account.

Motivi comuni di rifiuto al primo invio

Capire perché le app vengono rifiutate ti aiuta a evitare questi errori:

1. Crash dell'app o mancato avvio

Perché accade:

• Test solo su emulatore, non su dispositivo reale
• Manca la gestione degli errori di rete
• Endpoint API hardcoded e irraggiungibili
• Dare per scontate capacità specifiche del dispositivo (camera, GPS)

Come prevenire:

// Always implement proper error handling
async function loadData() {
  try {
    const response = await fetch('https://api.yourapp.com/data');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    // Show user-friendly error
    showError('Unable to load data. Please check your connection.');

    // Log for debugging
    console.error('Data load failed:', error);

    // Graceful degradation
    return getCachedData();
  }
}

Checklist di test:

• Test su dispositivi reali (minimo 2-3 modelli diversi)
• Test con rete instabile (usa Network Link Conditioner)
• Test in modalità aereo
• Test con permessi negati
• Test con installazione pulita (senza dati in cache)

2. Funzionalità core mancanti o non funzionanti

Perché accade:

• Funzionalità mostrate negli screenshot non ancora presenti
• L'account demo non ha accesso alle feature pubblicizzate
• Feature premium mostrate ma non implementate
• Placeholder “Coming Soon” presenti nell'app

Come prevenire:

• Invia l'app solo quando tutte le feature sono complete
• Assicurati che l'account demo abbia accesso completo
• Rimuovi o disabilita le feature incomplete prima dell'invio
• Aggiorna gli screenshot per riflettere l'attuale build

3. Contenuti non idonei al rating per età

Perché accade:

• Classificazione età impostata su 4+ ma l'app ha funzioni social
• La classificazione età non corrisponde ai contenuti reali
• Contenuti generati dagli utenti senza moderazione
• Link a contenuti esterni non moderati

Come impostare la classificazione età corretta:

Classificazioni età iOS:

• 4+ (nessun contenuto inappropriato)
• 9+ (contenuti lievi occasionali)
• 12+ (contenuti moderati)
• 17+ (contenuti frequenti/intensi)

Classificazioni contenuti Android:

• Per tutti
• Tutti 10+
• Adolescenti
• Adulti 17+
• Solo per adulti 18+

Importante: Se gli utenti possono condividere contenuti, serve:

• Sistema di moderazione dei contenuti
• Funzionalità di segnalazione/blocco
• Linee guida chiare della community
• Controllo dell'età, se necessario

4. Metadati ingannevoli o fuorvianti

Perché accade:

• Il nome dell'app promette funzioni inesistenti
• Screenshot di competitor o mockup
• Recensioni false o manipolazione dei rating
• La descrizione contiene superlativi senza prove

Esempi di metadati problematici:

❌ SBAGLIATO:

• Nome App: “Best Fitness Tracker - #1 App”
• Descrizione: “L'app più incredibile e rivoluzionaria mai creata!”
• Screenshot: Foto stock generiche

✅ CORRETTO:

• Nome App: “FitTrack - Workout Logger”
• Descrizione: “Monitora i tuoi allenamenti con routine personalizzabili e grafici dei progressi.”
• Screenshot: Schermate reali dell'attuale build

5. Testing insufficiente (specialmente Android Closed Testing)

Perché accade:

• Saltare il periodo di test obbligatorio di 14 giorni
• Non reclutare un numero sufficiente di tester
• I tester non usano realmente l'app
• Mancanza di crash monitoring durante i test

Come prevenire:

• Inizia a reclutare tester 3-4 settimane prima del lancio
• Usa Firebase Crashlytics o simili durante i test
• Interagisci attivamente con i tester (survey, feedback)
• Risolvi i bug critici prima del rilascio in produzione

6. Permessi senza giustificazione

Perché accade:

• Posizione richiesta ma non utilizzata
• Permesso fotocamera senza spiegazione
• Accesso ai contatti senza scopo chiaro
• Posizione in background per app non di navigazione

Come risolvere:

iOS - Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to scan QR codes for quick login.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Location helps us show nearby fitness centers and outdoor running routes.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Photo library access lets you upload a profile picture and share workout photos.</string>

Android - Strategia dei permessi:

<!-- Only request what you actually need -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Use when-in-use rather than always for location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- Avoid if possible -->
<!-- <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> -->

Richiesta permessi a runtime:

import { Camera } from '@capacitor/camera';

async function takePicture() {
  // Request with context
  const permissionStatus = await Camera.requestPermissions();

  if (permissionStatus.camera === 'granted') {
    const photo = await Camera.getPhoto({
      quality: 90,
      allowEditing: true,
      resultType: 'uri'
    });

    return photo;
  } else {
    // Explain why permission is needed
    showDialog(
      'Camera access required',
      'To upload a profile picture, please enable camera access in Settings.'
    );
  }
}

Requisiti specifici per iOS

Screenshot e anteprime App Store

Dimensioni richieste:

• iPhone 6.7”: 1290 x 2796
• iPad 13”: 2064 x 2752
• iPad 12.9”: 2048 x 2732

Importante: Se la tua app supporta iPad, devi caricare gli screenshot iPad. Non allungare gli screenshot iPhone per riempire gli slot iPad.

Best practice per gli screenshot:

• Devono mostrare contenuti reali dell'app (niente mockup)
• Rimuovi la status bar o mostra contenuti realistici
• Localizza per tutte le lingue supportate
• Evita overlay di testo eccessivi
• Mostra le funzionalità principali nei primi 2-3 screenshot

Configurazione dei metadata su App Store Connect

Prima di inviare, completa questi campi su App Store Connect:

• URL della Privacy Policy: obbligatorio per le app iOS
• URL di supporto: obbligatorio, deve contenere dati di contatto reali
• Age Rating: completa il questionario per pubblicare l'app
• Informazioni per la revisione dell'app: aggiungi un contatto per la revisione, credenziali demo funzionanti se serve il login e note chiare per il team
• Conformità all'esportazione: rispondi alle domande sulla crittografia o imposta ITSAppUsesNonExemptEncryption nella Info.plist quando necessario, per evitare di ripetere le stesse risposte a ogni upload

TestFlight prima della revisione

Esegui un vero test su TestFlight prima della revisione in produzione:

• Installa la build esatta da TestFlight
• Accedi con lo stesso account di revisione che fornirai
• Verifica i flussi di acquisto, ripristino e cancellazione
• Conferma che il revisore possa accedere alle feature chiave senza setup nascosto
• Testa su iPhone e iPad se entrambi sono supportati

Video di anteprima dell'app (opzionali ma consigliati)

Requisiti:

• Durata di 15-30 secondi
• Devono mostrare filmati reali dell'app
• Possono includere brevi overlay di testo
• Nessuna musica con problemi di copyright
• Stesse risoluzioni degli screenshot

Implementazione di Sign in with Apple

Già citato sopra, ma fondamentale per la review iOS se usi social login.

Requisiti per gli In-App Purchase

Se offri beni o servizi digitali:

Informative obbligatorie:

• Prezzi chiari prima dell'acquisto
• Termini dell'abbonamento chiari
• Istruzioni per la cancellazione visibili
• Pulsante ripristina acquisti

Esempio schermata abbonamento conforme:

function SubscriptionOffer() {
  return (
    <div className="subscription-screen">
      <h2>Choose Your Plan</h2>

      <PlanCard>
        <h3>Monthly</h3>
        <p className="price">$9.99/month</p>
        <ul>
          <li>Unlimited workouts</li>
          <li>Personalized plans</li>
          <li>Progress tracking</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <PlanCard>
        <h3>Annual</h3>
        <p className="price">$79.99/year</p>
        <p className="savings">Save 33%</p>
        <ul>
          <li>Everything in Monthly</li>
          <li>Priority support</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <div className="subscription-terms">
        <p>
          Subscription automatically renews unless cancelled at least
          24 hours before the end of the current period. Manage your
          subscription in Settings.
        </p>
        <button onClick={restorePurchases}>Restore Purchases</button>
      </div>

      <div className="legal-links">
        <a href="/privacy/">Privacy Policy</a> |
        <a href="/terms">Terms of Service</a>
      </div>
    </div>
  );
}

Requisiti specifici per Android

Configurazione account Google Play Console

Prima del primo rilascio su Android, assicurati che l'account Play Console e l'app shell esistano:

• Crea il tuo account developer su Registrazione Play Console
• In Play Console, vai su Home &gt; Crea app
• Scegli la lingua predefinita, il tipo di app/gioco e l'email di supporto
• Accetta le dichiarazioni obbligatorie su policy Play, esportazione e Play App Signing
• Decide whether the app is gratuita o a pagamento

Importante: Google permette di rendere gratuita in seguito un'app a pagamento, ma una volta che un'app è stata offerta gratuitamente non può più tornare a pagamento.

Requisito App Bundle

Importante: Google Play richiede il formato Android App Bundle (.aab), non APK:

# Sync the native Android project first
bunx cap sync android

# Then build the release app bundle
cd android
./gradlew bundleRelease

Requisito del livello target API

Requisito attuale: Le nuove app e gli aggiornamenti devono avere come target Android 15 (API livello 35) o superiore.

Aggiorna in android/app/build.gradle:

android {
    compileSdkVersion 35

    defaultConfig {
        targetSdkVersion 35
        minSdkVersion 23  // Minimum supported version
    }
}

Sicurezza dei dati di Google Play

Già trattato sopra, ma assolutamente cruciale per l'approvazione su Android.

Canale di test chiuso (requisito attuale)

Questa è la sfida principale per i nuovi account developer personali: il requisito dei 12 tester con opt-in continuo per 14 giorni descritto prima in questa guida.

Tempistica:

1. Settimana 1: Reclutamento tester e setup del test chiuso
2. Settimana 2-3: Periodo di testing attivo (minimo 14 giorni)
3. Settimana 4: Risoluzione bug e preparazione al rilascio in produzione
4. Settimana 5: Invio per la revisione di produzione

Target e classificazione dei contenuti

Questionario sulla classificazione dei contenuti:

• Obbligatorio per tutte le app
• Richiede 10-15 minuti per completarlo
• Determina la classificazione per età (Everyone, Teen, Mature, ecc.)
• Aggiornalo ogni volta che i contenuti cambiano influenzando le risposte

Argomenti trattati:

• Violenza
• Contenuti sessuali
• Profanity
• Sostanze controllate
• Gioco d'azzardo
• Funzionalità di interazione utente

Importante: Se utilizzi contenuti generati dagli utenti o social feature, devi dichiararlo e implementare la moderazione.

Requisiti per la scheda dello store

Asset richiesti:

• Icona app (512 x 512 PNG)
• Feature graphic (1024 x 500 JPG o PNG)
• Screenshot smartphone (min. 2, max. 8)
• Screenshot tablet 7” (opzionali ma consigliati)
• Screenshot tablet 10” (opzionali ma consigliati)

Requisiti della descrizione:

• Descrizione breve (max 80 caratteri)
• Descrizione completa (max 4000 caratteri)
• Deve descrivere accuratamente le funzionalità dell'app
• Non può includere contatti o prezzi

Checklist pre-invio

Prima di inviare l'app, segui questa checklist completa:

Requisiti tecnici

• L'app si avvia correttamente sui dispositivi reali
• Tutte le feature negli screenshot funzionano
• Nessun contenuto placeholder o “Prossimamente”
• Tutte le chiavi API di terze parti sono chiavi di produzione
• Gestione degli errori di rete implementata
• Le richieste di permessi includono spiegazioni chiare
• L'app non crasha con connessione instabile
• Testata con permessi negati
• Tested on minimum supported OS version
• Memory leak controllati e risolti

Autenticazione e Login

• Se usi il social login, è incluso Sign in with Apple (iOS)
• Credenziali dell'account demo fornite nelle note di revisione
• L'account demo ha accesso a tutte le funzionalità
• Il flusso di reset password funziona
• La funzione di logout funziona correttamente
• Opzione di eliminazione account disponibile (richiesta da GDPR/CCPA)

Note legali e privacy

• Privacy policy accessibile pubblicamente
• URL della privacy policy aggiunto alla scheda dell'app store
• Termini di servizio accessibili pubblicamente (se applicabili)
• Privacy policy linkata nell'app (schermata Impostazioni)
• Etichette nutrizionali sulla privacy accurate (iOS)
• Sezione Sicurezza dei dati completata (Android)
• Tutte le finalità di raccolta dati spiegate
• Raccolta dati SDK di terze parti dichiarata

Contenuti e metadati

• Nome app conforme alle linee guida (senza keyword stuffing)
• Descrizione fedele alle funzionalità
• Gli screenshot mostrano le schermate reali dell'app
• Screenshot localizzati per tutte le lingue supportate
• Nessun riferimento ai competitor nella descrizione
• Nessun superlativo senza prove
• Classificazione per età coerente con i contenuti
• Email di contatto monitorata

Specifico per iOS

• Sign in with Apple implementato (se usi social login)
• Screenshot di tutte le dimensioni richieste forniti
• Screenshot iPad reali caricati se il supporto iPad è attivo
• Descrizioni dei permessi in Info.plist chiare
• URL di supporto aggiunto con dati di contatto reali
• URL della Privacy Policy aggiunto in App Store Connect
• Age rating questionnaire completed
• Conformità all'esportazione compilata correttamente
• Contatti per l'App Review e account demo senza scadenza forniti
• iOS 15.0 o versioni successive
• Se IAP: prezzi chiari e tasto restore presenti
• Nessun riferimento ad Android o altre piattaforme

Specifico per Android

• Formato App Bundle (.aab) utilizzato
• Target API 35 o superiore
• Content rating questionnaire completed
• Feature graphic caricata
• Closed testing completato se richiesto da Play Console (12 tester attivi per 14 giorni consecutivi, con almeno 12 ancora attivi al momento dell'invio)
• Crash report dei test revisionati e risolti
• Nessun riferimento a iOS o altre piattaforme

Testing (requisito attuale per Android)

• Almeno 12 tester reclutati se il tuo account Play richiede il closed testing
• Track di closed testing creata
• Oltre 12 tester sono rimasti attivi per 14 giorni consecutivi e almeno 12 erano ancora attivi al momento della richiesta
• I tester hanno effettivamente usato l'app (non solo installata)
• Monitoraggio dei crash abilitato durante i test
• Bug critici rilevati durante i test risolti
• Feedback dei tester documentati

Note per la review: cosa includere

Note di revisione efficaci possono fare la differenza tra approvazione immediata e rifiuto. Ecco cosa includere:

Template per le note di review

APP REVIEW INFORMATION

=== Test Account ===
Email: reviewer@testapp.com
Password: TestReview123!
(This account has all premium features enabled)
(This account stays active during review)

=== Review Contact ===
Name: Jane Developer
Email: review@yourapp.com
Phone: +1 555-0100

=== Testing Instructions ===
1. Launch app and tap "Sign In"
2. Enter test credentials above
3. Navigate to "Dashboard" to see main features
4. Tap "Upgrade" to test subscription flow (sandbox mode)
5. Go to Settings > Account to see privacy policy and terms

=== Key Features to Test ===
- Workout tracking (tap "New Workout" on Dashboard)
- Progress charts (Analytics tab)
- Social sharing (Share button on workout details)
- Camera upload for profile picture (Settings > Profile)

=== Third-Party Services ===
- Firebase Authentication (for login)
- Stripe (for payments - sandbox mode)
- AWS S3 (for image uploads)
- Google Maps SDK (for location features)

=== Notes ===
- Location permission is optional, app works without it
- Camera permission only requested when uploading profile picture
- All subscription flows use Apple/Google sandbox environments
- Background location is not used
- Support URL and privacy policy are available from Settings > Account

=== Contact ===
For questions: developer@yourapp.com
Response time: Within 24 hours

Note di review per iOS

Per iOS, includi anche:

=== Device Coverage ===
Tested on: iPhone 15 Pro Max, iPad Pro 13-inch

=== App Store Connect Metadata ===
Support URL: https://yourapp.com/support
Privacy Policy: https://yourapp.com/privacy-policy

=== Submission Notes ===
- iPad screenshots match the current iPad UI
- Export compliance answered for this build
- Sign in with Apple is available on the login screen

Note di review per Android

Per Android, includi anche:

=== Testing Track Information ===
Closed testing period: [Start Date] to [End Date]
Number of active testers: 23
Critical issues found during testing: 2 (both fixed)
Test distribution method: Email invite list

=== Crash Data ===
Testing period crashes: 3 total
Crash rate: 0.8%
All crashes fixed in this build

=== API Levels ===
Target SDK: 35 (Android 15)
Min SDK: 23 (Android 6.0)
Tested on: Android 11, 12, 13, 14, 15

Cosa fare in caso di rifiuto

Niente panico: il rifiuto è comune, specialmente alla prima submission. Ecco come gestirlo:

Passaggi dopo un rifiuto

Risposte ai rifiuti più comuni

Rifiuto: “L'app crasha all'avvio”

Risposta:

I sincerely apologize for the crash. I have identified and fixed
the issue:

Root cause: The app attempted to fetch data before network
initialization completed, causing a null reference exception.

Fix: Implemented proper async initialization with error handling
and offline mode. The app now gracefully handles network issues.

Testing: Verified on iPhone 12 (iOS 17), iPhone 14 Pro (iOS 17.1),
tested with WiFi, cellular, and airplane mode.

Build version: 1.0.2 (build 3)

Rifiuto: “Privacy policy mancante”

Risposta:

Thank you for the feedback. I have added the privacy policy:

URL: https://myapp.com/privacy-policy
Location in app: Settings > Privacy Policy (tappable link)
Also added to: App Store Connect > App Information > Privacy Policy URL

The privacy policy covers all data collection as disclosed in the
Privacy Nutrition Labels.

Rifiuto: “Non conforme alla regola 4.2 - Funzionalità minima”

È più complicato. Significa che la tua app non offre abbastanza valore per essere considerata tale. Leggi come superare la revisione dell'App Store nel 2026 la guida completa per rispondere alle violazioni 4.2 e 4.3. Esempio di testo per il ricorso:

Risposta:

Thank you for the feedback. I'd like to clarify the app's
functionality:

Core Features:
1. [Feature 1 with specific details]
2. [Feature 2 with specific details]
3. [Feature 3 with specific details]

The app provides significant utility beyond a simple website by:
- Offline functionality for [specific feature]
- Native camera integration for [specific feature]
- Push notifications for [specific feature]
- Device hardware access for [specific feature]

Test account credentials have been provided to demonstrate all
features. Please let me know if you need additional clarification.

Best practice post-approvazione

Congratulazioni! La tua app è stata approvata. Ecco come mantenere questo status:

Monitoraggio post-lancio

Metriche critiche da monitorare:

• Crash rate (mantienilo sotto l'1%)
• ANR rate (Android - mantienilo sotto lo 0,5%)
• Valutazioni App Store/Play Store
• Rivedi i contenuti (rispondi a tutte le recensioni)
• Bug segnalati dagli utenti

Strumenti da utilizzare:

• Firebase Crashlytics
• Analytics di App Store Connect
• Google Play Console Vitals
• Sentry o simili per l'error tracking

Linee guida per gli update

Quando invii aggiornamenti:

• Testa con la stessa accuratezza della prima submission
• Aggiorna gli screenshot se la UI è cambiata molto
• Aggiorna le etichette privacy se cambia la raccolta dati
• Fornisci descrizioni chiare per “Novità”
• Considera i rollout graduali per i cambiamenti importanti

Rimanere conformi

Requisiti annuali:

• Rinnova il content rating di Android (obbligatorio ogni anno)
• Aggiorna la privacy policy se cambiano le pratiche
• Controlla e aggiorna i rating per età se cambia il contenuto
• Verifica la compliance degli SDK di terze parti

Monitoraggio continuo:

• Stay updated on guideline changes
• Iscriviti alle newsletter per developer di Apple/Google
• Partecipa alle community di developer
• Segui i blog sulle policy di App Store/Play Store

Risorse e approfondimenti

Documentazione ufficiale

Apple:

• Linee guida per la revisione dell'App Store
• Accedi con Apple
• Guida di App Store Connect
• Privacy e uso dei dati

Google:

• Centro Politiche per gli Sviluppatori
• Checklist di lancio
• Sezione sulla sicurezza dei dati
• Linee guida per i test

Risorse della community

• r/androiddev - Community di sviluppatori Android
• r/iOSProgramming - Community di sviluppatori iOS
• Stack Overflow - Domande tecniche
• Indie Hackers - Community di sviluppatori indie

Strumenti per la Privacy Policy

• Generatore della Privacy Policy di Termly
• PrivacyPolicies.com
• Privacy Policy gratuita

Frequently asked questions

Cosa sono le linee guida per la revisione delle app?
Sono quelle di Apple Linee guida per la revisione dell'App Store e di Google Policy del Programma DeveloperI revisori controllano il binario, i metadati, le informative sulla privacy e la configurazione dell'account prima del rilascio.

Quanto tempo richiede la revisione dell'app nel 2026?
Apple punta a revisionare il 50% delle sottomissioni entro 24 ore e il 90% entro 48 ore. Google può richiedere fino a sette giorni o più per alcuni account. I nuovi account personali Play Console richiedono inoltre almeno 12 tester che rimangano iscritti per almeno 14 giorni consecutivi di closed testing, con almeno 12 ancora attivi al momento della richiesta, laddove la regola si applichi.

Quali sono le cinque sezioni delle linee guida Apple?
Sicurezza, Performance, Business, Design e Legale. Performance riguarda completezza e metadati (incluso il 2.3). Legale riguarda la privacy (incluso il 5.1).

Cosa dovrei sistemare prima della prima sottomissione?
Login demo funzionanti, link HTTPS per privacy e supporto, etichette privacy accurate, test su dispositivi reali e asset dello store coerenti con il build. Completa il questionario sulla classificazione dell'età su entrambi gli store, se applicabile alla tua app.

Dove si collocano le linee guida 4.2 e 4.3?
Si tratta di rifiuti relativi al design di Apple per app troppo semplici o duplicate. Usa come superare la revisione dell'App Store nel 2026 per quell'ambito, non per questa checklist.

Quanto costa pubblicare su Apple?
Vedi costo per pubblicare un'app sull'App Store per le attuali quote di iscrizione e pubblicazione.

Ti serve aiuto con la revisione dell'app?

Se ti senti sopraffatto o cerchi una guida esperta per far passare la revisione alla tua app al primo colpo, siamo qui per aiutarti!

Prenota una call di consulenza con il nostro team per assistenza personalizzata su:

• preparazione alla revisione per App Store e Play Store
• revisione di privacy policy e documentazione legale
• implementazione di Sign in with Apple
• strategia di testing e reclutamento tester
• preparazione delle note di revisione
• risposta ai rifiuti e ricorsi
• Processo completo di invio dell'app

Il nostro team ha aiutato centinaia di sviluppatori a superare con successo la revisione delle app, facendoti risparmiare settimane di tentativi ed errori.

Conclusione

Inviare la prima app può spaventare, ma con la giusta preparazione puoi superare la revisione al primo colpo. Ricorda questi punti chiave:

1. Inizia presto: Soprattutto per Android - recluta quei 12 tester almeno 3 settimane prima del lancio previsto
2. La privacy prima di tutto: Prepara la privacy policy e assicurati che rifletta accuratamente il modo in cui tratti i dati
3. Accedi con Apple: Se utilizzi qualsiasi social login, devi includere Sign in with Apple su iOS
4. Testa accuratamente: Testa su dispositivi reali, con connessioni instabili e con i permessi negati
5. Sii onesto: Metadati accurati e informative sulla privacy evitano rifiuti e problemi legali
6. Note di revisione dettagliate: Aiuta i revisori a capire subito la tua app

I requisiti attuali per i test su Android allungano i tempi, ma alla fine portano ad app migliori e meno problemi dopo il lancio. Prevedi 3-4 settimane in più per gli invii su Android e sarai nelle condizioni migliori per riuscire.

In bocca al lupo per il lancio! Ricorda che un eventuale rifiuto è solo un'opportunità di apprendimento. Le app di successo spesso affrontano diversi round di revisione prima dell'approvazione.

Non vuoi fare tutto da solo? Prenota una consulenza e lascia che i nostri esperti ti guidino nel processo.

Ti serve aiuto per implementare i live updates dopo l'approvazione? Scopri la soluzione live update di Capgo per aggiornamenti fluidi senza passare dalla revisione degli store.

Continua con le App Review Guidelines 2026

Se stai usando questa checklist per la revisione dell'app per pianificare sicurezza e compliance, collegala a Crittografia per i dettagli di implementazione della crittografia, Conformità per i dettagli di implementazione in Compliance, Security Scanner di Capgo per il workflow del prodotto in Capgo Security Scanner, Sicurezza Capgo per il workflow del prodotto in Capgo Security, e Trust Center di Capgo per il workflow del prodotto in Capgo Trust Center.