Le Progressive Web App (PWA): il futuro è già qui?

A Progressive Web App is an app that can provide additional features based on the device support, including offline capabilities, push notifications and almost native app look and speed, and local caching of resources.

In questo post analizzerò questa “nuova” metodologia di sviluppo SW, sperando possa servire per evidenziare quelli che sono i punti a suo favore e che fanno presupporre che nei prossimi anni possa quasi sostituirsi al paradigma delle attuali app scaricate/acquistate da uno store ed installate su un proprio device. Si basa sul meglio delle tecnologie attualmente in circolazione del web da un lato e delle applicazioni native dall’altro, riducendo così un divario che sembrava epocale. In poche parole, questa tecnologia permette di trasformare un sito anche in un’app potenzialmente ricercabile ed installabile anche da uno Store, mantenendo molte delle caratteristiche proprie delle app, quali la sua possibilità di installazione in standalone al di fuori del browser: per fare ciò viene effettuato una cache nel dispositivo client (e.g. telefono) del sito o parte di esso per agevolarne l’utilizzo in termini di usabilità, con UI adaptive e responsive (cioè, capaci di adattare il layout a diverse risoluzioni e orientamenti del device, di loro natura cross-platform e, quindi, indipendenti dalla risoluzione video), e potenzialmente anche quando offline, utilizzando le funzionalità offerte da un componente chiave (e.g. Service Worker). Come lo stesso acronimo utilizzato indica, una PWA permette ad un utente di navigare normalmente quel sito web e, se lo trova interessante, può installarselo promuovendolo progressivamente da sito web ad app, in modo da poter beneficiare di alcune funzionalità proprie di un’app, che non necessariamente vogliamo abilitare di default quando visitiamo un sito web.

Per di più viene mantenuta la sua capacità di indicizzazione (SEO), propria di ogni sito, con conseguenti vantaggi di “reperibilità” e senza richiedere una installazione e successivi aggiornamenti (basta che lo sviluppatore aggiorni il sito lato server e l’utente vede automaticamente sul suo client la nuova versione).
Personalmente non credo che, almeno nel breve periodo, soppianteranno del tutto le applicazioni native, seppure siano già una realtà molto interessante da considerare per certi scenari dove l’applicazione è principalmente di front-end e non richiede una grande integrazione con il sistema operativo. Perciò nell’immediato futuro probabilmente coesisteranno entrambe le modalità, ma i vantaggi economici propri dello sviluppo di PWA e le sue probabili future evoluzioni pilotate appunto dalla richiesta, fanno pensare ad una loro significativa e progressiva sempre maggior diffusione in diversi contesti. Si noti comunque che una PWA può coesistere senza alcun problema con l’equivalente app nativa, come già avviene attualmente per alcune applicazioni (e.g. Twitter).
Inoltre, la maggiore potenza elaborativa dei dispositivi, anche quelli mobili, e la sempre più capillare e continua presenza di una connessione alla Rete, sono e saranno sempre più fattori che faciliteranno la diffusione delle PWA, soprattutto per quelle app che non si usano continuamente. Infatti, soprattutto per le piccole organizzazioni, realizzare e mantenere un’app nativa è costoso, ancor più se si desidera renderla disponibile su più piattaforme e anche da browser, per cui la modalità proposta dalle PWA può essere sicuramente la soluzione per loro più opportuna. Talvolta la disponibilità di un servizio viene meno se non si dispone del dispositivo adeguato: è questo ad esempio il caso di alcune soluzioni di bike-sharing che richiedono l’utilizzo unicamente di app Android o iOS, senza fornire alcuna possibilità di affitto per chi ha a disposizione un altro dispositivo mobile o un browser. Se queste applicazioni fossero state sviluppate come PWA, avrebbero consentito di superare questo possibile gap, risultando assi più “inclusive“.
Perciò, probabilmente nel prossimo futuro saranno proprio le PWA a dominare, in sinergia sia con l’intelligenza artificiale sia un hardware locale sempre più potente (non solo su smartphone ma anche su PC Windows cellulare) sia il cloud computing ed una onnipresente connessione dati ad elevata banda.

Ho recentemente sentito una presentazione in cui come sottotitolo aveva questa affermazione: “PWA is the most exiting thing that happened to the web since Ajax (2005)“. Prima dell’onda legata ad HTML5, ancora in perenne evoluzione, sviluppare applicazioni web cross-browser e cross-platform era molto complesso ed anche le potenzialità disponibili sui dispositivi mobili erano limitate per cui la navigazione su browser avveniva principalmente su desktop, magari potenziando il browser con plug-in non dettati da alcuno standard, quali Silverlight o Flash. Oggi i dispositivi più utilizzati sono gli smartphone, assi più potenti di un tempo, e le tecnologie intorno ad HTML5 e al web si sono evolute sempre più per far fronte a questa nuova esigenza, rimettendo al centro gli standard che stanno cercando di rimettere in primo piano il web, anche perché il costo di sviluppare e soprattutto mantenere entrambe le versioni di un’app è generalmente troppo elevato. Negli ultimi 5 anni le specifiche dello standard HTML5 sono state sempre più supportate da tutti i browser, tanto che oggi una direttiva di CSS o una chiamata JavaScript funzionano bene su qualsiasi browser (Chrome, Edge, Firefox, Opera o Safari) per chi il web è diventato veramente cross-platform e cross-browser.

Le WPA sono ben più che i tradizionali “web wrapper”, cioè semplici browser inseriti all’interno di una app: sebbene non siano app native, le API di Cache e di Push hanno già ampliato di molto i loro ambiti di utilizzo. Grazie al web Service Worker e al Caching hanno una maggiore integrazione con il sistema operativo (e.g. notification), consentono la sincronizzazione dei dati in background (e.g. inviare input dell’utente in un form anche in un secondo momento qualora manchi temporaneamente la connessione), ricevono aggiornamenti live e possono anche funzionare offline.

