Nel 2015 Alex Russell, ingegnere del team Chrome, pubblica il post in cui compare per la prima volta l’espressione Progressive Web App: siti che si comportano come applicazioni, si installano dal browser e non passano da nessuno store.
Dieci anni dopo App Store e Google Play distribuiscono insieme oltre 3,5 milioni di applicazioni e le banche, le compagnie aeree e le piattaforme di sport in tempo reale continuano a pretendere il download.
Le app installate non sono scomparse per una serie di limiti tecnici precisi del browser, che conviene conoscere prima di decidere come costruire il proprio progetto.
Le differenze tecniche tra app installate e web app
Un’app nativa è un pacchetto compilato per un sistema operativo specifico, scritto in Swift o Kotlin, che parla direttamente con il telefono attraverso le API di iOS o Android.
Una web app è un sito che gira dentro il browser e usa tecnologie standard, HTML, CSS e JavaScript, con un componente in più chiamato service worker, uno script che resta attivo in background e permette di salvare pagine offline, ricevere notifiche e aggiornare i contenuti senza che l’utente faccia nulla.
In mezzo esistono le app ibride, che impacchettano una web app dentro un contenitore nativo per poterla pubblicare negli store, e i framework come React Native o Flutter, che scrivono il programma una volta sola e lo compilano per entrambe le piattaforme.
La distinzione tra i tre modelli riguarda soprattutto due cose, fino a che punto arrivano a toccare l’hardware del telefono e che controllo lasciano allo sviluppatore su prestazioni e distribuzione.
I servizi che funzionano meglio nel browser
Twitter lancia Twitter Lite nel 2017 come Progressive Web App e dichiara un consumo di dati inferiore del 70 per cento rispetto all’app nativa, con un peso di installazione di poche centinaia di kilobyte.
Nello stesso anno Starbucks pubblica una PWA per gli ordini che occupa 233 kilobyte contro i 148 megabyte della versione iOS, e Uber apre m.uber.com per chi ha un telefono vecchio o una connessione 2G.
Cataloghi, testate giornalistiche, e-commerce con ordini saltuari e uffici pubblici si spostano sul browser perché il costo di far scaricare un’app a chi la userà due volte l’anno non si ripaga.
Twitter, Starbucks e Uber hanno in comune la frequenza d’uso. Per uno strumento consultato di rado l’installazione è un ostacolo, e un link condiviso in chat porta più utenti di qualsiasi scheda dello store.
Con un uso quotidiano e tempi di risposta stretti valgono altri criteri.
Aggiornamenti in tempo reale e connessioni persistenti
Un titolo quotato a Piazza Affari, il punteggio di Juventus-Inter o la posizione di un corriere Amazon cambiano di continuo, e l’app deve mostrarli senza interrogare il server ogni volta.
La tecnica si chiama WebSocket, un canale che resta aperto tra telefono e server e spinge i dati appena cambiano, la stessa logica che regge la tecnologia dietro la diretta nello streaming video.
Nel browser il canale resta vivo finché la scheda è in primo piano; se l’utente passa a un’altra app, il sistema operativo può sospenderlo per risparmiare batteria, e al ritorno i dati vanno riallineati.
Secondo quanto scrive Denis Michelotti su Sitiscommesse, il betting in mobilità è il caso in cui la differenza tra un’app installata e una web app risulta più evidente.
Il 69,7 per cento dei giocatori italiani dichiara di preferire lo smartphone al computer (Bonafide Research, 2024), e su quel pubblico un ritardo di mezzo secondo nell’aggiornamento di una quota equivale a una puntata persa.
Per questo gli operatori tengono l’app nativa anche quando il sito mobile è impeccabile, e lo stesso ragionamento vale per chi vende biglietti last minute o per chi gestisce la ricarica di un monopattino.
Su iPhone e Android lo scorrimento è l’altro fattore. Un’app nativa disegna le liste con componenti del sistema operativo e tiene stabili i 60 fotogrammi anche con migliaia di righe, mentre il browser deve calcolare il layout di ogni elemento a ogni movimento del dito.
Su una lista di 2.000 voci che si aggiornano in continuazione la differenza è misurabile, e su un telefono di fascia media è evidente.
Autenticazione biometrica e notifiche push
Intesa Sanpaolo, UniCredit e le altre app bancarie restano native per una ragione che non ha niente a che vedere con la velocità.
L’autenticazione con il volto o con l’impronta passa dal Secure Enclave di Apple o dal Trusted Execution Environment di Android, aree del processore isolate dal resto del sistema, e il browser può domandare una conferma biometrica ma non può conservare chiavi al loro interno né firmare operazioni con la stessa garanzia.
Android concede le notifiche push alle web app dal 2015, Apple le ha aperte a Safari su iPhone solo con iOS 16.4, nel marzo 2023, e a condizione che l’utente abbia aggiunto il sito alla schermata Home.
Una notifica nativa raggiunge il telefono bloccato e può svegliare l’app per scaricare dati in anticipo; una notifica web arriva, ma nel momento in cui l’utente la tocca deve ancora caricare tutto.
Il ritardo conta poco per un promemoria di volo e molto per un avviso di accesso sospetto.
Commissioni e revisione degli store
Pubblicare su App Store e Google Play significa accettare le regole dei due negozi.
I due store trattengono il 30 per cento sugli acquisti in-app, ridotto al 15 per cento per chi incassa meno di un milione di dollari l’anno, e ogni aggiornamento passa da una revisione che può durare da poche ore a diversi giorni.
Dal marzo 2024, con iOS 17.4, l’Unione Europea ha imposto ad Apple di ammettere store alternativi e pagamenti esterni in base al Digital Markets Act, ma le condizioni economiche restano complesse e la maggior parte degli sviluppatori europei continua a usare l’App Store come prima.
Una PWA come quella di Starbucks non prevede commissioni sugli store, si aggiorna appena i file vengono caricati sul server e non deve passare attraverso un processo di revisione esterno.
Lo svantaggio riguarda la visibilità, dato che chi cerca un servizio sul telefono apre lo store prima del motore di ricerca, e un’icona sulla schermata Home viene aperta più spesso di un segnalibro.
Le app ibride e i framework multipiattaforma
Instagram, Facebook e molte app bancarie europee usano da anni un approccio misto, con le schermate critiche scritte in codice nativo e le sezioni informative caricate come pagine web all’interno dell’app.
React Native, nato in Facebook nel 2015, e Flutter, uscito nel 2018, permettono di condividere fino al 90 per cento del codice tra iOS e Android mantenendo l’accesso all’hardware, e strumenti come Capacitor impacchettano una web app esistente per gli store in pochi giorni.
Flutter e React Native funzionano bene se il team è piccolo e il prodotto non richiede un uso intensivo del processore.
Le app che devono elaborare video, gestire mappe in 3D o mantenere aperti più flussi di dati contemporaneamente ricorrono ancora spesso al nativo puro, perché lo strato intermedio richiede memoria e introduce tempi di elaborazione aggiuntivi.
Come scegliere tra app nativa e web app
Bastano quattro domande per orientare la decisione: quante volte l’utente aprirà l’applicazione, ogni giorno o qualche volta l’anno; se servono componenti del telefono che il browser non espone, come biometria, Bluetooth, esecuzione in background o notifiche affidabili su iPhone; se i dati devono essere disponibili anche senza rete, cosa che il service worker copre solo in parte; se il modello di business regge una commissione del 15 o del 30 per cento sulle vendite digitali.
Chi risponde “raramente, nessuna funzione speciale, sempre connesso, nessun acquisto in-app” ha tutto l’interesse a partire dal browser, magari con una PWA installabile che costa una frazione dello sviluppo nativo.
Chi risponde all’opposto ha bisogno di un’app nativa, e può usare la web app come vetrina per portare le persone nello store.
Conclusione
Nel 2026 la scelta tra app native e web app dipende dalla frequenza d’uso e dalle funzioni richieste.
Un sito consultato ogni tanto funziona bene nel browser; un servizio che deve reagire all’istante, proteggere credenziali o lavorare a schermo spento continua a passare dal download, e nessuna evoluzione degli standard web ha ancora chiuso quel divario.
FAQ sulle applicazioni installate e le PWA
Una PWA può stare negli store?
Google Play accetta dal 2019 le PWA impacchettate come Trusted Web Activity, quindi sì; su App Store serve un contenitore nativo, per esempio tramite Capacitor, e la revisione di Apple richiede che l’app offra funzioni oltre il semplice sito.
Le web app funzionano offline?
Da Safari 11.1, nel 2018, tutti i browser principali supportano il service worker, che può salvare schermate, immagini e dati già visti e mostrarli senza rete, quindi in parte sì, ma non può eseguire operazioni in background per lunghi periodi né sincronizzare grandi quantità di dati quando il telefono è bloccato.
Quanto costa in più sviluppare un’app nativa?
Dipende dal progetto, ma mantenere due versioni separate per iOS e Android raddoppia buona parte del lavoro di sviluppo e di test.
I framework multipiattaforma riducono il divario, e la scelta va fatta sui requisiti tecnici, non sul preventivo iniziale.
Le PWA possono inviare notifiche push su iPhone?
Sì, da iOS 16.4 le web app aggiunte alla schermata Home possono ricevere notifiche push.
Restano però differenze rispetto alle app native, soprattutto nella gestione delle attività in background e nell’integrazione con alcune funzioni del sistema operativo.
Quando conviene scegliere un’app nativa?
Un’app nativa è indicata quando servono prestazioni elevate, accesso più profondo all’hardware del dispositivo, autenticazione avanzata, attività in background affidabili o un’esperienza d’uso molto frequente e reattiva.
Lascia un commento