Silent Push — essenza, attività in background e configurazione della consegna

Cos’è Silent Push — essenza e scopo

Silent Push è un meccanismo iOS che consegna dati al dispositivo senza alcuna notifica visiva all’utente. A differenza di un push standard che mostra un banner, riproduce un suono e appare nel Centro Notifiche, un silent push “risveglia” l’app in background e le passa i dati da elaborare. L’utente non viene mai a conoscenza della consegna di tale notifica — il risultato è un contenuto aggiornato la prossima volta che apre l’app.

Differenza dalle notifiche push regolari

La differenza chiave risiede nel payload JSON: un silent push contiene il flag content-available: 1 e NON contiene alert, sound o badge. Una notifica standard con alert viene sempre mostrata all’utente, indipendentemente da content-available. Silent push funziona solo con content-available: 1 e senza alert — se si aggiunge alert, il sistema mostrerà la notifica anche con il flag di consegna in background.

Quando utilizzare Silent Push

Le notifiche silenziose sono indispensabili per scenari in cui i dati devono essere freschi quando l’utente apre l’app, ma l’utente non deve essere disturbato. Esempi: aggiornare il feed delle notizie in background, sincronizzare abbonamenti, scaricare nuovi contenuti per l’accesso offline, aggiornare widget, invalidare la cache. Silent Push viene utilizzato anche per “riscaldare” l’app prima di un’azione prevista dell’utente.

Come funziona la consegna delle notifiche silenziose

La consegna di Silent Push differisce significativamente dalle notifiche regolari e segue le regole di ottimizzazione energetica. Il sistema iOS riceve la richiesta push da APNS, determina che si tratta di un silent push (content-available: 1) e decide se consegnarlo in base a molteplici fattori: livello della batteria, modalità di risparmio energetico, frequenza dei silent push precedenti, attività dell’app e carico attuale della CPU.

Il ruolo di Power Nap e delle modalità background

Sui dispositivi con chip Apple M e iOS 15+, il silent push si integra con il meccanismo Power Nap, che risveglia periodicamente il dispositivo per attività in background. Power Nap consolida più silent push in un unico periodo di attività, riducendo il consumo energetico complessivo. Lo sviluppatore non può controllare Power Nap direttamente — il sistema prende decisioni automaticamente in base al comportamento dell’utente e alla cronologia di utilizzo dell’app.

La finestra di elaborazione di 30 secondi

Quando il sistema consegna un silent push, l’app riceve una chiamata a application(_:didReceiveRemoteNotification:fetchCompletionHandler:) in AppDelegate. Lo sviluppatore deve chiamare il completion handler entro 30 secondi, passando il risultato corretto (UIBackgroundFetchResult). Se l’elaborazione non viene completata in tempo, il sistema può limitare la frequenza dei silent push per questa app o smettere del tutto di consegnarli.

// Elaborazione di Silent Push in AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

Intervalli tra le consegne

Apple non pubblica intervalli esatti tra i silent push, ma sulla base di test e documentazione, si consiglia di inviare non più di 2–3 notifiche silenziose all’ora per dispositivo. Se inviate più frequentemente, il sistema inizia a ignorare i silent push e i dati smettono di essere consegnati. Se è necessaria una sincronizzazione più frequente, prendere in considerazione l’uso di URLSession con configurazione in background o VoIP push.

Casi d’uso di Silent Push

Silent Push viene utilizzato in un’ampia gamma di attività in cui i dati devono essere aggiornati senza la partecipazione attiva dell’utente. Esaminiamo i casi d’uso più efficaci di questo meccanismo nelle applicazioni iOS reali.

Aggiornamento dei contenuti per l’accesso offline

Le app di notizie, i lettori e le applicazioni di viaggio utilizzano Silent Push per scaricare nuovi contenuti in background. Quando l’utente apre l’app, i dati sono già caricati e disponibili anche senza connessione Internet. Questo approccio migliora drasticamente l’esperienza utente — gli schermi di caricamento vuoti scompaiono e il contenuto viene visualizzato immediatamente. Il server invia un silent push quando compaiono nuovi articoli e l’app li scarica in background per la lettura offline.

Sincronizzazione dello stato dei widget

iOS WidgetKit aggiorna i widget secondo una pianificazione, ma per aggiornamenti istantanei dopo modifiche ai dati sul server, viene utilizzato Silent Push. L’app in background elabora il silent push, aggiorna l’archivio dati locale per i widget e forza l’aggiornamento della timeline tramite WidgetCenter. L’utente vede informazioni aggiornate sul widget senza aprire l’app — tassi di cambio, previsioni meteo, stato della consegna.

Invalidazione della cache e pulizia dei dati obsoleti