============================================================

In questo post (per ora) non dirò nulla di nuovo rispetto a quanto già si può leggere in molti articoli, per cui se credi puoi andare direttamente ad approfondire ai seguenti link o in molti altri articoli che sempre più spesso escono anche sulle maggiori testate Web:

Molto interessante è anche questo video su YouTube: All you need to know about PWA, oltre ai molteplici tutorial presenti sul Channel YouTube per gli sviluppatori di Google. (e.g. Progressive Web Apps course; Getting Started With PWA; Progressive Web App tutorial – learn to build a PWA from scratch). Inoltre, esiste nel sito di Google per gli sviluppatori una sezione apposita di Get Started dove, passo-passo, viene indicato come effettuare lo sviluppo di una PWA di esempio, partendo dai suoi componenti minimali, a livello di HTML, CSS e JavaScript. In particolare, sempre in quel sito, esiste una sezione in cui viene fornito una checklist di tutte le funzionalità che una PWA deve avere, sia quelle base (Baseline Progressive Web App Checklist, verificabili automaticamente tramite un tool open-source Lighthouse) sia quelle avanzate (Exemplary Progressive Web App Checklist, il cui check si deve effettuare manualmente in quanto non ancora implementati in quel tool) che consentono di ottenere una più significativa esperienza offline, raggiungendo una interattività ancora più veloce e prestando anche attenzione ad ulteriori dettagli.

Da tempo lo sviluppo sul web ha fatto uso di tecnologie e metodologie che consentono di avere pagine dinamiche (e.g. Ajax, jQuery, responsive web design), ma solo negli ultimi anni i miglioramenti nell’HTML5, CSS3, e JavaScript, hanno reso possibile realizzare le cosiddette app ibride che imitano l’esperienza utente delle app native su mobile. Tuttavia queste ultime hanno ancora la necessità di un App Store per essere scaricate e, in quanto app, consumano spazio di memoria sul terminale utente. Inoltre, fino a poco tempo fa, le app native hanno fornito una user experience migliore, una maggiore velocità di esecuzione, caricandosi più velocemente rispetto all’uso del browser, oltre a poter fornire funzionalità che richiedono un accesso diretto all’hardware. Con le PWA il mondo del Web fa un ulteriore passo avanti … potendo funzionare anche offline e in background, potendo avere anche requisiti per poter ottenere, dal Sistema Operativo, concessioni di accesso a funzionalità presenti sul dispositivo (e.g. telecamera, come fa attualmente la PWA di Instagram). Il comportamento previsto è conforme con i requisiti del modello RAIL introdotto da Google stesso (Response, Animation, Idle, Load), cioè deve rispondere subito alla richiesta dell’utente, facendogli visualizzare un’animazione durante l’attesa, utilizzando questo momento di inattività (Idle) per immagazzinare più contenuti possibili e poi caricare il tutto in meno di un secondo.

Parlandone anche con alcuni colleghi, penso che il termine Progressive Web App (PWA) non sia ancora sufficientemente conosciuto anche dagli addetti ai lavori, seppure sia stato coniato da Frances Berriman e dallo sviluppatore Alex Russell di Google Chrome nell’ormai lontano 2015: tuttavia, qualunque tecnico si soffermi a conoscerlo, anche superficialmente, non può che condividere quelli che sono i vantaggi che un utilizzo delle PWA comporta per tutti gli attori in gioco! In alcuni articoli si parla infatti delle PWA come di una tecnologia win-win, cioè dove tutti sono i vincitori e nessuno risulta perdente … ed è proprio per questa ragione che penso, come molti altri, che avrà un sicuro futuro. Vediamo quindi nel seguito quali sono i vantaggi considerando uno per uno gli attori coinvolti.

Le ditte, soprattutto quelle piccole, troppo spesso attualmente non investono nel realizzare un’app in quanto troppo costoso è il suo sviluppo e soprattutto la sua manutenzione su più piattaforme. Per loro risulta più vantaggioso chiedere ad un Web developer di trasformare in PWA il sito che comunque generalmente la ditta possiede. Inoltre, le app PWA hanno maggiore visibilità in quanto possono essere trovata non solo cercandole negli Store ma anche tramite i motori di ricerca. Risulta plausibile che anche i sistemi di Banking online presto si appoggeranno alle PWA, in quanto tipicamente mantenere una app bancaria risulta dispendioso per via dei requirement di sicurezza e di rispetto di requisiti di legge: molto più agevole è invece mantenere semplicemente solo un sito Web nuovo, PWA-enabled, estendendo le funzionalità già presenti nei siti bancari che si collegano direttamente ai loro servizi di backend, presenti da ben prima che le app prendessero piede.

Anche per uno sviluppatore di applicazioni, il più grande vantaggio è il risparmio di costi in termini di sviluppo e di manutenzione: non deve più preoccuparsi di sviluppare e gestire la stessa app per più piattaforme o utilizzare framework per sviluppi multipiattaforma che, in generale, non risultano di facile utilizzo. Molte delle competenze proprie degli sviluppatori di siti web dinamici, possono essere inoltre riutilizzate anche in questo contesto di sviluppo. Le app PWA hanno maggiore visibilità in quanto possono essere trovata non solo cercandole negli Store ma anche tramite i motori di ricerca. Una PWA può essere condivisa fornendo semplicemente la sua URL. Una informazione contenuta in un’app nativa risulta più difficile da trovare, non potendo a tale scopo essere sfruttata la potenza dei motori di ricerca: si rischia quindi di “perdere” traffico Web. Avendo poi pubblicato la PWA anche in uno Store, lo sviluppatore può comunque ricevere dagli utilizzatori dei commenti, assai utili per eventualmente migliorare il sito associato.
Il lato negativo, tuttavia, è che la professionalità degli sviluppatori di codice nativo risulta penalizzata, in quanto per realizzare PWA quella competenza non risulta più così essenziale e quindi potrà non essere così richiesta.
L’articolo Why your web project should be a PWA elenca, in particolare, le seguenti indicazioni che in parte sintetizzano quanto già da me indicato:

Non è più necessario creare applicazioni per ciascuna delle piattaforme mobili, nessun codice separato da sviluppare e da dover gestire. Risulta relativamente più economico rispetto allo sviluppo di applicazioni native.
Funziona su tutte le piattaforme e su tutti i dispositivi, massimizzando così la sua diffusione con conseguente vantaggio commerciale.
A differenza delle sue controparti native, funzionando all’interno del browser dell’utente, non richiede un’installazione prima del suo primo utilizzo.
È notevolmente migliorata la cross-funzionalità di un’app, il passaggio tra le applicazioni è molto più veloce ed intuitivo (e.g. Instant Articles di Facebook, in-app browser per Slack). Per maggiori informazioni su Instant Articles, vedere i video tutorial presenti in Facebook Blueprint eLearning. Per informazioni sulle app collegate con Slack vederne l’elenco nell’App directory e la sezione per gli sviluppatori. Tool e servizi possono essere integrati con Slack in modo che il team può rimanere coordinato, lavorare più velocemente, mantenere le conversazioni e il contesto tutto in un unico luogo.
La user experience è unificata in quanto tutti gli utenti agiscono sull’unica ultima versione dell’app, che quindi avrà ovunque lo stesso aspetto, le medesime funzionalità, gli ultimi aggiornamenti di protezione, senza necessità di scaricarla ed installarla ad ogni modifica. Tutti gli utenti hanno perciò accesso alla stessa versione dell’app, fornendo costantemente la migliore esperienza utente, ottimizzata per l’intero parco di utenza.
Offre un grado di libertà maggiore dal sistema operativo utilizzato sulla piattaforma. Si è liberi di sviluppare una funzionalità come la si desidera, senza eventuali vincoli dettati dal sistema operativo (e.g. iOS, Android, Windows).

Tuttavia, almeno per ora le PWA hanno alcuni aspetti negativi da considerare:

Limitate capacità di integrazione con le funzionalità HW del dispositivo su cui girano (e.g. smartphone, tablet). Questo ne impedisce l’utilizzo per lo sviluppo di PWA che debbano interagire con gli accessori mobili ed i “wearable” (e.g. smartwatch, fitness tracker, auricolari wireless).
Necessità di una connessione Internet, sebbene in molti casi il Cashing e le pagine custom “offline” possano sopperire bene tale limitazione per cui molte PWA si comportano già egregiamente anche in condizioni di scarsa connettività.

È importante poi che le PWA siano presenti anche negli Store (e.g. MS Store, App Store, Google Play) per una loro categorizzazione. Microsoft si sta infatti già muovendo per inserire, anche in modo automatico, le PWA nel suo Store, effettuandone una ricerca su Web, una loro selezione e quindi una loro conversione nel formato appx proprio delle app UWP.

Ci sono solo tre requisiti tecnici per lo sviluppo di una PWA:

Deve essere eseguita utilizzando connessioni su HTTPS per garantire una connessione sicura con il server Web e conseguentemente una garanzia di sicurezza per l’utente nella sua navigazione. Questo è necessario è necessario in quanto in un sistema operativo può essere concessa ad una PWA tutta una serie di privilegi extra e quindi deve essere garantita l’origine del server che genera il codice eseguito. L’uso dell’HTTPS è comunque diventato da tempo un requisito anche per tutte le comunicazione delle app iOS
Deve esporre un manifesto (Web App Manifest) che serve ad indicare al browser quali asset dovrà scaricare per supportarne l’esecuzione in mancanza di rete, avvisando quali risorse saranno disponibili offline. Si tratta di un file JSON con informazioni sul sito a cui si deve fare riferimento nell’Header delle sue pagine Web, in modo tale che possa essere trovato sia dai motori di ricerca sia dai browser: viene inserito con “link” direttamente nella pagina principale della PWA (<link rel=”manifest” href=”/manifest.json”/> ) e contiene al proprio interno sicuramente la pagina di avvio, la splash screen e le icone relative all’app, oltre ad altre informazioni opzionali (e.g. l’orientamento con cui partire, se deve essere aperta come app o all’interno di un browser) . Il manifest consente di controllare come la PWA viene visualizzata ed avviata: ad esempio è possibile specificare le icone della schermata iniziale, la pagina da caricare quando l’app viene avviata, l’orientamento dello schermo e anche se deve essere visualizzata in una finestra indipendente o internamente al browser. Tramite il manifest, una PWA deve avvisare quali risorse saranno rese disponibili offline. Consente anche di consentirne una installazione sul proprio device.
Deve avere un Service Worker che può essere creato su misura per l’attività che intende svolgere, partendo dalle indicazioni e dagli esempi presenti nelle guide per lo sviluppo. E’ l’elemento chiave che rappresenta il meglio della rivoluzione delle PWA in quanto consente la gestione sia delle notifiche push con i suoi task in background, sia di usufruire di contenuti offline tramite un meccanismo di cache delle risorse chiave, eliminando la dipendenza dalla rete in modo da consentire un funzionamento anche offline o con reti di bassa qualità. Un service worker, che nient’altro è che un file JavaScript creato in modo opportuno, è come un proxy client-side che gestisce la cache e come rispondere alla richieste di risorse: ogni richiesta del browser viene intercettata in modo da eventualmente restituire immediatamente dati presenti nella cache locale, senza nemmeno interpellare il server che può tra l’altro risultare momentaneamente irraggiungibile. Consente ad una PWA di aprirsi in modo rapido all’avvio, anche in mancanza di rete, perché i suoi file sono stati preventivamente scaricati in locale nella cache. Inoltre può eseguire task in background, capaci di effettuare o intercettare richieste a risorse remote, inviare notifiche push o sincronizzare dati. Si noti infine che un Service Worker funziona solo in https o in localhost, per motivi di sicurezza. Grazie alla sua funzionalità di cache, il tempo di caricamento iniziale della PWA è rapido, prendendo i dati localmente, per poi eventualmente aggiornarli ad applicazione attiva. Un Service Worker si registra nel Javascript principale dell’applicazione.

