---
term: 'Notifiche push (APNs e FCM)'
seoTitle: 'Notifiche push: APNs, FCM, token del dispositivo, Web Push'
headline: 'Che cosa sono le notifiche push (APNs e FCM)?'
slug: notifiche-push
category: backend-compute
shortDefinition: 'Una notifica push è un messaggio avviato dal server che i servizi push della piattaforma consegnano a un dispositivo, anche con l''app chiusa.'
relatedTerms:
  - websockets-real-time-sync
  - real-time-live-queries
  - background-jobs-task-schedulers
  - presence-online-status
contrastsWith:
  - websockets-real-time-sync
aboutTerms:
  - 'Device Token'
  - 'APNs'
  - 'FCM'
  - 'Web Push (VAPID)'
faq:
  - question: 'Che cos''è una notifica push?'
    answer: 'Un messaggio avviato dal server, consegnato a un dispositivo dal servizio push del sistema operativo e mostrato anche quando l''app non è in esecuzione. Quest''ultima proprietà è quella che definisce tutto: separa il push dai messaggi in-app, che richiedono l''app aperta, e dai socket, che richiedono una connessione viva.'
  - question: 'Come funzionano le notifiche push da un capo all''altro?'
    answer: 'L''app si registra presso il servizio push della propria piattaforma e riceve un token del dispositivo; l''app consegna quel token al backend; il backend invia un payload insieme al token ad APNs o FCM; il servizio push lo consegna sulla connessione persistente che il sistema operativo mantiene; il sistema lo mostra oppure risveglia l''app.'
  - question: 'Che cos''è un token del dispositivo?'
    answer: 'Un identificatore opaco per una singola installazione dell''app su un singolo dispositivo, emesso dal servizio push della piattaforma – un indirizzo, non un segreto. Cambia alla reinstallazione, al ripristino o alla cancellazione dei dati, ed è per questo che le app lo risincronizzano con il backend a ogni avvio e i backend lo eliminano appena un invio lo segnala scomparso.'
  - question: 'Qual è la differenza tra APNs e FCM?'
    answer: 'APNs (Apple Push Notification service) è l''unica strada verso i dispositivi Apple. FCM è il servizio push della piattaforma Android – e fa anche da livello multipiattaforma: con le credenziali APNs caricate al suo interno, accetta una sola richiesta e ne riemette una conforme ad APNs per i dispositivi Apple. Una API, due piattaforme.'
  - question: 'Perché un server non può spingere direttamente su un dispositivo?'
    answer: 'Perché solo il sistema operativo detiene l''unica connessione persistente e ottimizzata per la batteria verso il proprio servizio push – un socket condiviso da ogni app del telefono. Server qualsiasi non riescono a tenere connessioni aperte attraverso radio, NAT e stati di sospensione, quindi tutti i push passano dai gateway delle piattaforme.'
  - question: 'Come funziona il web push?'
    answer: 'Attraverso i service worker: la pagina si sottoscrive con la chiave pubblica VAPID, il servizio push del browser restituisce una sottoscrizione – un URL di endpoint più le chiavi di cifratura – e il server invia in POST payload cifrati a quell''endpoint secondo il Web Push Protocol. L''evento push del service worker mostra la notifica, anche con il sito chiuso.'
  - question: 'La consegna del push è garantita?'
    answer: 'No – una risposta di successo da APNs o FCM significa accettato, non consegnato. I dispositivi offline ricevono code accorpate o limitate nel tempo, gli ottimizzatori della batteria ritardano la consegna e gli utenti possono disattivare del tutto le notifiche. Il push è best-effort per progetto; tutto ciò che è critico ha bisogno anche di un secondo canale.'
  - question: 'Che cosa sono le notifiche push silenziose?'
    answer: 'Push in background che risvegliano l''app perché recuperi dei dati senza mostrare un avviso. Sono fortemente limitate – un piccolo budget orario, con gli invii fuori budget scartati senza errore – quindi funzionano come suggerimenti di aggiornamento, mai come trasporto di sincronizzazione affidabile.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Apple — Sending notification requests to APNs'
    url: 'https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns'
  - name: 'RFC 8030 — Generic Event Delivery Using HTTP Push'
    url: 'https://datatracker.ietf.org/doc/html/rfc8030'
  - name: 'RFC 8292 — VAPID for Web Push'
    url: 'https://datatracker.ietf.org/doc/html/rfc8292'
  - name: 'W3C Push API'
    url: 'https://www.w3.org/TR/push-api/'
cta:
  title: 'Una sola API push per ogni dispositivo'
  text: 'Il servizio push di Back4app conserva le tue credenziali APNs e FCM una volta per tutte, tiene traccia di ogni installazione come oggetto Installation e invia per canale o per query – da Cloud Code, dall''SDK o dalla dashboard.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-06'
