Trasformare il sito in un’app installabile: quando conviene una PWA

Che cosa cambia rispetto a un normale sito

La PWA utilizza tecnologie web e resta raggiungibile attraverso un indirizzo. Nei sistemi compatibili può aggiungere un’icona al dispositivo e aprirsi in una finestra dedicata. Chi non la installa deve poter continuare a utilizzare il sito dal browser: l’installazione è una possibilità offerta al cliente, non un passaggio da imporre per leggere informazioni o contattare l’azienda.

Come spiega MDN sull’installabilità, l’esperienza dipende dalla piattaforma. Avere un’icona non significa essere presenti nell’App Store o in Google Play: un’eventuale distribuzione negli store è un progetto separato, con requisiti e verifiche propri. Nel preventivo chiedi quindi che cosa viene realmente consegnato e attraverso quale percorso il cliente lo utilizzerà.

Parti da un motivo concreto per tornare

Una PWA merita una valutazione quando le persone tornano per consultare ordini, riacquistare prodotti, leggere documenti o gestire appuntamenti. Per un sito visitato una sola volta per cercare un numero di telefono, migliorare navigazione e velocità potrebbe essere un investimento più utile. Non decidere soltanto perché i concorrenti hanno un’app.

Esempio ipotetico: un grossista serve officine che ogni settimana ordinano gli stessi materiali. Una PWA potrebbe aprire direttamente l’area clienti e rendere più comodo ritrovare gli ordini precedenti. Prima di svilupparla, il grossista verifica con alcune officine se il problema principale sia l’accesso al sito o la difficoltà nel trovare i ricambi. Nel secondo caso va migliorato prima il catalogo. L’icona non risolve da sola una ricerca inefficace.

Prepara il sito prima di aggiungere l’installazione

Controlla navigazione mobile, leggibilità, moduli, collegamenti e connessione HTTPS. Un sito che richiede di ingrandire lo schermo per completare un ordine conserva il problema anche quando si apre come app. La guida ai problemi del sito da smartphone offre un punto di partenza per queste verifiche.

Per un’esperienza curata, lo sviluppatore configura il manifest: un file che descrive elementi come nome, icone, pagina iniziale e modalità di apertura. Alcuni browser consentono di installare anche siti che non soddisfano tutti i criteri di una PWA; per questo la sola presenza di un comando di installazione non certifica la qualità del lavoro. Definisci anche cosa accade aprendo un link esterno, tornando indietro e riprendendo una sessione interrotta.

Prova il percorso su iPhone, Android e computer

Su iPhone, le istruzioni Apple per Safari prevedono il menu di condivisione, “Aggiungi alla schermata Home” e, nelle versioni che lo mostrano, “Apri come app web”. Non promettere lo stesso pulsante automatico presente in altri browser: prepara istruzioni adatte alla versione utilizzata.

Su Android il risultato varia con browser e dispositivo: può essere un’app integrata nel sistema oppure un collegamento alla pagina. Anche da computer modalità e disponibilità cambiano. La documentazione web.dev sull’installazione illustra queste differenze.

Prepara una piccola matrice di prova con i dispositivi dei tuoi clienti: apertura dal browser, installazione, riapertura dall’icona e completamento dell’azione principale. Registra gli esiti, evitando di considerare sufficiente una sola dimostrazione sul telefono dello sviluppatore.

Stabilisci che cosa deve succedere senza connessione

Installabile non significa automaticamente utilizzabile offline. Come descrive MDN sulle operazioni offline, un service worker può gestire richieste e contenuti conservati sul dispositivo. Occorre però decidere quali risorse salvare e come usarle quando la rete manca.

Un catalogo consultabile offline non garantisce prezzi e disponibilità aggiornati. Un carrello salvato non è un ordine ricevuto; una richiesta scritta non è una prenotazione confermata. Pagamenti, verifica delle scorte e assegnazione di un appuntamento dipendono normalmente da servizi online. Il sito deve distinguere chiaramente bozze locali, operazioni in attesa e conferme effettive.

Nel collaudo disattiva la connessione prima dell’apertura e durante un’operazione. Verifica messaggi, recupero dei dati e comportamento quando torna la rete. Non accettare una schermata di successo se il server non ha registrato l’azione.

Controlla accessi, pagamenti e notifiche separatamente

Prova login, recupero password, uscita dall’account e ritorno da un pagamento esterno nella versione installata. Controlla che un cliente non trovi dati dell’utente precedente su un dispositivo condiviso. Per i servizi riservati, definisci le autorizzazioni prima dell’interfaccia: la guida all’area clienti del sito aiuta a chiarire documenti e accessi.

Le notifiche richiedono un’implementazione specifica, supporto del dispositivo e autorizzazione dell’utente. Su iOS e iPadOS, WebKit documenta il supporto Web Push per le app aggiunte alla schermata Home a partire dalla versione 16.4, con richiesta del permesso legata a un’azione dell’utente. Non presentarle come messaggi che arriveranno sempre a tutti.

Per conferme importanti mantieni un percorso consultabile nell’account e gli altri canali previsti dal servizio. Una notifica disattivata non deve impedire al cliente di sapere se l’ordine è stato accettato.

Prevedi aggiornamenti senza mostrare informazioni vecchie

La memoria locale può velocizzare l’esperienza, ma richiede regole. La guida web.dev alla cache chiarisce che memorizzare e aggiornare le risorse sono scelte dell’applicazione. Evita di trattare allo stesso modo un’icona, un listino personale e la disponibilità di un appuntamento.

Nel capitolato indica quali informazioni devono essere verificate online e come eliminare le copie superate. La gestione degli aggiornamenti deve considerare anche le persone che tengono l’app aperta: un nuovo rilascio non dovrebbe interrompere un modulo compilato a metà.

Chiedi una prova completa: modifica un contenuto, riapri una vecchia installazione e controlla quando compare la nuova versione. Verifica inoltre che logout e cambio utente gestiscano correttamente i dati locali. Conserva un referente per manutenzione e assistenza dopo la consegna.

Approva il progetto sulla base di prove e risultati utili

Chiedi un preventivo che distingua sviluppo iniziale, eventuali licenze, verifiche sui dispositivi e manutenzione. Prima di estendere il progetto, prova il percorso con un gruppo di clienti abituali e osserva dove chiedono aiuto.

• L’azione ricorrente da semplificare è definita.
• Il sito resta utilizzabile senza installazione.
• Installazione e riapertura sono provate sui dispositivi scelti.
• Accesso, uscita e pagamenti hanno esiti verificabili.
• Contenuti offline e operazioni che richiedono rete sono distinti.
• Notifiche e relativi permessi sono facoltativi e comprensibili.
• Una vecchia installazione riceve correttamente gli aggiornamenti.
• Responsabilità di manutenzione e assistenza sono concordate.

Misura quante persone tornano e completano l’attività, quanto tempo impiegano e quali problemi segnalano. Un numero elevato di installazioni, senza utilizzo successivo, non basta a dimostrare che la PWA abbia migliorato il servizio.