Come indicato in un post di Bochicchio, le specifiche proprie delle PWA coprono le seguenti funzionalità:

Offline API: possibilità di salvare localmente i dati, per poterli riutilizzare in caso di mancanza di rete;
Web Notification API e Push API: per inviare notifiche push dall’ app;
File API: per accedere al file system, aprire e salvare file;
Drag&Drop API: per poter trascinare file dal desktop verso il client;
Media Capture and Streams API: per implementare nel browser il supporto a WebRTC, gestire flussi di audio e video e la loro manipolazione;
MediaDevices API: per accedere ai device collegati, come webcam, microfoni, schermi esterni e, in generale, all’hardware esporto;
Locale Storage API: per salvare informazioni localmente al browser e mantenere costantemente l’utente aggiornato;
Location API: per accedere alla posizione del device, attraverso il GPS o una tecnologia alternativa;
WebGL: per visualizzare e manipolare grafica 3D in piattaforme che supportano OpenGL (standard open source per rappresentare elementi in 3D);
Fullscreen API: per promuovere contenuti a tutto schermo;
Battery Status API: per accedere allo stato della batteria dell’utente.

Per l’utente finale le PWA si comportano e si mostrano con un look & feel tipico delle app native. Hanno per di più il vantaggio che non occupano necessariamente spazio in memoria per cui si possono utilizzare moltissime app PWA anche su telefoni con poca memoria, analogamente a come si può accedere ad innumerevoli siti con il suo browser: infatti, di fatto sono siti web che si possono “installare” nello smartphone con una modalità simile alle app native. Inoltre l’utente si ritrova la medesima interfaccia, indipendentemente dal dispositivo usato, del suo sistema operativo e dal tipo di browser. Può trovarle più agevolmente potendole ricercare sia da un motore di ricerca sia negli Store.

Per i grandi attori Google, Microsoft ed Apple i motivi di interesse sono probabilmente differenti ma di fatto tutti si stanno impegnando per rendere i loro browser PWA-enabled. Chrome, Opera (che ha lo stesso engine di Chrome), Firefox, supportano le PWA anche con le loro relative push notification. Per ora il browser che supporta ufficialmente maggiormente le PWA è Chrome. Con l’importante aggiornamento di Windows 10, denominato Spring Creators Update, anche Edge è diventato più compatibile con le PWA che, tra l’altro, incominciano ad essere presenti anche all’interno del MS Store: un supporto più completo di Edge si avrà poi con update autunnale. Anche Apple con il suo browser Safari si sta adeguando un po’ più lentamente avendo un proprio business nelle app presenti nel suo Store, ma non potendo comunque rimanere troppo indietro su questa tecnologia comunque promettente.

Google è stata la prima a crederci e ad implementarla nel suo browser Chrome. Alex Russell, l’ingegnere di Google Chrome, ha scritto in un articolo intitolato “Progressive Web Apps: escaping tabs without loosing our soul“, ciò che è considerato essere il ground zero per il movimento PWA: Google ha poi solidificato l’iniziativa con una sezione specifica nel portale developers.google.com, spingendo ulteriormente in avanti il concetto là espresso. Quindi, ironicamente, non è stata Microsoft il principale fautore delle PWA e questo, di primo acchito, può sorprendere in quanto Google non ha certo il problema dell’app gap. I motivi della scelta di Google sono legati ovviamente alla pubblicità ed alla indicizzazione delle informazioni: il suo modello di business è sicuramente nel Web e non nella vendita di app dal suo Store o di device Android. Quest’ultimo S.O. è stato supportato solo perché l’utente usi i Servizi Google preinstallati che operano appunto sul Web. Ciò che non interessa a Google è avere app native che inviano i dati direttamente ad un loro server, senza utilizzare le funzionalità del Web, in quanto ciò non le porta alcun vantaggio: Google è interessata invece ad un utilizzo del Web, agli analytics, al Search Engine Optimization, per i vantaggi pubblicitari che ne derivano. Un ritorno massivo al Web anche delle app non può quindi che far comodo a Google! Le PWA consentono pienamente il tracciamento e l’engagement degli utenti: tutte le pageviews provenienti dalle app PWA installate sono tracciabili in Google Analytics. Per Google i benefici derivano perciò dal fatto che le PWA sono trattate come qualsiasi sito JavaScript il che significa che quando Google “crawl” il Web, anche per le PWA possono essere utilizzate le specifiche ottimizzazione dei motori di ricerca (SEO), cioè quelle attività volte a migliorare la visibilità di un sito web sul suo motore di ricerca, migliorandone il ranking.

Microsoft ne ha compreso un suo vantaggio non da molto, dopo avere tentato diverse strade per incrementare il popolamento del suo Store. Oltre ad avere supportato sistemi di sviluppo multipiattaforma (e.g. Xamarin), creato un Desktop Bridge per la conversione a UWP di applicazioni win32 (vedere Come convertire i programmi win32 in UWP utilizzando Desktop Bridge), ora sta vedendo nelle PWA una nuova possibilità per superare il gap attuale che il MS Store ha e con quelli della concorrenza (i.e. App Store, Google Play). Perciò Microsoft incomincerà a supportare le PWA già nella prossima release primaverile di Windows 10 e ancor più in quella autunnale.
Le PWA potranno essere introdotte nel Microsoft Store tramite due meccanismi:

Gli sviluppatori le inseriscono manualmente, analogamente a quanto avviene già per le altre tipologie di app. Anche se un’app PWA-UWP può essere aggiornata in qualsiasi momento nel Windows Store, molti dei suoi contenuti sono dinamici per cui le aziende possono semplicemente apportare modifiche al backend, riducendo così il tempo di consegna ai clienti. Inoltre, per i principi su cui si basano le PWA, come il supporto per HTTPS e la presenza in uno Store che ne individua la provenienza (“siloed apps“), l’utente sa che l’applicazione è sicura.
Microsoft le aggiunge automaticamente ricercandole nel Web con un suo motore di ricerca specifico (Bing Clawler), filtrando quelle PWAs che soddisfano i requisiti tecnici e di qualità richiesti, nel rispetto dei requisiti propri del MS Store. Utilizzando un Bridge specifico, se ne effettua il wrapping in contenitori appx, convertendole in UWP, inseribili perciò nello Store in modo analogo a quando già avviene con le app native. Così facendo, queste PWA acquistano anche ulteriori funzionalità, quali le live tile, l’uso di Cortana, consentire di effettuare in-app purchase per avere funzionalità aggiuntive, avere analytics più approfonditi oltre che ampliare la discoverability del sito e per di più quell’app UWP non necessita di essere più ripubblicata in quanto tutti i futuri aggiornamenti possono essere effettuati direttamente solo agendo sul sito stesso puntato. Inoltre, in questo modo una PWA non si apre nel browser bensì gira in un suo container, comportandosi proprio come un’app nativa. Questo packaging effettuato dal Bing Crawler viene effettuato gratuitamente e non c’è alcuno scambio di denaro. Poiché non si aggiunge pubblicità per avere introiti ed essendo questi siti pubblici, Microsoft non ha neppure necessità di chiedere il permesso per questa loro pubblicazione nel suo Store: nell’app generata viene messo principalmente solo un semplice link al sito.
Già ora MS sta scandagliando il Web alla ricerca di web-app e le sta compilando come .appx in modo da poterle caricare nel suo Store, secondo quanto affermato in un post di WindowsBlogItalia: qui. In questo modo nel MS Store si potrà presto avere il debutto di app mai arrivate nel MS Store, quali quelle di Google.
Per queste app PWA presenti nello Store, non comporteranno una vera installazione che ruba memoria al dispositivo sebbene, da un punto di vista dell’utente finale, non cambi nulla: anzi … l’utente potrà riutilizzare persino dispositivi con poca memoria (e.g. quelli con soli 8GB), forse abbandonati solo perché saturi dopo l’installazione di poche app. Se si ricercano nello Store le app pubblicate (automaticamente) da Microsoft Store, si trovano diverse PWA: se la ricerca viene fatta da un PC se ne trovano attualmente 15 ma se poi lo si fa da uno smartphone Windows 10 Mobile se ne trovano 30!. … essendo PWA, quindi app che puntano in realtà a siti, questa differenza mi è risultata assai strana, ma poi ho visto che è solo imputabile a una non corretta visualizzazione dell’elenco delle app pubblicate da Microsoft Store (e.g. se si va, ad esempio, sull’app WHEC, una di quelle elencate su Windows 10 Mobile e non su PC, si vede che in realtà risulta non solo pubblicata effettivamente da Microsoft Store ma anche disponibile su tutti i device, compreso i PC: se la si ricerca puntualmente nello Store anche sul PC, infatti viene travata ed è possibile installarla!) … per cui sicuramente sono attualmente almeno 30 le app PWA pubblicate da Microsoft Store, ma probabilmente sono ancora di più …

Prime PWA pubblicate nello Store da Microsoft Store (come visibile da PC)

Prime PWA pubblicate nello Store da Microsoft Store (come visibile da smartphone)

Verifica che esistono anche altre app pubblicate da Microsoft Store e non elencate filtrando su quel pubblicatore

Le PWA in Windows 10 hanno tutti i vantaggi delle app UWP native e l’unica infrastruttura necessaria è quella fornita da un qualsiasi browser idoneo a supportarle: gestiscono le notifiche, tramite sia banners sia Action Center, funzionano anche offline, si adattano ai diversi formati e alle dimensioni dello schermo, possono essere eseguite su tutte piattaforme Windows 10, non solo i PC, ma anche su Xbox One, HoloLens etc…
Appaiono nei contesti relativi alle “app”, quali la tabella di Start e la ricerca di Cortana ed hanno accesso alla suite completa delle API WinRT, le stesse disponibili alle app UWP potendo così accedere ai dati locali dei contatti e del calendario (con permesso), la telecamera ed altro ancora.

Utilizzando il nuovo browser Edge, Project Andromeda (nome in codice del Surface Phone) potrebbe perciò consentire di avere già anche tutte le app PWA, incluso Google Maps. Infine, c’è da aspettarsi che anche Google adotti presto una medesima politica di inserimento delle PWA nel suo store , Google Play.
Si noti invece che nel caso dell’utilizzo del Desktop Bridge per convertire le applicazioni win32, le app risultanti non sono reali UWP, ma girano all’interno di quel suo container: di conseguenza, piattaforme come Xbox, Windows Phone o HoloLens non hanno tutta l’infrastruttura necessaria e il supporto alle API Win32 che, invece, consente anche ad un sistema operativo nuovo come Windows 10 di continuare a supportare applicazioni scritte 10 anni fa con tecnologie ormai legacy.

Lo step “Install” può anche essere abilitato in una app PWA attraverso il suo manifest, che fornisce al browser tutte le informazioni necessarie (e.g. l’icona per ogni tipo di dispositivo, lo splash screen, la visualizzazione portrait/landscape e se l’app sta operando autonomamente dal browser).

Il comportamento dei diversi browser relativamente all’installazione di un sito PWA come app sul proprio device è attualmente piuttosto differente.