translationKey: push-notifications-apns-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

| Domanda | Risposta |
| --- | --- |
| La catena | Il backend → APNs/FCM → l'unico socket persistente del sistema operativo → l'app |
| L'indirizzo | Il token del dispositivo – per installazione, in continuo cambiamento, da sincronizzare e potare |
| Il contratto | Best-effort: accettato ≠ consegnato, limitato, disattivabile dall'utente |
| I limiti | Payload di circa 4 KB · flag di priorità · push silenziosi su un budget orario minuscolo |
| vs. i socket | Il push raggiunge le app *chiuse*; i [WebSocket](/glossary/it/websockets/) servono quelle *aperte* |

## La catena di consegna, da un capo all'altro

```text
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:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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.
```

```mermaid
flowchart LR
  accTitle: La consegna delle notifiche push attraverso i servizi push delle piattaforme
  accDescr: L'app si registra presso il servizio push della propria piattaforma e riceve un token del dispositivo, che sincronizza con il backend applicativo. Il backend invia i payload insieme ai token ad APNs o FCM, che consegnano sull'unica connessione persistente mantenuta dal sistema operativo di ogni dispositivo, e il sistema mostra la notifica anche quando l'app è chiusa.
  A["App sul dispositivo"] -->|"1 · registrazione"| PS["Servizio push della piattaforma<br/>APNs / FCM"]
  PS -->|"2 · token del dispositivo"| A
  A -->|"3 · sincronia del token"| B["Il backend<br/>registro dei token"]
  B -->|"4 · payload + token"| PS
  PS -->|"5 · una connessione<br/>persistente del sistema"| OS["Sistema del dispositivo"]
  OS -->|"6 · mostra / risveglia"| N["Notifica<br/>(l'app può essere chiusa)"]
```

## 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

| | APNs | FCM |
| --- | --- | --- |
| Raggiunge | I dispositivi Apple – l'unica strada | Android nativamente; i dispositivi Apple inoltrando ad APNs |
| Autenticazione | Chiave di firma `.p8` (key ID + team ID) | Credenziali server dalla console della piattaforma |
| Payload | ~4 KB · dizionario `aps` | ~4 KB · messaggi notification + data |
| Gestione offline | Accorpa – conserva il *più recente* per app | Coda con un TTL, fino a circa 4 settimane |
| Priorità | 10 (immediata) vs. 5 (risparmio energetico) | Alta vs. normale |
| Extra | Collapse ID, push in background | Topic, gruppi di dispositivi, collapse key |

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](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns); 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](https://www.w3.org/TR/push-api/) usando la coppia di chiavi **VAPID** ([RFC 8292](https://datatracker.ietf.org/doc/html/rfc8292) – 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](https://datatracker.ietf.org/doc/html/rfc8030). 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

| | Notifiche push | [WebSocket](/glossary/it/websockets/) / [live queries](/glossary/it/live-queries-tempo-reale/) |
| --- | --- | --- |
| Stato dell'app | **Chiusa o in background** | Aperta, connessa |
| Direzione | Senso unico, server → dispositivo | Full duplex / push per sottoscrizione |
| Latenza e affidabilità | Nell'ordine dei secondi, best-effort | Millisecondi, garantiti dalla connessione |
| Payload | Riepilogo di circa 4 KB + link profondo | Quello che trasporta il protocollo scelto |
| L'ibrido | Il pattern di produzione: consegnare sul socket se c'è connessione; passare al push dopo qualche secondo se non c'è | |

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](/glossary/presence-online-status/).
- **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

| Situazione | Scegliere |
| --- | --- |
| L'utente deve sapere benché l'app sia chiusa | Il push – il suo mestiere per definizione |
| L'app è aperta sullo schermo | [Live queries / socket](/glossary/it/live-queries-tempo-reale/) – più rapidi e affidabili |
| I dati devono arrivare, garantiti | L'API più una [sincronizzazione in background](/glossary/it/job-in-background/); il push come colpetto |
| Pubblico web | Il web push via VAPID + service worker |
| Sincronizzazioni silenziose frequenti | Meglio no – il budget le scarterà; sincronizzare all'apertura |
| Due piattaforme, una sola squadra | Una API sopra entrambi i servizi – la modalità di inoltro di FCM o un BaaS |

## 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](/glossary/it/cloud-code-funzioni-serverless/) – un `afterSave` su `Message` che spinge verso il destinatario è la metà di ripiego del pattern ibrido –, da [job](/glossary/it/job-in-background/) 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.