Tra il 2017 e il 2020 le PWA erano al centro dell'hype tecnologico. Conferenze, post sui blog, supporto ufficiale da Google e Microsoft. Poi è arrivata la delusione: iOS ha bloccato l'accesso alle API chiave, i prompt di installazione si sono rivelati confusi e il marketing delle app native era ancora più forte. La community è passata a Flutter, React Native e Capacitor.
Ma in sordina è successo qualcos'altro. Lo stack PWA ha continuato a maturare. Negli ultimi anni Apple ha aggiunto le API mancanti, i browser hanno migliorato il flusso di installazione e le specifiche dei service worker si sono stabilizzate. E per i team di prodotto senza un grosso budget, le PWA sono diventate un'opzione sorprendentemente valida.
Questo articolo è un caso di studio onesto su trefa.app — una lega di pronostici aziendale costruita come PWA — dopo un anno in produzione. Ecco cosa ha funzionato, cosa no e a chi consiglierei una PWA oggi.
Contesto: cos'è trefa.app
Trefa.app è una web app per leghe di pronostici aziendali. L'utente accede con Google, crea una lega per la propria azienda, invita i colleghi tramite un link o un codice QR e insieme pronosticano i risultati delle partite. L'app sincronizza i dati dalle API sportive (NHL, Premier League, Mondiali) e ricalcola i punti in tempo reale.
Il frontend è in Next.js 16 + React 19 + Tailwind, ospitato su Vercel. Il backend è in Django 5 + DRF + Channels su Hetzner. In mezzo, PostgreSQL su Supabase e Redis per la comunicazione in tempo reale.
Un dettaglio piacevole: non esiste alcuna app nativa per iOS o Android. La PWA è l'unico client. Gli utenti su iPhone, Android, Windows e macOS usano esattamente la stessa cosa.
Perché abbiamo scelto una PWA invece del nativo
La decisione è stata in gran parte economica. Un'app nativa avrebbe significato:
- Sviluppare due client paralleli (iOS Swift + Android Kotlin), oppure un framework multipiattaforma (Flutter, React Native).
- Il processo di pubblicazione su App Store + Google Play — costi di iscrizione, ritardi nella revisione, ripubblicazioni periodiche a ogni modifica delle API del backend.
- Notifiche push tramite APNs e FCM, due infrastrutture separate, due processi di certificazione.
- Il flusso di aggiornamento tramite gli store — l'utente deve aggiornare attivamente, e una parte degli utenti resta su una versione più vecchia per mesi.
Per un prodotto con un pubblico di riferimento relativamente ristretto (team aziendali, non il mercato di massa), il costo dello sviluppo nativo era nettamente superiore al beneficio. La PWA ha eliminato tutto questo in un colpo solo.
Vantaggi tecnici che gli utenti non noteranno mai
Questa è la parte che avrei sottovalutato prima di andare in produzione. Dal punto di vista dello sviluppo, una PWA porta una serie di vantaggi concreti che fanno risparmiare settimane di lavoro all'anno:
Il deploy è istantaneo. Push su main → Vercel fa la build → in 2 minuti la nuova versione è davanti a tutti gli utenti. Niente pubblicazione, niente attese, niente acrobazie di compatibilità tra le versioni del client e del backend. Se introduco una modifica che rompe le API, il giorno dopo posso rilasciare una correzione e tutti la ricevono immediatamente.
Un'unica codebase per tutto. iOS, Android, Windows, macOS, Linux — la stessa app ovunque. Niente bug specifici per piattaforma ("questo si rompe solo su iPhone 13 in dark mode"), nessuna implementazione duplicata.
Percorso breve verso l'utente. Invii un link, un clic, sei nell'app. Niente "scarica la nostra app dall'App Store, registrati e poi accedi". Per i prodotti B2B con un utilizzo a bassa frequenza (una lega di pronostici è attiva solo durante un torneo sportivo), questo è un enorme vantaggio in termini di conversione.
Le notifiche push funzionano anche senza installazione. Il service worker registra l'iscrizione alle notifiche push. Una volta che l'utente clicca su "Consenti notifiche", inizia a ricevere gli avvisi prima delle partite, indipendentemente dal fatto che abbia aggiunto l'app alla schermata Home o che la apra solo occasionalmente in Safari.
Cosa non può fare una PWA (in tutta onestà)
Qui l'onestà conta più del marketing. Una PWA ha limiti reali che abbiamo incontrato in produzione.
Le notifiche push su iOS hanno qualche vincolo. L'Apple Web Push esiste dalla versione iOS 16.4, ma funziona solo se l'utente ha aggiunto la PWA alla schermata Home. Se usa l'app dalle schede di Safari, l'iscrizione push non si mantiene. È un attrito che le app native non hanno.
Manca la presenza sull'App Store. Per alcune buyer persona (reparti HR, responsabili IT aziendali) "non sull'App Store" equivale a "non serio". Soggettivo, ma reale.
Alcune API del sistema operativo non sono disponibili. Bluetooth Low Energy, NFC, accesso completo al file system — per un'app tipica va bene, ma se hai bisogno di queste funzionalità, la PWA ti limita.
La modalità offline è possibile, ma non automatica. Il service worker va configurato manualmente, le strategie di cache vanno progettate, le code di sincronizzazione vanno implementate. Per un'app interamente offline-first questo è più lavoro di quanto gli sviluppatori si aspettino.
Benchmark di performance vs. nativo: una PWA è circa il 15–25% più lenta al primo caricamento (parsing del bundle JS) e circa il 5–10% nelle interazioni quotidiane. Per la maggior parte delle app è impercettibile, per il gaming spinto o l'editing video è un fattore decisivo.
Risultati dopo un anno in produzione
Dati concreti di trefa.app dopo un anno di attività:
- Stabilità multipiattaforma — un team di sviluppo di una sola persona mantiene l'app su tutti i sistemi operativi senza bug specifici per piattaforma. Lo stesso ciclo di test per tutti.
- Frequenza dei deploy — in media 3–5 deploy a settimana tramite Vercel. Nessuno di questi alle prese con i ritardi di pubblicazione dell'App Store.
- Notifiche push — circa il 70% degli utenti attivo, tasso di consegna delle push circa il 95% su Android, circa l'85% su iOS (a causa del requisito di installazione sulla schermata Home).
- Nessuna commissione App Store — risparmiati circa 70 USD all'anno in account sviluppatore, più circa il 30% di commissione sulle transazioni (che altrimenti si applicherebbe agli acquisti in-app).
Il principale beneficio per il business, tuttavia, non è stato tecnico. È stata la velocità di iterazione. Se un cliente scriveva "questa funzionalità mi aiuterebbe", di solito ci iniziavo a lavorare lo stesso giorno e la rilasciavo entro la settimana. Con un'app nativa questo semplicemente non è possibile.
A chi consiglierei una PWA oggi
Una PWA è la scelta giusta se valgono almeno due delle seguenti condizioni:
- Hai risorse limitate e non puoi permetterti due app native più una versione web.
- I tuoi utenti usano l'app occasionalmente (non ogni giorno), quindi conta avere poco attrito alla prima apertura.
- La tua app non ha bisogno di API di sistema spinte (Bluetooth, NFC, accesso completo al file system).
- Vuoi fare il deploy senza avere gli app store di mezzo.
- Il tuo pubblico è misto — iOS più Android, mobile più desktop.
Probabilmente una PWA non è la scelta giusta se:
- La tua app gira ogni giorno, per diverse ore al giorno, e gli utenti la usano in modo intensivo (social media, messaggistica).
- Hai bisogno di integrazioni avanzate con il sistema operativo.
- I tuoi acquirenti si aspettano una presenza sull'App Store.
- La performance è critica (gaming, video, AR).
Conclusione
L'hype per le PWA sarà anche finito, ma la tecnologia è cresciuta in silenzio fino a un punto in cui, per molti prodotti, è una scelta migliore rispetto al nativo. Trefa.app è su PWA da un anno e non vedo alcun motivo per cambiare. Anzi — se ricominciassi oggi, ci andrei ancora più deciso.
Se stai valutando una PWA rispetto a un'app nativa per il tuo progetto, tieni conto di una cosa oltre agli argomenti tecnici: una PWA ti porta in produzione più velocemente. E nelle fasi iniziali, la velocità di iterazione vale più di qualsiasi altra cosa.
A proposito, puoi provare trefa.app tu stesso — niente installazione, basta un clic e stai già pronosticando.