Progressive Web App nel 2026: guida allo sviluppo

Anna Kowalski Senior Mobile Engineer, YuSMP Group · Sviluppa prodotti React Native, Flutter e PWA per clienti US & UE dal 2017

Cosa rende una PWA tale

Il termine Progressive Web App è stato coniato dagli ingegneri Google Alex Russell e Frances Berriman nel 2015. Un decennio dopo, il concetto è passato da un esperimento del browser a una vera strategia di produzione utilizzata da aziende come Twitter (ora X Lite), Pinterest, Starbucks e Uber. La parola "progressiva" si riferisce all'approccio a strati: una PWA è un'applicazione web nel suo nucleo e migliora progressivamente il proprio comportamento man mano che l'ambiente del browser lo supporta.

Tre pilastri tecnici definiscono una PWA:

• Service worker. Un file JavaScript che viene eseguito in un thread separato, funge da proxy di rete tra il browser e internet, e abilita la funzionalità offline, la sincronizzazione in background e le notifiche push.
• Web App Manifest. Un file JSON che indica al browser come presentare l'app quando viene installata — nome, icone, colore del tema, modalità di visualizzazione e URL di avvio.
• HTTPS. I service worker richiedono un contesto sicuro. Ogni PWA di produzione deve essere servita tramite HTTPS (localhost è esente durante lo sviluppo).

Se state ancora decidendo se una PWA è l'architettura giusta per il vostro prodotto, il nostro articolo App web vs nativa vs PWA: come scegliere nel 2026 analizza il compromesso completo tra costi, portata e capacità. Questa guida presuppone che abbiate preso la decisione e vogliate sviluppare.

Service worker: il motore sotto il cofano

Un service worker è l'elemento più importante di una PWA. Comprenderlo a fondo previene gli errori di produzione più comuni — cache obsolete, ritardi di aggiornamento, fallback offline difettosi — che danno una cattiva reputazione alle PWA quando vengono implementate con superficialità.

Ecco come funziona il ciclo di vita:

1. Registrazione. La pagina principale registra lo script del service worker: navigator.serviceWorker.register('/sw.js').
2. Installazione. L'evento install si attiva. Qui si apre una cache e si precache l'app shell.
3. Attivazione. Dopo l'installazione, il nuovo service worker attende che tutti i tab che usano la vecchia versione vengano chiusi prima di attivarsi. Durante l'evento activate si eliminano le vecchie cache.
4. Intercettazione fetch. Una volta attivo, il service worker intercetta ogni richiesta di rete tramite l'evento fetch. Qui vivono le strategie di cache.
5. Inattività e terminazione. Il browser può terminare un service worker inattivo in qualsiasi momento per conservare la memoria. Non memorizzate mai lo stato in variabili globali del service worker — usate invece IndexedDB o l'API Cache.

Strategie di cache in pratica

Il gestore fetch del service worker è il punto in cui si decide come viene servito ogni tipo di risorsa. Non esiste una strategia migliore unica — l'approccio giusto dipende da quanto spesso cambia la risorsa e quanto obsolescenza è accettabile.

Workbox (di Google) è la libreria de facto per implementare questi schemi. Gestisce il precache con hash di integrità, il cache runtime con plugin di scadenza e la gestione dei nomi delle cache. A meno che non abbiate un motivo imperativo per scrivere manualmente la logica di cache, usate Workbox.

I quattro schemi che userete in quasi ogni PWA:

• Cache-First. Controllare prima la cache; accedere alla rete solo se la risorsa non è in cache. Ideale per le risorse statiche che cambiano raramente.
• Network-First. Provare la rete; in caso di errore, usare la cache. Ideale per gli endpoint API dove la freschezza è critica.
• Stale-While-Revalidate. Servire immediatamente dalla cache, poi aggiornare la cache in background dalla rete. Bilancia velocità e freschezza per le risorse che si aggiornano periodicamente.
• Network-Only. Usare sempre la rete; non usare mai la cache. Per analytics, pagamenti, login/logout.