Con Google Chrome si può già effettuarne il pin di un sito nel desktop e nella barra di Start: lo screenshot seguente mostra come farlo nel caso della PWA Twitter Lite, sebbene lo si possa fare con qualsiasi sito anche non PWA, ad esempio quello di questo blog. Questo da già un’idea di come le PWA possono essere impostate per essere visualizzate standalone, anche a tutto lo schermo, senza la tipica barra degli indirizzi ed i comandi tipici del browser, tutto a vantaggio dell’usabilità e della fruibilità del sito web.

Pin a site to desktop/Start: … -> More tools -> Add to desktop

Set Open as a window to run the site outside Chrome browser

Si noti tuttavia che l’icona associata a quell’app, quando inserita come tile, risulta quella generica di una Google app e non è specifica dell’app.

The site is pinned in the Start menu and can be added also as a live tile

Inoltre attualmente l’icona con il link al sito viene inserito nel menu di Start nella cartella Chrome Apps (e.g. C:\Users\Enzo\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Chrome Apps).

Il link al sito viene inserito nella cartella Chrome Apps (1)

Avendo indicato Open as window nella popup di Add to desktop, cliccando sull’icona di Twitter Lite presente nel menù di Start, si apre il sito in una finestra a parte, svincolata dal browser che comunque in background fornisce le funzionalità di base.

Il sito si apre in una finestra svincolate da Chrome, apparendo come fosse un’app.

Analogamente si ottiene se si effettua un Add to desktop di un qualsiasi sito anche non PWA, quale ad esempio questo blog.
Si noti che se poi uno cerca di disinstallare l’app (right click sull’icona nella lista delle applicazioni), viene subito aperta da Windows 10 automaticamente il Control Panel\Programs\Programs and Features come se si trattasse di una disinstallazione di un’applicazione win32 … ma ovviamente non risulta presente quell’app tra la lista delle app disinstallabili da quella sezione del Control Panel: evidentemente questa parte non è ancora correttamente gestita da Windows 10 nella sua attuale release ma probabilmente lo sarà presto!

Add to desktop di un qualsiasi sito anche non PWA, quale ad esempio questo blog.

Si può aprire anche esternamente al browser, similmente a quanto avviene per un’app.

Chrome inoltre cerca una serie di criteri che una PWA deve rispettare e, se li trova, mostra un banner simile a quello che vediamo navigando su un sito web che ha un’app da un dispositivo mobile, per invogliare l’utente ad installare quel sito come app attraverso l’apposito menu presente tra i settings. Infine in Chrome OS, nell’ultima build Canary, il canale di sviluppo include il supporto diretto a PWA nel sistema operativo stesso.

Safari, Opera e Firefox, seguono un approccio molto più simile a quello scelto di Chrome lasciando all’utente la libertà di installare la PWA in autonomia.

Diversamente avviene invece qualora si utilizzi Edge o Internet Explorer. Sebbene esista in entrambi la possibilità di salvare un sito nello Start, non esiste la possibilità di indicare direttamente che si apra standalone al di fuori del browser: questa possibilità viene data esclusivamente se si installa quel sito PWA dallo Store Microsoft, se ovviamente presente. Questa attuale scelta viene giustificate dal fatto che garantisce una certa sicurezza all’utente, dovendo quelle app passare da un controllo preliminare: questa è tuttavia una forzatura che snatura un po’ il concetto di PWA e, data la natura delle funzionalità offerte dalle PWA, non mi sembra una necessità.

Si noti che la funzionalità Pin this site to Start di Edge comporta l’inserimento del tile l’aggiunta del tile, propriamente valorizzato, solo tra le icone della finestra di Start ma NON tra l’elenco delle applicazioni installate. Diversamente la funzionalità Add site to Apps di Internet Explore inserisce sia il tile nella finestra di Start sia lo aggiunge nell’elenco delle app installate (ma senza presentare nel right click menu l’opzione di disinstallazione, c’è solo quella di rimozione dalla lista). Se si installa la PWA dallo Store invece tutto risulta consistente: viene inserita nella lista delle applicazioni installate (con la possibilità di disinstallazione) ed eventualmente può essere effettuato il pin del tile nella finestra di Start.

Add site to Apps in Internet Explorer

Pin this page to Start in Edge

Utilizzando esclusivamente voci dei rispettivi settings, sia in IE sia in Edge, non si ottiene una vera installazione di una PWA che attualmente può avvenire solo dallo Store

Se da Chrome si fa More tools -> Add to desktop -> Open as a Window, tutto funzione tranne il processo di disinstallazione

Con la installazione tramite Chrome l’icona del tile è generica così come la collocazione tra le applicazioni (dentro la cartella Chrome Apps). Inoltre non funziona la Uninstall(right click sulla icona nella lista delle applicazioni) che apre Control Panel\Programs\Programs and Features come se si trattasse di una applicazione win32

Già oggi, gli sviluppatori interessati a testare una PWA in Windows 10 possono già abilitare in Microsoft Edge una sua funzionalità “nascosta” che supporta la tecnologia dei Service Worker, appunto richiesta dai PWA.
Si può effettuare questa abilitazione è sufficiente navigare in about: flags, per visualizzare alcune opzioni in preview, specialmente utili agli sviluppatori.
In particolare, scorrendo in basso nell’area di anteprima standard, è possibile attivare l’opzione “Abilita i processi di lavoro dei servizi“, vale a dire i Service Worker.
In realtà questa abilitazione non fornisce ancora, per ora, le funzionalità di notifica ed altro previsto dalle PWA, ma semplicemente consente ad uno sviluppatore di testare una sua PWA affinché possa essere pronta per una sua sottomissione nel Microsoft Store tra poche settimane/giorni …

Navigando in about: flags, nell’area di anteprima standard si può attivare l’opzione “Abilita i processi di lavoro dei servizi“, vale a dire i Service Worker