Quando il server aggiorna dati critici (ad esempio, regole di prezzo, funzionalità disponibili per utenti premium), Silent Push consente di invalidare istantaneamente la cache locale. Alla prossima apertura, l’app caricherà dati freschi dal server invece di utilizzare la cache obsoleta. Ciò è particolarmente rilevante per le app con contenuti a pagamento o abbonamenti.

Aggiornamento del badge senza notifica visibile

In alcuni scenari, il badge sull’icona dell’app deve essere aggiornato senza mostrare una notifica. Un Silent Push con il campo badge nel payload consente di impostare il valore del contatore desiderato senza disturbare l’utente con un banner. Ad esempio, un’app di chat può aggiornare il badge con il numero di messaggi non letti senza mostrare ogni nuovo messaggio come notifica se l’utente è già nell’app.

Configurazione di Silent Push: payload e capacità

Per il corretto funzionamento di Silent Push è necessaria una configurazione su tre livelli: il progetto Xcode, il payload JSON sul server e il codice di elaborazione nell’app. Ogni livello è critico: saltare qualsiasi passaggio comporterà la consegna della notifica come normale o la mancata consegna.

Configurazione delle capacità in Xcode

In Xcode, è necessario attivare la capacità Push Notifications e Background Modes con la casella Remote notifications selezionata. Push Notifications genera un certificato per APNS, mentre Remote notifications in Background Modes consente al sistema di risvegliare l’app alla ricezione di un silent push. Senza Remote notifications, il silent push verrà consegnato, ma l’app non verrà attivata in background e i dati non verranno elaborati.

Struttura del payload JSON

Un payload Silent Push deve contenere la chiave aps con content-available: 1 e NON deve contenere alert, sound o badge. I campi personalizzati vengono passati allo stesso livello di aps e contengono dati per l’elaborazione: tipo di operazione, identificatori di oggetti, metadati. Un payload senza content-available verrà trattato come notifica normale; con alert, sarà normale anche con content-available.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

Elaborazione lato client

Alla ricezione di un silent push, iOS chiama application(_:didReceiveRemoteNotification:fetchCompletionHandler:) prima che l’app diventi visibile. In questo metodo, è necessario analizzare userInfo, eseguire il lavoro necessario (richieste di rete, scritture Core Data, aggiornamenti della cache) e chiamare sempre il completionHandler con il risultato corretto entro 30 secondi. Non chiamare il completionHandler viene considerato un errore dal sistema e influisce sulla frequenza dei futuri silent push.

Limitazioni e migliori pratiche

Silent Push non è un canale affidabile di consegna dati per operazioni critiche — è un meccanismo di ottimizzazione, non una sincronizzazione garantita. Lo sviluppatore deve comprendere le limitazioni e progettare il sistema in modo che l’app funzioni correttamente sia con che senza silent push.

Limitazioni di consegna

iOS non garantisce la consegna di ogni silent push. Il sistema può ritardare o annullare la consegna quando la batteria è scarica (sotto il 20%), in modalità di risparmio energetico, dopo silent push frequenti o se l’app non viene utilizzata per molto tempo. Statistiche medie di consegna secondo Apple: circa il 70–80% dei silent push viene consegnato entro 5 minuti, il resto può essere ritardato o perso.

Raccomandazioni Apple per Silent Push

Apple raccomanda di seguire diverse regole per un uso efficace del silent push. Non inviare più di 2–3 silent push all’ora per dispositivo — il superamento del limite comporta il blocco. Utilizzare un payload compatto: la dimensione minima del payload accelera l’elaborazione e riduce il carico di rete. Chiamare sempre il completionHandler il più rapidamente possibile: più tempo richiede l’elaborazione, maggiore è la probabilità che il sistema limiti i silent push in futuro.

Alternative a Silent Push

Per scenari che richiedono consegna garantita o più tempo di elaborazione, considerare le alternative. VoIP push (PushKit) garantisce la consegna e dà più tempo, ma è destinato solo ad applicazioni VoIP. Background fetch (UIApplication background fetch) viene avviato dal sistema secondo una pianificazione, ma non può essere avviato dal server. WebSocket mantiene una connessione persistente ma consuma più batteria e non è adatto a tutti i tipi di app.

Monitoraggio e debug

Per eseguire il debug di Silent Push, utilizzare Console.app su Mac e filtrare per nome dell’app. Il sistema registra ogni silent push con l’etichetta “background task” e indica se l’elaborazione ha avuto successo. Su un dispositivo, verificare tramite Impostazioni → Sviluppatore → Background Modes Logging. Il monitoraggio lato server viene effettuato tramite APNS Feedback Service per identificare le notifiche non consegnate.