iOS ti offre esattamente una possibilità di richiedere il permesso push con la richiesta nativa. Se l'utente tocca "Non consentire", quella decisione viene nascosta nell'app Impostazioni, dove quasi nessuno va per annullarla. Questo singolo fatto dovrebbe plasmare la tua intera strategia di permesso per le notifiche push su iOS — ed è il motivo per cui le app con i migliori tassi di opt-in quasi mai mostrano la richiesta di Apple a freddo.
Questa guida spiega come funziona effettivamente il permesso iOS, il modello di preparazione che protegge il tuo unico tentativo e come implementare l'intero flusso con poche righe di codice SDK.
Come funziona effettivamente il permesso push iOS
Ogni app si trova in uno dei tre stati di permesso: all'utente non è stato ancora chiesto, l'utente ha concesso il permesso o l'utente lo ha negato. La richiesta di sistema nativa — quella visualizzata da Apple, con un testo che non puoi modificare — sposta l'utente dallo stato iniziale in modo permanente. Non esiste una seconda richiesta nativa. Una volta negato, l'unica strada per tornare indietro passa attraverso l'app Impostazioni, e i tassi di recupero da Impostazioni sono così bassi che dovresti considerare un rifiuto come quasi definitivo.
Confrontalo con Android, dove il permesso di notifica storicamente era attivo per impostazione predefinita. È il motivo principale per cui i tassi di opt-in iOS si aggirano intorno al 51% mentre Android si aggira intorno all'81%, come abbiamo trattato nella guida al marketing push delle app. Su iOS, l'opt-in va guadagnato. Il vantaggio: un abbonato che ha deliberatamente detto sì vale di più, interagisce di più e abbandona meno di un abbonato con impostazione predefinita. Il tuo compito è preparare il terreno prima che venga posta la domanda.
Perché il timing batte il testo
L'errore più comune nel permesso iOS è strutturale, non verbale: attivare la richiesta nativa al primo avvio, prima che l'utente abbia idea di cosa faccia l'app o perché le notifiche potrebbero essergli utili. In quel momento, la risposta onesta a "dovrei permettere a questa app di interrompermi?" è no — l'utente non ha alcuna prova in un senso o nell'altro, e il no è l'impostazione predefinita sicura.
La soluzione è chiedere in un momento di valore — un punto della sessione in cui il beneficio di una notifica è concreto ed evidente:
- Un acquirente di e-commerce salva un articolo in una wishlist → "vuoi sapere quando scende il prezzo?"
- Un acquirente completa un acquisto → "vuoi aggiornamenti sulla spedizione per questo ordine?"
- Un lettore finisce un secondo articolo → "vuoi essere avvisato quando pubblichiamo su questo argomento?"
- Un utente completa l'onboarding e raggiunge il suo primo successo → "vuoi che ti diciamo quando succede X?"
Stessa richiesta, stesso testo di Apple — risposta drasticamente diversa, perché la domanda ha finalmente un contesto.
Il modello di preparazione: richiesta soft prima della richiesta reale
La preparazione significa mostrare una schermata personalizzata all'interno dell'app — una finestra di dialogo pre-permesso che controlli completamente — prima di attivare la richiesta di Apple. Il modello ha una regola che lo fa funzionare: attiva la richiesta nativa solo dopo che l'utente dice sì alla tua.
Se l'utente accetta la tua richiesta soft, ha già deciso; il prompt nativo è una formalità e converte con tassi molto elevati. Se rifiuta la tua richiesta soft, non hai perso nulla: il prompt nativo non è mai stato mostrato, il one shot è ancora attivo e puoi rieseguire la richiesta soft in un momento migliore settimane dopo. La richiesta soft è ripetibile all'infinito; il prompt di Apple no.
Una buona richiesta soft indica il valore specifico ("allarmi di calo prezzo sui tuoi articoli salvati"), mostra come apparirà la notifica e offre un'opzione di rifiuto genuina che non fa sentire in colpa. Gli stessi principi dietro i prompt di opt-in push web ad alta conversione si applicano: la specificità converte, la vaghezza no.
Implementazione del flusso con l'SDK PushEngage
L'SDK iOS 1.0 ti fornisce le due chiamate necessarie per questo flusso: una per controllare lo stato corrente, una per attivare il prompt nativo nel momento che scegli.
// 1. Check state before deciding what UI to show
let status = PushEngage.getNotificationPermissionStatus()
switch status {
case "notYetRequested":
showSoftAskScreen() // your own UI — the native prompt is untouched
case "denied":
showSettingsNudgeIfEarned() // deep link to Settings, only at a high-value moment
case "granted":
break // already subscribed — get out of the way
default:
break
}
// 2. Only after the user accepts YOUR screen:
PushEngage.requestNotificationPermission { granted, error in
if granted {
// subscribed — thank them with value, not a welcome blast
}
}Nota cosa impone il codice: il prompt nativo viene attivato dall'interno dell'handler di accettazione della tua richiesta soft e da nessun altro luogo. Nessuna sorpresa al momento del lancio, nessun colpo sprecato.
Recuperare gli utenti che hanno detto di no
Per gli utenti nello stato negato, il prompt nativo è scomparso, ma il gioco non è finito. La mossa di recupero è un deep link alle Impostazioni: UIApplication.openNotificationSettingsURLString porta l'utente direttamente all'interruttore delle notifiche della tua app. Riservalo per i momenti in cui l'utente sta attivamente chiedendo qualcosa che le notifiche fornirebbero ("ricevi una notifica quando torna disponibile" → "le notifiche sono disattivate per questa app - attivale nelle Impostazioni?"). Un suggerimento nelle Impostazioni in un momento casuale viene letto come fastidio; lo stesso suggerimento in un momento di "lo voglio ora" viene letto come aiuto.
Misuralo come la metrica di crescita che è
Il tasso di opt-in è il moltiplicatore di ogni campagna push che eseguirai mai, il che lo rende degno di essere strumentato correttamente: traccia separatamente l'accettazione della richiesta soft e la conversione del prompt nativo, segmenta per il momento del trigger che ha attivato la richiesta e verifica lo stato di iscrizione con getSubscriptionNotificationStatus - che verifica sia l'iscrizione che il permesso - prima di contare chiunque come raggiungibile. Dieci punti di miglioramento dell'opt-in si compongono su ogni campagna, ogni settimana, per tutta la vita dell'app.
Il permesso è il cancello. Una volta che un utente lo ha superato, tutto il resto - campagne attivate, segmentazione, drip journey - viene eseguito dalla dashboard di PushEngage senza un'altra riga di codice dell'app. La guida all'installazione per iOS ti porta dall'installazione dell'SDK alla tua prima campagna in un pomeriggio.