Essendo il browser Edge una UWP, la medesima funzionalità relativa all’URL about:flags esiste anche sugli altri device Windows 10, quale Windows 10 Mobile, dove risulta avere addirittura più checkbox relative a funzionalità attivabili: anche qui si può notare una sezione dedicata ai Service Workers, Push Notifications, Background Sync, Cache Storage).

about:flags settings page in Edge for Windows 10 Mobile (1)

about:flags settings page in Edge for Windows 10 Mobile (2)

about:flags settings page in Edge for Windows 10 Mobile (3)

about:flags settings page in Edge for Windows 10 Mobile (4)

Non c’è più bisogno necessariamente di interagire con l’interfaccia utente del browser Web, ma basta installare la PWA dallo Store, analogamente a quanto avviene per qualsiasi altre UWP.

Già ora dal browser Edge, nel caso si richieda per un sito qualsiasi il Pin this page to Start, questa viene inserita con una opportuna icona (e.g. nel caso di un blog di WordPress è l’icona del profilo dell’utente): tuttavia per ora cliccando su quella icona viene aperto il sito internamente ad Edge e non è ancora possibile svincolarlo in una window a parte, come invece è già ora possibile con Chrome selezionando l’apposita checkbox.

Pin this page to Start con il browser Edge (1)

Pin this page to Start con il browser Edge (2)

Pin this page to Start con il browser Edge (3)

… solo Apple ha tardato a prendere una sua decisione in merito alle PWA, in quanto confidava nelle sue app e del suo App Store, essendo stata lei la prima a promuovere questa tipologia di diffusione delle applicazioni. Ma avere Samsung, Google e Microsoft che implementano tale funzionalità che consente un più agevole singolo punto di contatto con il mondo consumer, ha fatto propendere anche lei ad accettare tale metodologia: perciò recentemente (febbraio 2018) ha dichiarato che il supporto per le PWA ci sarà presto in iOS 11.3 e macOS 10.13.4 perciò entro la fine di dell’anno, sebbene già ad ottobre 2017 c’erano stati segnali positivi (e.g. Work on Web App Manifest in WebKit has Begun). Per il momento tuttavia la loro implementazione ha attualmente le seguenti limitazioni, alcune ragionevoli, altre ancora limitanti:

Limite di 50Mb di cache.
Il sistema operativo iOS può decidere di liberare automaticamente la cache dopo “qualche settimana”.
Non sono implementati né il background sync né le push notification (implementate da Apple in modo proprietario).
Aggiungere l’icona shortcut sulla pagina è possibile ma per nulla agevole.

Si noti che, anche se un browser specifico attualmente non supporta tutte le features previste da una PWA, vale a dire non supporta i Service Worker e/o i Web App Manifest, ciò non significa che un sito sviluppato con quella tecnologia non possa essere navigato utilizzandolo, … anzi, magari anche solo con quello ha performance migliori a quelle che si ottenevano con il precedente sito, sviluppato con tecnologie più tradizionali ed ora soppiantato: vuole solo dire che la PWA non può magari ricevere push notification, essere inserita automaticamente nella schermata di Start/Home e funzionare anche offline. Comunque, anche ora persino in ambito Apple, in attesa di nuove versione del browser Safari, anche sulla versione attuale è comunque sempre possibile aggiungere manualmente l’installazione di un sito nella homescreen (e.g. utilizzando ember-web-app) ed anche implementare le notifiche push di OS X dal sito Web o effettuando un wrapping della PWA in un’applicazione nativa per ottenere l’approvazione iniziale per le notifiche; il funzionamento anche offline risulta invece difficilmente percorribile senza uno specifico supporto del browser.

Come giustamente viene evidenziato qui, “A Progressive Web App done right doesn’t leave anyone out“.

Effettuando ricerche su Internet, ho trovato il sito pwa.rocks, progetto opensource presente su GitHub (List of Progressive Web Apps), che racchiude un elenco di icone relative ad alcune PWA esistenti, suddividendole per categoria e consentendo a chiunque di suggerirne una ulteriore, previa autenticazione in GitHub ed tramite un inserimento manuale del codice indicato, da specializzare per puntare anche ad un ulteriore sito nuovo: insomma non certo una procedura agevole quanto una agevole pubblicazione in uno Store! Comunque, nel suo piccolo, già anche questo sito realizza una funzionalità simile a quella di uno Store, vale a dire una categorizzazione e la possibilità di effettuare un’agevole ricerca per argomenti di ciò che si desidera.

PWA rocks: lista di Progressive Web App suddivise per categorie

Un qualcosa di analogo viene fornito anche nel sito https://www.progressivewebapproom.com.

http://www.progressivewebapproom.com

Oltre ad Apple, Microsoft e Google che mettono o metteranno il supporto per PWAs nei loro rispettivi browser, molte sono poi le aziende che stanno già modificando i loro siti Web per renderli PWA, perché in fondo sono solo siti che possono fornire una migliore user experience già ora, anche utilizzando un browser classico.
Anche su Wikipedia esiste un elenco, non certo esaustivo, di alcune PWA, così come anche in questo post di Windows Central dove sono indicati alcuni siti PWA-Enabled:

… il loro numero è in continua crescita e tutte le major company stanno abbracciando questa tecnologia: Alibaba, Trivago (ditta leader nella prenotazione di hotel), Weather Channel, The Financial Times, Offline Wikipedia, Medium, Flipboard, Snapdeal, Pokedex.org, Flipkart, Forbes, Lancôme , BookMyShow, Voot.com, MakeMyTrip.com, George.com …

Alcune PWA sono in preview, come Twitter che ha Twitter Lite. Per averla come app sul proprio smartphone è sufficiente andare sul sito Twitter: se non appare la richiesta di installazione, si può usare l’opzione Add to home screen presente nel menu in alto.

