Che cosa sono le notifiche push (APNs e FCM)?

Una notifica push è un messaggio avviato dal server che i servizi push della piattaforma consegnano a un dispositivo, anche con l’app chiusa. I team di prodotto conoscono il push come canale di coinvolgimento; questa voce copre il macchinario della consegna – perché è il macchinario a spiegare ognuna delle stranezze di cui i team di prodotto si lamentano. Il fatto centrale: il server non parla mai al telefono. Ogni sistema operativo mobile mantiene esattamente una connessione persistente e ottimizzata per la batteria verso il gateway push del proprio fornitore – APNs (Apple Push Notification service) per i dispositivi Apple, FCM per Android – e ogni notifica di ogni app viaggia su quel tubo condiviso.

Punti chiave

La catena di consegna, da un capo all’altro

1  L'app chiede al sistema operativo di registrarsi per il push
2  Il servizio push della piattaforma emette un DEVICE TOKEN (l'indirizzo)
3  L'app invia il token AL PROPRIO backend, che lo memorizza
4  Qualcosa accade → il backend fa POST di { token, payload ≤4 KB } ad APNs / FCM
5  Il servizio push trova la connessione persistente del dispositivo → consegna
6  Il sistema mostra la notifica – o risveglia l'app un istante per un push silenzioso

Il secondo mestiere di FCM: con le credenziali APNs caricate, accetta una richiesta
e ne riemette una conforme ad APNs per i dispositivi Apple –
una sola superficie di API per entrambe le piattaforme. Un BaaS astrae perfino questo.

Entrambe le metà in codice – il client che registra il proprio indirizzo, il backend che invia a un canale:

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Token del dispositivo: l’indirizzo che non smette di cambiare

Il ciclo di vita del token è il vero lavoro del backend, e la parte che le pagine divulgative saltano. Registrare: il sistema operativo emette un token per ogni installazione dell’app. Memorizzare: l’app lo sincronizza con il backend a ogni avvio – i token cambiano in silenzio alla reinstallazione, al ripristino e alla cancellazione dei dati. Indirizzare: gli invii puntano a dei token, singolarmente o tramite il registro. Invalidare: gli invii verso token morti tornano con errori precisi – 410 Gone da APNs, errori di token non registrato da FCM – e FCM manda in scadenza i token inutilizzati per circa nove mesi. Potare: cancellare su quegli errori, subito. I backend che saltano l’ultimo passo accumulano tabelle di token in putrefazione che sprecano invii, falsano le metriche di consegna e rallentano le campagne – il problema dei token scaduti è noioso, cumulativo, ed è il bug di push più comune nella vita reale.

APNs vs. FCM

La conseguenza pratica della prima riga: ogni backend multipiattaforma o integra entrambi i servizi, o usa FCM come superficie unica (caricandovi le credenziali APNs), o affida l’intero problema a una piattaforma che detiene entrambi i set di credenziali – che è il punto in cui atterra la sezione sul BaaS.

Che cosa il push non promette

Il contratto onesto, raccolto in un unico posto. Un 200 dal servizio push significa accettato per la consegna, non consegnato. I dispositivi offline non accumulano una coda fedele: APNs conserva solo la notifica più recente per app; la coda di FCM scade secondo un TTL. Gli ottimizzatori della batteria su Android rinviano la consegna in modi che restano fuori controllo; gli utenti possono silenziare un canale o l’app intera a livello di sistema operativo, in modo invisibile al backend. I push silenziosi – risvegli in background senza avviso visibile – girano su un budget orario minuscolo e oltre quello vengono scartati senza errore, secondo le indicazioni di Apple stessa; sono suggerimenti di aggiornamento, non un protocollo di sincronizzazione. La regola di progettazione che ne deriva: il push è il colpetto sulla spalla – i dati veri viaggiano attraverso l’API all’apertura dell’app, e tutto ciò che deve assolutamente arrivare si guadagna un secondo canale.

Il web push, in breve

I browser hanno standardizzato una catena propria: la pagina si sottoscrive tramite la Push API usando la coppia di chiavi VAPID (RFC 8292 – il server si identifica con un token firmato, senza registrazione presso alcun fornitore), il servizio push del browser restituisce una sottoscrizione (URL di endpoint + chiavi di cifratura) e il server invia in POST payload cifrati a quell’endpoint secondo il Web Push Protocol. Un service worker riceve l’evento push e mostra la notifica – sito chiuso, e su desktop magari anche browser chiuso. Ogni produttore di browser fa girare il proprio servizio push; l’URL di endpoint dice al server dove fare il POST. La riserva onesta: su iOS il web push funziona solo per le web app installate nella schermata Home.

Push vs. WebSocket vs. live queries

Sono complementari, con un solo confine: il socket serve l’utente che guarda lo schermo; il push raggiunge quello che ha posato il telefono. Le app di chat dimostrano l’ibrido ogni giorno – i messaggi scorrono sulla connessione mentre l’app è aperta, e lo stesso messaggio diventa un push nell’istante in cui non lo è più.

Casi d’uso tipici

• Messaggi e menzioni – il push canonico: qualcuno ha bisogno di una risposta e l’app è chiusa.
• Avvisi transazionali – ordine spedito, corsa in arrivo, pagamento riuscito: riepiloghi di una riga con link profondo nell’app.
• Trigger sensibili al tempo – cambi di punteggio, avvisi di prezzo, momenti “X è in diretta” vicini alla presenza.
• Riattivazione – da usare con parsimonia, con disiscrizioni per singolo canale, altrimenti gli utenti disattivano tutto.
• Badge e suggerimenti di stato – il budget silenzioso speso per spingere l’app ad aggiornarsi prima che l’utente la apra.

Conviene usare il push? Matrice decisionale

Limiti e trade-off

• La consegna è una probabilità, non una promessa. Conviene progettare flussi che sopravvivono a un push perduto, e riconciliare all’apertura dell’app.
• Il permesso si chiede davvero una volta sola. La richiesta del sistema operativo (esplicita su iOS e sul web, a runtime su Android moderno) converte meglio se posta nel contesto giusto – e un rifiuto è quasi irreversibile.
• Il registro dei token è un insieme di dati vivo. Sincronizzare all’avvio, potare sugli errori, oppure stare a guardare la recapitabilità degradarsi in silenzio.
• I payload sono quasi pubblici. Le notifiche compaiono sulle schermate di blocco e attraversano infrastrutture di terzi – riepiloghi e identificatori, mai segreti.
• Due sistemi di credenziali, una sola funzionalità. Chiavi .p8, credenziali di console, scadenze e rotazione – il dolore della configurazione è reale, una volta per piattaforma, ed è esattamente ciò che i livelli gestiti assorbono.

Il push su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il servizio push di Back4app trasforma l’intera catena in dati: ogni installazione si registra come oggetto Installation – token del dispositivo, piattaforma, canali e un Pointer all’utente catturati automaticamente, come mostrano le schede lato client – e una sola chiamata di invio indirizza dei canali (in stile topic) oppure qualsiasi query sulle Installation (“tutti quelli del canale scores su Android che non hanno aperto l’app questa settimana”), con la piattaforma che detiene le credenziali APNs e FCM e instrada per singolo dispositivo. Gli invii partono da Cloud Code – un afterSave su Message che spinge verso il destinatario è la metà di ripiego del pattern ibrido –, da job pianificati o dalla console della dashboard per le campagne una tantum. Igiene dei token, doppie credenziali e stranezze di payload per piattaforma diventano comportamento della piattaforma; il codice applicativo decide chi e che cosa, non come.