Quando Chiedere il Permesso per le Notifiche Push (e Quando Non Farlo)

La maggior parte delle app chiede il permesso per le notifiche push nella prima schermata che l'utente vede, prima ancora che abbia fatto qualcosa per cui valga la pena essere notificato. Su iOS, quel singolo dialogo è una risorsa da usare una volta sola: se l'utente lo rifiuta, l'unica strada è andare nelle Impostazioni, un percorso che quasi nessuno fa. Abbiamo visto i tassi di opt-in su app clienti passare da meno del 30% a oltre il 70% cambiando unicamente quando viene mostrato il prompt di sistema. Il testo, l'icona, l'app stessa: tutto invariato.

Se state costruendo o riprogettando il flusso di onboarding di un'app mobile, la tempistica dei permessi merita la stessa attenzione progettuale del modulo di registrazione.

Perché il prompt nativo è una risorsa da usare una volta sola

iOS mostra il dialogo di sistema per i permessi esattamente una volta per ogni installazione dell'app. Non esiste un "chiedi di nuovo più tardi": se l'utente tocca Non consentire, l'unica strada è Linking.openSettings() e un utente disposto a navigare tra Impostazioni iOS > Notifiche > La Tua App. Android è storicamente più permissivo (prima della versione 13, il permesso era implicito; dalla 13 in poi è richiesta una richiesta runtime esplicita, ma richiedere nuovamente è ancora possibile in alcune condizioni), il che significa che i team che costruiscono i flussi di permesso basandosi sul comportamento Android si trovano spesso in difficoltà quando rilasciano su iOS.

Trattate il prompt nativo come una risorsa che si spende una volta sola. Tutto ciò che lo precede deve esistere per far sì che quel singolo tentativo vada a buon fine.

Il pattern del soft-ask

La soluzione è una schermata di pre-permesso che controllate interamente — un normale elemento dell'interfaccia in-app, non un dialogo di sistema — che spiega il valore delle notifiche prima che compaia il prompt del sistema operativo:

• "Ricevi una notifica quando il tuo ordine viene spedito", con un'icona a forma di campanella e due pulsanti: Abilita Notifiche e Non ora
• Solo toccando Abilita Notifiche si attiva la vera richiesta di permesso del sistema operativo
• Toccare Non ora chiude la schermata senza toccare lo stato a livello di sistema, quindi il prompt reale è ancora disponibile in seguito

Questo è importante perché rifiutare un soft-ask non costa nulla: potete mostrarlo di nuovo nella sessione successiva, dopo un'azione diversa, con un testo diverso. Un rifiuto della richiesta hard (quella del sistema operativo) su iOS è quasi permanente.

```tsx import * as Notifications from 'expo-notifications';

async function requestPushPermission() { const { status: existing } = await Notifications.getPermissionsAsync(); if (existing === 'granted') return true;

const { status } = await Notifications.requestPermissionsAsync(); return status === 'granted'; }

// Only call requestPushPermission() after the user taps // "Enable Notifications" on your own in-app screen. ```

Tempistica: il contestuale batte il cronologico

"Giorno 3" o "dopo l'onboarding" è una tempistica cronologica — facile da implementare, ed è per questo che la maggior parte delle app chiede ancora al lancio, in un passaggio fisso. La tempistica contestuale lega la richiesta a un momento in cui il valore è evidente:

• E-commerce: dopo che è stato effettuato il primo ordine, non prima ("tieni traccia della tua consegna")
• App SaaS/dashboard: dopo che l'utente ha creato la prima cosa che vale la pena monitorare (un progetto, un alert, un report)
• Social/messaggistica: dopo che è stato inviato o ricevuto il primo messaggio, non alla creazione dell'account
• Prenotazioni/scheduling: subito dopo la conferma di una prenotazione ("ti ricorderemo prima dell'inizio")

Se la vostra app non ha un "momento" ovvio, non inventatene uno: una richiesta generica alla seconda o terza sessione supera comunque quella alla prima sessione, perché l'utente ha almeno avuto modo di farsi una prima impressione del prodotto.

Differenze tra piattaforme che fanno saltare le implementazioni superficiali

• iOS: un solo tentativo per installazione (finché l'utente non disinstalla e reinstalla manualmente l'app, operazione che azzera lo stato del permesso). L'autorizzazione provvisoria (provisional: true nelle opzioni della richiesta) recapita le notifiche in modo silenzioso nel Centro Notifiche senza alcun prompt — utile per tipologie di notifiche a basso impatto e alto volume, dove è preferibile guadagnarsi la fiducia prima di chiedere.
• Android 13+: POST_NOTIFICATIONS è un permesso runtime come la fotocamera o la posizione, richiesto nello stesso modo. Prima di Android 13, le notifiche vengono concesse per impostazione predefinita all'installazione, quindi testare solo su dispositivi Android più recenti può nascondere bug che emergono per una fetta reale della vostra base di installazioni Android.
• Stato background/foreground: alcune API per i permessi si comportano diversamente a seconda che la richiesta avvenga immediatamente al mount o dopo un ritardo con useEffect — testate la tempistica effettiva che andrete a rilasciare, non solo la chiamata API in isolamento.

Questa è una delle aree in cui la scelta tra React Native e Flutter conta meno di quanto si pensi: entrambi incapsulano lo stesso modello di permessi del sistema operativo sottostante, ed entrambi vi daranno gli stessi problemi se chiedete troppo presto.

Misurate prima di ottimizzare

Non è possibile ottimizzare la tempistica dei permessi senza dati. Tracciate, come minimo:

• Soft-ask mostrato → Soft-ask accettato (il vostro funnel in-app)
• Soft-ask accettato → Permesso del sistema operativo concesso (quanto vi costa il prompt del sistema)
• Tempo alla prima notifica ricevuta (un indicatore proxy dell'effettiva utilità della notifica una volta concesso il permesso)

Senza questi eventi separati, il "tasso di opt-in" come numero unico nasconde se il calo è dovuto al vostro testo, alla tempistica o al prompt del sistema operativo — tre problemi con soluzioni molto diverse.

Una checklist essenziale

• Non attivate mai il dialogo di permesso del sistema operativo al primo avvio o da un passaggio generico dell'onboarding
• Costruite una schermata di soft-ask che controllate interamente, con un testo legato a un beneficio concreto
• Attivate il soft-ask dopo un'azione contestuale, non in base a un giorno o a un numero fisso di passaggi
• Gestite esplicitamente il comportamento one-shot di iOS: trattate il rifiuto come (quasi) definitivo e offrite un deep link alle Impostazioni dopo il rifiuto, invece di riproporre la richiesta
• Testate specificamente su dispositivi Android 13+; non assumete che il comportamento pre-13 si generalizzi
• Misurate ogni passaggio del funnel separatamente prima di modificare qualsiasi cosa

Questo tipo di dettaglio è facile da trascurare quando si corre verso una data di lancio, ma è economico costruirlo correttamente la prima volta ed è costoso da rimediare a posteriori, una volta che la vostra base di installazioni ha già visto — e rifiutato — il prompt sbagliato. Se state pianificando un nuovo sviluppo mobile o state verificando le performance e l'onboarding di un'app esistente, parliamone.