L’implementazione della tecnologia PWA ha portato a Twitter:

65% aumento pagine per sessione.
75% aumento dei Tweets inviati.
20% riduzione del bounce rate ( percentuale di visitatori che entrano nel sito e poi lo lasciano, piuttosto che continuare a visualizzare altre pagine all’interno dello stesso sito).
70% riduzione della banda utilizzata nella normale navigazione. Da considerare inoltre il saving sul download dell’app che pesa 23.5 MB contro l’installazione della PWA che pesa soltanto 600K.

Lancôme ha registrato, con il nuovo sito PWA:

un incremento delle prestazioni dell’84% (tempi di caricamento minori),
un incremento del 17% delle conversioni
un incremento dell’8% sui carrelli abbandonati grazie alle notifiche push.

La PWA di Instagram è già molto performante e gestisce diverse modalità di interazione (e.g. accede alla telecamera; gestisce il double-tap per inserire un like) e anche se non ha ancora tutte le funzionalità presenti nell’app nativa, sicuramente evolverà anche grazie al probabile progredire della tecnologia PWA, attualmente solo alla versione 1.0.

C’è anche da aspettarsi che alcune compagnie, ad esempio Twitter ed Instagram, nel prossimo futuro sostituiscano negli Store le loro app native con le loro rispettive PWA, attualmente in Beta: Twitter ha già attualmente deprecato la sua app su Mac OS.

Così come ha fatto per Outlook.com, Microsoft probabilmente renderà PWA-compliant tutti gli altri suoi servizi sul Web, quindi è lecito supporre anche OneDrive.

Esistono inoltre alcuni tool opensource che consentono di realizzare PWA da propri siti, come ed esempio il plugin “Super Progressive Web Apps” di WordPress.

In un post di WindowsBlogItalia viene mostrato come usare Google Maps su un device con Windows 10 Mobile con la PWA ufficiale: per ora questa PWA realizzata da Google non supporta ancora la navigazione turn-by-turn, ma è solo questione di tempo e già ora è molto performante per cui l’esperienza utente risulta analoga a quella che si ha tramite l’omonima app.
Si noti che, in quel caso specifico, esiste anche nel MS Store anche un’app UWP di terze parti, quindi non una web-app, che implementa il client per Google Maps: attualmente è in fase di sviluppo ma risulta comunque installabile attivando sul proprio smartphone la modalità sviluppatore.

=======================================

Per chi vuole poi cimentarsi a provare a sviluppare una semplice PWA di esempio, suggerisco di vedere questi siti, oltre che ovviamente il Getting Started With PWA nel sito Google dedicato agli sviluppatori:

Framework che sicuramente sono parte fondamentale delle PWA, rendendone lo sviluppo enormemente più semplice, sono Angular, React o vue.js (ciascuno con le proprie caratteristiche) che consentono di rispondere alla navigazione interna e mantenere l’history, esattamente come ci si aspetta da un’app nativa. Inoltre assicurano un responsive design, cioè, la capacità di adattare il layout a diverse risoluzioni e orientamenti del device.

Se si desidera rendere PWA un sito preesistente, supposto che già faccia uso di un framework che lo renda adaptive e responsive, si può procedere con una metodologia Test Driven Development, utilizzando il tool Lighthouse , presente in Chrome, per individuare le funzionalità che devono essere aggiunte. Per lanciare questo tool da Chrome, basta andare nel tab Audit nella sezione … -> More tools -> Developer tools di quel browser, mentre si sta accedendo al sito che si desidera migliorare. Come indicato nella sua descrizione, “Lighthouse è uno tool open-source per migliorare la qualità di pagine Web. È possibile eseguirlo in qualsiasi pagina Web, pubblica o che richiede l’autenticazione. Ha audit per prestazioni, accessibilità, applicazioni Web progressive e altro ancora“. Altri metodiche si possono utilizzare, benché non specifici per PWA, sono GTmetrix e PageSpeed.

Utilizzo di Lighthouse per individuare come rendere PWA un sito (1)

Utilizzo di Lighthouse per individuare come rendere PWA un sito (2)

Utilizzo di Lighthouse per individuare come rendere PWA un sito (3)

Utilizzo di Lighthouse per individuare come rendere PWA un sito (4)

Utilizzo di Lighthouse per individuare come rendere PWA un sito (5)

Esiste poi una Progressive Web App Checklist in una pagina di Google dedicata agli sviluppatori, dove viene indicato how to fix it per ciascuna segnalazione evidenziata da quel tool: ad esempio, se viene segnalata la mancanza di registrazione di un Service Worker, esiste una sezione Use a Service Worker dove viene indicato come avviare quel processo registrandolo nella pagina, dopo avere ovviamente inserito l’sw.js nel proprio progetto. In quella stessa pagina viene indicato come poi verificare che un Service Worker sia effettivamente abilitato andando su chrome://inspect/#service-workers e cercando il proprio sito o anche andando su chrome://serviceworker-internals per vederne i dettagli e magari studiare il suo ciclo di vita.

chrome://inspect/#service-workers

chrome://serviceworker-internals

Può poi essere utile utilizzare talvolta una navigazione in incognito, in modo da poter chiudere e riaprire il tab essendo sicuri che il Service Worker precedente non influisca sulla nuova finestra: infatti le registrazioni e le cache create dall’interno di una finestra in incognito sono completamente cancellate dopo la sua chiusura. In tutti i browser esiste la possibilità di iniziare una navigazione in incognito/privata con quelle caratteristiche: per maggiori dettagli puoi vedere questo mio seguente post.

Per generare agevolmente il manifest, file Json che descrive l’applicazione e consente di farla installare come app su un device, si può utilizzare, ad esempio, il tool Web App Manifest Generator che fornisce già le icone nelle diverse dimensioni richieste, data un’unica immagine 512×512. Il codice generato lo si inserisce poi tra i file del progetto.