Manifesto dell'app web e installabilità

Il Web App Manifest è un file JSON che definisce l'aspetto e il comportamento della vostra PWA quando viene installata. Campi chiave del manifesto per il 2026:

• id (nuovo nel 2023). Un identificatore stabile per l'app. Se cambiate start_url, specificare id garantisce che il browser tratti la nuova versione come un aggiornamento dell'app installata esistente.
• screenshots. Richiesto per l'interfaccia di installazione più ricca che Android 14 + Chrome 119+ mostra prima del prompt di installazione.
• Icone mascherabili. Le icone adattive Android vengono ritagliate in cerchio, squircle o altra forma. Senza un'icona mascherabile, il vostro logo apparirà con riempimento bianco all'interno della forma.
• display: "standalone". L'app installata nasconde il chrome del browser (barra degli indirizzi) e sembra un'app nativa.

Prompt di installazione e aggiunta alla schermata Home

Convincere gli utenti a installare la vostra PWA è un evento di conversione come qualsiasi altro. L'interfaccia di installazione predefinita del browser è facile da perdere. La creazione di un prompt di installazione personalizzato migliora notevolmente i tassi di installazione.

Su Android (Chrome): il browser attiva l'evento beforeinstallprompt quando tutti i criteri di installabilità sono soddisfatti. Catturatelo e attivatelo su un gesto dell'utente. Monitorate il tasso di installazione come metrica di prodotto e fate A/B test sul momento del prompt — mostrarlo dopo un'azione significativa dell'utente converte molto meglio che al primo caricamento.

Su iOS (Safari): non esiste un evento beforeinstallprompt. L'utente deve toccare manualmente il pulsante Condividi e poi "Aggiungi alla schermata Home". La vostra migliore opzione è un modal che spiega il gesto con una breve animazione.

Sviluppo per la modalità offline

Il supporto offline è la funzionalità che distingue più radicalmente una PWA da un'app web standard. Ben implementato, offre un'esperienza completa o degradata ma utile quando l'utente non ha rete.

Lo schema fondamentale è l'app shell: precache il set minimale di risorse necessarie per renderizzare lo scheletro dell'interfaccia e servirle dalla cache ad ogni caricamento. Oltre all'app shell, tre API alimentano la funzionalità offline:

• API Cache. Archiviazione chiave-valore per coppie Request/Response. Workbox la avvolge con scadenza, pulizia e versioning.
• IndexedDB. Un database completo lato client con transazioni, indici e cursori. Librerie come Dexie.js rendono l'API ergonomica.
• API Background Sync. Mette in coda le richieste di rete effettuate offline e le riproduce quando la connettività viene ripristinata.

Notifiche push dall'inizio alla fine

Le notifiche push sono uno degli strumenti di re-engagement più potenti disponibili per una PWA. Il flusso tecnico ha cinque passaggi: (1) richiedere l'autorizzazione per le notifiche su un gesto dell'utente, (2) iscriversi al servizio push per ottenere un oggetto PushSubscription, (3) inviare tale abbonamento al vostro server, (4) dal vostro server, inviare un messaggio push all'endpoint push tramite il protocollo Web Push, (5) il service worker riceve un evento push e mostra la notifica.

Nota iOS: le notifiche push per le PWA sulla schermata Home sono supportate da iOS 16.4. La PWA deve essere installata sulla schermata Home — il push non funziona per le PWA in esecuzione nel tab del browser su iOS. Invitate prima gli utenti a installare, poi richiedete l'autorizzazione per le notifiche.

Capacità PWA: iOS vs Android nel 2026

La parità di piattaforma tra iOS e Android è migliorata sostanzialmente negli ultimi tre anni, ma rimangono lacune significative. Questa tabella è aggiornata a metà 2026 basata su WebKit 17.x e Chrome 125:

Quando una PWA è la scelta giusta

Sviluppate una PWA quando:

• Il vostro principale canale di distribuzione è la ricerca web (SEO) e non volete frammentare la scopribilità tra uno store di app e una pagina web.
• I vostri utenti sono su un insieme diversificato di dispositivi e sistemi operativi.
• I vostri requisiti offline sono moderati — contenuto in cache, invii di moduli in coda, CRUD di base da un IndexedDB locale.
• I vincoli di budget rendono impraticabile mantenere codebase iOS e Android native separate.
• State sviluppando un prodotto ricco di contenuti (notizie, documentazione, corsi, catalogo e-commerce).

Considerare invece il nativo o React Native quando:

• Avete bisogno di Bluetooth, NFC, GPS in background continuo o capacità AR avanzate.
• Il vostro prodotto è un gioco o un'esperienza di streaming audio/video.
• La presenza nello store di app è un segnale di fiducia nel vostro mercato.
• Avete bisogno di una profonda integrazione con il sistema operativo: widget, scorciatoie vocali, estensioni di condivisione.

Consultate il nostro articolo App web vs nativa vs PWA per l'analisi completa dei costi e della portata. Il nostro servizio di sviluppo di app web include le PWA come output di prima classe.

Checklist di sviluppo PWA

Usate questa checklist prima di distribuire una PWA in produzione:

FAQ

Che cos'è una Progressive Web App e come si differenzia da un'app web normale?

Una Progressive Web App è un'applicazione web che utilizza API browser moderne — principalmente service worker, il Web App Manifest e la Push API — per offrire un'esperienza paragonabile a un'app nativa. Può funzionare offline, memorizzare nella cache le risorse per caricamenti quasi istantanei, ricevere notifiche push ed essere installata sulla schermata Home senza passare per uno store.

Le PWA funzionano su iOS nel 2026?

Sì, con alcune limitazioni. iOS 16.4+ supporta Web Push (PWA sulla schermata Home), Background Sync, l'API Badging e l'archiviazione persistente. Tuttavia, iOS non dispone di Background Fetch, Bluetooth/NFC completo né Screen Wake Lock. Il flusso di installazione richiede un gesto manuale — non esiste un prompt di sistema. Per la maggior parte delle PWA, il supporto iOS è sufficiente nel 2026.

Quale strategia di cache dovrei usare per la mia PWA?

Cache-First per le risorse statiche che cambiano raramente. Network-First per le API dove la freschezza è critica. Stale-While-Revalidate per le pagine dove un contenuto leggermente obsoleto è accettabile. Workbox di Google automatizza tutti e tre gli schemi.

Come si attiva il prompt di installazione su Android?

Catturate l'evento beforeinstallprompt (attivato quando i criteri di installabilità sono soddisfatti: HTTPS, manifesto valido, service worker con gestore fetch) e chiamate prompt() su un gesto dell'utente. Su iOS, presentate un modal che spiega il gesto Condividi > Aggiungi alla schermata Home.

Una PWA può inviare notifiche push?

Sì. Richiedete l'autorizzazione, iscrivetevi al servizio push, inviate l'abbonamento al vostro server, inviate un messaggio push dal vostro server, e il service worker mostra la notifica. Su iOS la PWA deve essere installata sulla schermata Home (iOS 16.4+).

Quando dovrei creare una PWA invece di un'app nativa?

Una PWA è la scelta giusta quando il vostro canale principale è la ricerca web, i vostri utenti sono su dispositivi diversi, i vostri requisiti offline sono moderati e non avete bisogno di Bluetooth, NFC o integrazione profonda con il sistema operativo. Vedete il nostro confronto completo su App web vs nativa vs PWA.

Quanto può essere grande la cache di una PWA?

Chrome concede circa il 60% dello spazio su disco totale. Pianificate la cache con attenzione: precache solo le risorse shell (di solito meno di 5 MB) e memorizzate nella cache le risposte API selettivamente con limiti di scadenza. Chiamate navigator.storage.persist() per evitare l'eliminazione sotto pressione.

Ultimo aggiornamento 16 giugno 2026. I dettagli tecnici riflettono le matrici di supporto di WebKit 17.x e Chrome 125+ aggiornate a metà 2026.