WebView nelle applicazioni: cos'è e quando ha senso utilizzarlo

Molte persone hanno utilizzato un'applicazione che, senza saperlo, era in realtà un sito Web eseguito all'interno di una shell. Lo schermo impiega un po' più tempo per caricarsi, lo scorrimento appare leggermente diverso e quando tocchi qualcosa, appare l'indicatore di caricamento che ricorda un browser. Questo è WebView al lavoro ed è presente in più app di quanto potresti pensare.

WebView è uno dei concetti più utili e, allo stesso tempo, più fraintesi nello sviluppo mobile. Usato bene, fa risparmiare tempo e denaro e risolve problemi reali. Usato male, offre un'esperienza tiepida che aliena l'utente e offusca la percezione del prodotto.

Questo testo è un'introduzione. Se sei un fondatore, un product manager o sei appena entrato nel mondo mobile e hai sentito parlare di WebView senza capire veramente di cosa si tratta, ecco la panoramica: cos'è, come funziona e, soprattutto, quando ha senso usarlo.

Cos'è in pratica una WebView

Un WebView è essenzialmente un browser senza barra degli indirizzi, incorporato in un'applicazione. Consente all'app di visualizzare contenuti web, pagine HTML, intere applicazioni web, come se fossero schermate native.

Dal punto di vista dell'utente spesso non c'è differenza visibile: apre l'app, naviga, la usa. Sotto, però, quello schermo non è stato costruito con i componenti nativi del sistema operativo. È una pagina Web renderizzata all'interno di un contenitore.

Sia Android che iOS offrono ufficialmente questo componente. In altre parole, WebView non è un hack, è uno strumento legittimo e ampiamente supportato dalle piattaforme stesse. La domanda non è mai stata “è consentito?”, ma piuttosto “è la scelta giusta in questo caso?”.

Perché esiste questo approccio

La ragione d'essere di WebView è semplice: riutilizzare. Se la tua azienda dispone già di un sito Web o di un'applicazione Web funzionante, visualizzarlo all'interno di un'app evita di ricostruire tutto da zero per ciascuna piattaforma.

Costruire un'app veramente nativa significa, in pratica, mantenere basi di codice separate per Android e iOS, ciascuna con il proprio linguaggio, team e cicli. È costoso e richiede tempo. WebView offre una scorciatoia: scrivere l'interfaccia una volta, nelle tecnologie web, e visualizzarla ovunque.

Questa scorciatoia ha un valore reale, soprattutto per coloro che hanno bisogno di mettere qualcosa in funzione rapidamente, convalidare un'idea o mantenere contenuti che cambiano frequentemente. Ma, come ogni scorciatoia, ha un prezzo, e comprendere quel prezzo è ciò che distingue una buona decisione da una ingenua.

La tesi: WebView non è né buono né cattivo, è un compromesso

La domanda che sento spesso è "WebView è buono o cattivo?". La domanda è sbagliata. WebView è uno scambio e ciò che conta è sapere cosa stai scambiando.

Ottieni velocità di sviluppo, codice condiviso su più piattaforme e facilità di aggiornamento. Perdi, a vari livelli, prestazioni, fluidità e pieno accesso alle risorse del dispositivo. In alcuni prodotti, questo scambio è eccellente. In altri è disastroso.

Coloro che trattano WebView come una soluzione universale, "facciamo tutto in WebView per risparmiare denaro", tendono a pentirsene quando il prodotto cresce e la tiepida esperienza inizia a costare agli utenti. E chi rifiuta per principio "WebView è per dilettanti", spreca uno strumento che risolverebbe il problema in modo elegante. La maturità tecnica è sapere a cosa appartiene ciascun approccio.

Quando WebView ha senso

Esistono scenari in cui WebView è la scelta intelligente, non il ripiego.

Quando i contenuti cambiano frequentemente, termini di utilizzo, politiche, pagine di aiuto, centro notizie, non ha molto senso incorporarli nell'app e dover lanciare una nuova versione ad ogni modifica del testo. In WebView, cambi la pagina e la modifica appare immediatamente a tutti.

Quando disponi già di un'applicazione web matura e desideri arrivare rapidamente nei negozi, WebView ti consente di raggiungere il mercato con investimenti molto inferiori. Per verificare se vale la pena di un'app prima di investire pesantemente, è una strategia ragionevole.

Quando il budget e il team sono limitati e l'alternativa sarebbe non avere alcuna app, un prodotto WebView ben realizzato è meglio di niente. L’ottimale è nemico del possibile in molti contesti reali.

Quando WebView si mette in mezzo

D'altra parte, ci sono situazioni in cui insistere su WebView è un errore.

Le applicazioni la cui proposta di valore è esperienza, fluidità, animazioni, risposta istantanea al tocco, sensazione di qualità, soffrono in WebView. L'utente potrebbe non essere in grado di spiegare il motivo, ma ritiene che "è strano". Nei mercati competitivi, questa sottile differenza definisce chi resta e chi se ne va.

Funzionalità che dipendono fortemente dall'hardware, fotocamera con elaborazione in tempo reale, sensori, uso offline intensivo, integrazioni specifiche del sistema, incontrano ostacoli in WebView. In parte è possibile aggirare questo problema, ma lo sforzo per aggirarlo a volte annulla il risparmio che ha motivato la scelta.

E c'è il problema delle prestazioni sui dispositivi più modesti. In Brasile, dove gran parte della base utilizza dispositivi intermedi, un'interfaccia web pesante può rimanere bloccata dove scorrerebbe una nativa. Decidere su WebView senza pensare al dispositivo reale dell'utente è come decidere al buio.

Limiti e insidie

La trappola più comune è considerare la decisione come puramente tecnica quando si tratta di una decisione sul prodotto. La domanda giusta non è “quale tecnologia preferiamo?”, ma “di quale esperienza ha bisogno il nostro utente e quanto siamo disposti a pagare per averla?”.

Un'altra trappola è la falsità del "tutto o niente". Molti prodotti ben realizzati sono ibridi: schermi nativi critici, dove l'esperienza conta, e schermi WebView secondari, dove il riutilizzo ripaga. Non devi scegliere da che parte stare nella vita. Una buona architettura si mescola in base al valore di ogni schermo.

C'è ancora un punto di sicurezza che merita attenzione fin dall'inizio: una WebView trasporta contenuto web, e il contenuto web porta con sé le preoccupazioni del web. Il caricamento di pagine da fonti non attendibili o l'esposizione di funzionalità sensibili al contenuto caricato apre porte che un'app puramente nativa non avrebbe. Non è un motivo per evitare WebView, è un motivo per usarlo con cautela.

La scelta giusta è quella che serve all'utente

Alla fine, WebView è uno strumento e gli strumenti non hanno una morale, hanno un'applicazione. La domanda non dovrebbe mai essere se WebView sia buono, ma se serva ciò che il tuo prodotto deve fornire, il tuo budget e il tuo utente reale.

Coloro che capiscono questo smettono di discutere di tecnologia in base all’ideologia e iniziano a decidere in base al contesto. A volte la risposta è nativa, a volte è WebView, spesso è un mix intelligente dei due. La maturità è scegliere con chiarezza, sapere esattamente cosa guadagni e cosa rinunci.

Se stai decidendo l'architettura di un'applicazione e sei indeciso tra nativo, ibrido e WebView, vale la pena parlarne prima di fare una scelta che ti peserà per anni. Ho altri testi sul blog sullo sviluppo mobile e sui prodotti digitali e mi piace aiutare chi è a questo punto della decisione.