Progressive Web App: Quando Una PWA Batte Il Nativo

Lo sviluppo di progressive web app è l’opzione che i committenti britannici scartano nei primi dieci minuti di un progetto e riscoprono diciotto mesi dopo, quando la seconda base di codice nativa ha già divorato il budget in silenzio. La si scarta perché quasi tutto ciò che se ne scrive cade in due schieramenti, la propaganda che salta le parti che iOS rifiuta, o lo scetticismo ereditato dal 2019, quando la piattaforma davvero non poteva.

Oggi sbagliano entrambi, in modi che cambiano i conti. Safari supporta le notifiche push nelle web app della schermata Home da iOS 16.4. Chrome ha lasciato cadere il requisito del service worker per l’installazione. A ottobre 2025 il regolatore britannico ha riconosciuto ad Apple e Google uno status di mercato strategico sui loro browser e motori mobili. Intanto iOS nega ancora l’esecuzione in background, espelle i dati salvati secondo regole che non controlli, e non elencherà mai una web app sull’App Store.

È la versione che darei a un cliente indeciso tra una base di codice e tre. Ogni capacità citata qui è stata verificata a settembre 2026 sulla documentazione del fornitore, perché qui il sapere corrente è puntualmente vecchio di due anni.

Quando una PWA batte un’app nativa? Quando i tuoi utenti stanno su Android e desktop quanto su iPhone, quando l’app è una facciata verso un server, non verso il dispositivo, e quando la gente ti trova con la ricerca, non in uno store. Una PWA perde se ti servono la posizione in background, i widget della schermata Home, il Bluetooth su iPhone o la fatturazione dello store. Il risparmio è una base di codice invece di tre, nel Regno Unito circa da £40.000 a £120.000 di costruzione, e poi ogni anno un conto molto più leggero.

Che cos’è davvero una progressive web app

Il termine si usa con tale larghezza che due persone nella stessa riunione possono intendere cose diverse. La definizione tecnica è stretta e conviene attenersi a quella.

MDN descrive una progressive web app come un’app costruita con le tecnologie della piattaforma web che offre un’esperienza simile a quella di un’app specifica per piattaforma. Gira su più piattaforme da un’unica base di codice, e si può installare, usare offline e integrare con il sistema operativo.

In pratica significa tre artefatti, e un sito a cui ne manca uno è un sito con delle ambizioni, non una PWA.

Il manifest dell’app web

Il manifest è un file JSON che dice al sistema operativo come si chiama l’app, quali icone usare, quale URL aprire all’avvio e se girare dentro una cornice di browser o in modalità autonoma. Senza di esso il browser non ha niente da installare. È piccolo, è statico, ed è la parte più economica di tutto l’esercizio.

Il service worker

Un service worker è uno script che gira separatamente dalla pagina, si mette tra l’app e la rete e può rispondere alle richieste da una cache. È ciò che rende possibile il comportamento offline ed è ciò che riceve i messaggi push. È anche la parte che va storta, perché una cache mal delimitata serve codice vecchio agli utenti per settimane.

HTTPS

Service worker, push, geolocalizzazione e accesso alla fotocamera sono tutti limitati ai contesti sicuri. Su un hosting moderno questo è gratuito e automatico, quindi è un vincolo e non un costo.

Che cosa significa installata, piattaforma per piattaforma

I committenti danno per scontato che l’installazione sia un unico comportamento. Sono tre, e le differenze contano sul piano commerciale.

Android

Chrome su Android offre la cosa più vicina alla parità. L’app ottiene un’icona sulla schermata Home, una voce propria nel selettore delle app, uno spazio di archiviazione proprio, e può essere pubblicata sul Play Store tramite un contenitore. Gli inviti all’installazione si possono attivare dalla tua interfaccia una volta che il browser ha emesso l’evento relativo, quindi decidi tu il momento in cui chiedere.

iOS e iPadOS

Safari installa dal menu di condivisione, con la voce che aggiunge alla schermata Home. Non esiste alcun invito all’installazione nella pagina che tu possa attivare, nessun banner che Apple mostrerà per te, e nessun modo affidabile di rilevare che un utente lo ha fatto. Quell’unico divario di interazione è la differenza pratica più grande fra le piattaforme, ed è un problema di design più che di ingegneria: devi insegnare un gesto all’utente.

Desktop

Chrome, Edge e Safari su macOS installano tutti le web app nel dock o nella barra delle applicazioni, con una finestra propria. Il desktop è il posto in cui le PWA sono meno discusse e più sottoutilizzate, in particolare per gli strumenti interni dove l’alternativa è una build Electron che nessuno vuole mantenere.

Chrome ha cambiato le regole di installabilità e quasi nessuna guida se n’è accorta

Per anni ogni articolo ripeteva la stessa lista: manifest, icone, HTTPS e un service worker con un gestore fetch. Quest’ultimo punto non vale più per l’installazione dal menu.

Google ha rimosso il requisito di un service worker che implementa fetch per l’installazione dal menu, nella versione 108 su mobile e 112 su desktop, e ora fornisce una pagina offline predefinita ai siti che non ne offrono una propria. L’algoritmo dell’invito all’installazione vuole ancora un gestore fetch, ma l’installabilità in sé non dipende più da questo.

L’effetto è arrivato fino agli strumenti. Lighthouse ha rimosso del tutto la categoria PWA nella versione 12.0.0, pubblicata ad aprile 2024, perché quegli audit esistevano per verificare criteri che non valevano più. Se la tua pipeline di build fallisce ancora su un punteggio PWA mancante, sta verificando qualcosa che Google ha ritirato.

La lettura pratica è che installazione e capacità offline sono state disaccoppiate. Puoi rilasciare un’app installabile senza alcuna storia offline, che spesso è la prima versione giusta, e aggiungere la cache quando sai quali schermate la gente usa davvero senza segnale.

L’offline è una scelta di progetto con un costo

La parola offline nasconde una gamma enorme di ambiti. Un guscio in cache che mostra gli ultimi dati noti è una settimana di lavoro. Un’app davvero pensata offline first, che accoda le scritture, risolve i conflitti e riconcilia alla riconnessione, è un altro prodotto.

Le strategie di cache

La cache di un service worker si riduce a quattro schemi e a una decisione per tipo di risorsa. Cache first serve la copia salvata e non verifica mai, il che è giusto per i font e per gli asset di build con hash. Network first tenta il server e ripiega sulla cache, il che si adatta ai dati che devono essere aggiornati. Stale while revalidate serve la cache all’istante e aggiorna in background, la scelta abituale per i contenuti. Network only si usa per tutto ciò che non deve mai arrivare da una copia vecchia, come i pagamenti.

Sbagliare qui è il fallimento più comune che vedo nelle PWA. Una politica cache first applicata al guscio dell’applicazione servirà agli utenti di ritorno il JavaScript del mese scorso finché qualcosa non forza un aggiornamento, e le segnalazioni di bug descriveranno sintomi che nel codice attuale non esistono.

La sincronizzazione in background

Accodare le scritture offline e svuotarle quando la connettività torna è lo scopo della Background Synchronization API. MDN la classifica come a disponibilità limitata ed esplicitamente non Baseline, il che significa che non funziona in alcuni dei browser più diffusi.

Su iOS quindi il ripiego lo scrivi tu: conservi la coda in IndexedDB e la svuoti alla successiva apertura dell’app. Funziona, gli utenti lo accettano, e sono forse da tre a cinque giorni di ingegneria invece del pomeriggio che sarebbe costata l’API.

Le notifiche push decidono più progetti di qualsiasi altra cosa

Se c’è una singola capacità che affonda una proposta di PWA è questa, di solito su fatti che erano veri nel 2022.

Android e desktop

Il push web su Chrome per Android, Chrome desktop, Edge e Firefox funziona da anni grazie a Push API, Notifications API e un service worker che lavorano insieme. La consegna è gestita dal servizio push del produttore del browser, il permesso è una richiesta standard, e non c’è alcun divario significativo rispetto a un’app nativa per il caso comune di un server che manda un messaggio a un utente iscritto.

iOS e iPadOS

Apple ha aggiunto il push web in iOS e iPadOS 16.4. La condizione che vi è legata è la parte che sfugge: WebKit afferma che la web app deve essere stata aggiunta alla schermata Home, e il permesso va richiesto in risposta a un’interazione diretta dell’utente, per esempio il tocco su un pulsante di iscrizione. Il push web non funziona per un sito che sta in una scheda di Safari.

Il manifest deve impostare display su standalone o fullscreen, e le notifiche si comportano poi come quelle di qualsiasi altra app: schermata di blocco, centro notifiche, Apple Watch abbinato e controllo per singola app nelle Impostazioni. Anche i badge funzionano.

Apple ha poi aggiunto una strada più semplice. Declarative Web Push è arrivato in Safari 18.4, disponibile su iOS e iPadOS 18.4 per le web app aggiunte alla schermata Home, e mostra una notifica a partire da un payload JSON standardizzato senza che un service worker debba essere in esecuzione. Toglie lavoro. Non toglie il requisito della schermata Home.

Il divario iOS, detto con precisione

Il divario è reale ed è più piccolo della sua fama. Enunciarlo con esattezza serve più che lamentarsene o fingere che si sia chiuso.

L’espulsione dei dati salvati

WebKit espelle i dati dei siti in base al criterio del meno usato di recente, dove l’ultimo uso si misura dall’ultima interazione dell’utente o operazione di archiviazione. La sua documentazione sulla politica di archiviazione fissa una quota per origine fino al 60 % del disco per le app di navigazione e fino al 15 % per le altre app, con quote complessive rispettivamente dell'80 % e del 20 %, e conferma che una web app autonoma sulla schermata Home riceve le stesse quote del browser.

Ne discendono due cose. L’archiviazione non è il vincolo che si immagina, e l’espulsione è un rischio di tempistica più che di capienza. Tratta il dispositivo come una cache e il server come il registro, e l’espulsione smette di essere un difetto di prodotto.

L’esecuzione in background

Su iOS non esiste un equivalente di un task nativo in background. Nessun recupero periodico, nessuna posizione in background, nessuna elaborazione silenziosa ad app chiusa. Tutto ciò che deve avvenire a orario avviene sul tuo server e raggiunge il dispositivo tramite un messaggio push che l’utente vede.

Nessuna presenza sull’App Store

Una PWA non può essere pubblicata sull’App Store. Se una quota significativa dei tuoi clienti si aspetta di cercare il tuo marchio nello store e di trovarti lì, quello non è un problema di ingegneria che tu possa risolvere sul web.

I motori dei browser, il DMA e la CMA

Questa è la parte in cui la cronaca corre più delle fonti primarie, quindi conviene restare stretti su ciò che è davvero documentato.

Apple ora consente motori di browser alternativi, ed è esplicito che questo vale nella sola Unione europea, su iOS 17.4 o successivo e iPadOS 18 o successivo, tramite due abilitazioni concesse agli sviluppatori che soddisfano criteri pubblicati di sicurezza, privacy e suite di test. Apple richiede il superamento del 90 % dei Web Platform Tests e dell'80 % di Test262, il funzionamento senza JIT e la risoluzione della maggior parte delle vulnerabilità entro 30 giorni.

Per un’impresa britannica niente di tutto questo cambia qualcosa oggi. Le abilitazioni sono legate alla giurisdizione, e un utente britannico su un operatore britannico esegue WebKit qualunque icona di browser abbia toccato.

La posizione del Regno Unito si muove per conto suo. Il 22 ottobre 2025 la CMA ha riconosciuto ad Apple e Google uno status di mercato strategico sulle loro piattaforme mobili, che copre sistemi operativi, distribuzione di app, browser e motori di browser, per un periodo di cinque anni. La designazione è il potere di imporre obblighi di condotta, non gli obblighi stessi. Pianifica sulla piattaforma come si comporta oggi e tratta ogni allentamento come un guadagno.

Hardware e API di dispositivo, verificate anziché presunte

Il web non può accedere all’hardware è l’obiezione che sento più spesso, ed è quella che nel caso concreto sbaglia più spesso.

Che cosa funziona praticamente ovunque

L’accesso a fotocamera e microfono tramite getUserMedia è Baseline su MDN e funziona su tutti i browser dal 2017. Geolocalizzazione, orientamento del dispositivo, caricamento di file inclusa la cattura da fotocamera su mobile, accesso agli appunti, Web Share API su mobile e passkey via WebAuthn con Face ID o un’impronta come autenticatore funzionano tutti sui browser mobili attuali. La lettura di codici a barre e QR dal flusso della fotocamera è ordinaria amministrazione.

Per la grande maggioranza delle applicazioni aziendali quella lista è l’intero fabbisogno hardware.

Che cosa è solo Chromium, e su mobile di fatto solo Android

Web Bluetooth è documentato da Google come disponibile su ChromeOS, Chrome per Android 6.0, macOS da Chrome 56 e Windows 10 da Chrome 70, senza alcun supporto iOS elencato, e MDN lo segna a disponibilità limitata anziché Baseline. Web NFC è ancora più ristretto: Google lo documenta come disponibile su Android in Chrome 89.

Anche la File System Access API per leggere e scrivere file scelti dall’utente è territorio Chromium, benché l’origin private file system copra su tutti i browser la maggior parte del fabbisogno di archiviazione interna di un’app.

La distribuzione sugli store è una questione commerciale, non tecnica

I team discutono della distribuzione sugli store come se riguardasse le capacità. Riguarda quattro variabili commerciali, e una sola favorisce lo store senza ambiguità.

La scoperta è il vantaggio onesto. I consumatori cercano davvero nell’App Store e su Play per marchio e per categoria, e un’azienda senza presenza negli store rinuncia a quel canale. Conta enormemente per un prodotto di largo consumo con un nome riconoscibile e pochissimo per uno strumento usato da 200 dipendenti di una sola società.

La fiducia è reale e asimmetrica a seconda del pubblico. Gli utenti più anziani e meno tecnici leggono una scheda sullo store come un segnale di sicurezza. I più giovani sempre meno, e lo stesso utente userà volentieri il sito di una banca dallo stesso telefono.

Di contro, uno store aggiunge una coda di revisione tra te e i tuoi utenti, un rischio di rifiuto su regole che cambiano e una commissione su tutto ciò che vendi dentro l’app. Una PWA non ha niente di tutto questo. Pubblichi quando decidi tu, e una correzione critica raggiunge ogni utente al caricamento successivo anziché dopo una revisione.

Quanto trattengono davvero gli store

Le percentuali di commissione si muovono abbastanza spesso da rendere imprudente citarle a memoria. Queste sono le condizioni pubblicate dai fornitori stessi, verificate a settembre 2026.

Apple trattiene il 30 % come commissione standard su beni e servizi digitali. L’App Store Small Business Program la riduce al 15 % per gli sviluppatori con proventi fino a 1.000.000 USD nell’anno solare precedente, con i nuovi sviluppatori ammessi e il ritorno alla tariffa standard sulle vendite future una volta superata la soglia nell’anno.

Google pubblica una commissione di servizio per Google Play a scaglioni: 15 % sul primo milione di USD di ricavi dello sviluppatore ogni anno, 30 % oltre, e 15 % sugli abbonamenti a rinnovo automatico a prescindere dai ricavi. La stessa pagina espone una struttura diversa in vigore dal 30 giugno 2026 per SEE, Regno Unito e Stati Uniti, basata sul 10 % o sul 20 % più una commissione di fatturazione del 5 %, a seconda che l’installazione sia nuova o già esistente.

Entrambi i fornitori pubblicano in USD. Vendere un abbonamento mensile da £9,99 tramite uno store costa circa £18 all’anno per abbonato al 15 % e circa £36 al 30 %. Moltiplica per il numero dei tuoi abbonati prima di considerare lo store gratuito.

Una PWA si può comunque pubblicare su Google Play

Android ti dà entrambe le opzioni insieme, il che è una vera asimmetria nel confronto tra piattaforme e viene menzionato di rado.

Una Trusted Web Activity è un’app Android che apre la tua PWA a schermo intero senza cornice del browser, verificata come tua tramite i Digital Asset Links. Richiede Chrome su Android 72 o superiore, e l’app ospite non ha accesso ai cookie né all’archiviazione del contenuto web. In pratica è un contenitore sottile generato dal tuo manifest e inviato a Play come qualsiasi altra app.

Su Android quindi la scelta non è store o web. Pubblichi la PWA, la incarti e ottieni anche la scheda sullo store, dalla stessa base di codice, per qualche giorno di lavoro di confezionamento e la quota annuale dell’account sviluppatore.

Su iOS non c’è un equivalente. Le linee guida di revisione di Apple trattano da tempo un contenitore attorno a un sito come insufficiente di per sé, quindi la strada dello store iOS significa costruire qualcosa di davvero nativo. Quell’asimmetria, più di ogni divario di API, dà forma alla tabella dei costi qui sotto.

Costo dello sviluppo di una progressive web app contro due basi di codice native

Il confronto che si fa di solito è il costo di costruzione, che è la metà più piccola. Quello che decide l’esito è il costo totale su tre anni, perché la spesa del nativo è ricorrente.

Leggi quelle cifre come fasce di agenzia britannica per un’app aziendale di media complessità, non come un preventivo. Una PWA di questa forma è di norma una squadra di due o tre ingegneri per tre o cinque mesi. Due basi di codice native più una presenza web sono tre squadre, tre processi di rilascio e tre serie di aggiornamenti di piattaforma ogni anno.

Il divario tra la prima e la terza riga, all’incirca da £75.000 a £175.000 in costruzione e da £27.000 a £60.000 all’anno dopo, è ciò che compri quando compri il nativo. A volte sono soldi ben spesi. Dovrebbe essere una decisione, non un automatismo. Le nostre pagine su sviluppo di siti web e sviluppo software spiegano come inquadriamo entrambe le strade.

Dove finiscono davvero i soldi della manutenzione

Il costo di costruzione si negozia. Il costo di manutenzione si scopre, ed è lì che i progetti a più basi di codice falliscono in silenzio anziché con fragore.

Le piattaforme native ti impongono lavoro ogni anno. Le nuove versioni maggiori del sistema deprecano API, firma e provisioning cambiano, i livelli minimi di SDK salgono, e le politiche degli store aggiungono requisiti come i manifesti sulla privacy e le dichiarazioni sulla sicurezza dei dati. Niente di tutto ciò rilascia una funzionalità. Su due piattaforme lo paghi due volte, secondo un calendario deciso da altri.

Poi c’è la deriva. Due basi di codice che implementano la stessa funzionalità divergono, e la divergenza affiora come ticket di assistenza che si riproducono su una sola piattaforma. Ogni decisione di prodotto va presa due volte e poi riconciliata, e il costo di coordinamento non compare su nessuna fattura.

Una PWA sostituisce tutto questo con l’evoluzione dei browser, che è continua, retrocompatibile e quasi mai rompe codice funzionante. Il lavoro ricorrente sono i tuoi aggiornamenti di dipendenze, le patch di sicurezza e l’hosting, cioè la stessa manutenzione di cui ogni applicazione web su misura ha già bisogno.

Il confronto che conta non è tra due cifre su una proposta. È una squadra contro tre, ogni anno, finché il prodotto vive.

Prestazioni e Core Web Vitals per una PWA

Un’app installata viene giudicata rispetto al nativo, quindi l’asticella delle prestazioni è più alta che per un sito, non più bassa. La buona notizia è che le metriche sono pubbliche e le soglie sono fisse.

I Core Web Vitals sono attualmente tre metriche, ciascuna valutata al 75° percentile dei caricamenti di pagina e distinta tra mobile e desktop. Largest Contentful Paint è buono a 2,5 secondi o meno e scadente oltre 4,0. Interaction to Next Paint, che ha sostituito First Input Delay quando è diventato stabile nel 2024, è buono a 200 millisecondi o meno e scadente oltre 500. Cumulative Layout Shift è buono a 0,1 o meno e scadente oltre 0,25.

Qui una PWA ha un vantaggio strutturale. Un service worker che serve il guscio dalla cache rende le visite ripetute quasi istantanee, che è esattamente lo schema prodotto da un’app installata, per cui i dati reali di una PWA installata di solito appaiono migliori dello stesso codice visitato a freddo in un browser.

Ha anche un rischio strutturale. I framework a pagina singola spostano il lavoro sul client, e INP è la metrica che lo punisce. Se stai già combattendo con questi numeri, la nostra guida per superare i Core Web Vitals affronta la diagnosi più a fondo di quanto possa fare questo articolo.

La SEO è il vantaggio che nessuno mette a bilancio

Questo è l’argomento che metterei per primo nella maggior parte dei casi commerciali, e nel confronto viene quasi sempre lasciato fuori del tutto.

Una PWA è un sito web. Ogni schermata ha un URL, ogni URL può essere scansionato, indicizzato, linkato e condiviso, e ognuno può posizionarsi. Un’app nativa non ha niente di tutto ciò. Le schede degli store vengono indicizzate in superficie e si posizionano dentro un giardino recintato su segnali del tutto diversi, e i contenuti dentro l’app sono invisibili alla ricerca.

La conseguenza si accumula. La spesa di marketing su un’app nativa compra installazioni e finisce il giorno in cui la spesa finisce. La stessa spesa su contenuti e qualità tecnica di una PWA compra una pagina che continua a posizionarsi. Su tre anni quella differenza supera spesso l’intero costo di costruzione dell’una o dell’altra strada.

Ripaga solo se l’implementazione è scansionabile, ed è lì che sbagliano le app renderizzate lato client: rendere tutto in JavaScript con un solo URL e senza HTML generato dal server butta via il vantaggio per intero. Il rendering lato server o il prerendering delle rotte indicizzabili è il rimedio, e un audit SEO tecnico prima del lancio costa molto meno che scoprire dopo sei mesi che non si è indicizzato niente.

I requisiti che squalificano

La decisione è più facile come elenco di veti che come elenco di vantaggi, perché i veti sono oggettivi.

Ti serve il nativo se uno dei punti seguenti è un requisito vero e non un desiderio. Il tracciamento della posizione in background ad app chiusa. I widget della schermata Home, le app per orologio, o l’integrazione con CarPlay e Android Auto. Il Bluetooth o l’NFC su iPhone. HealthKit, Apple Pay dentro l’app, o qualsiasi integrazione profonda con il sistema che Apple non ha aperto al web. La fatturazione dello store per beni digitali, dove la politica dello store lo impone. Il calcolo pesante e prolungato, come l’elaborazione video in tempo reale o il rendering 3D a frame rate nativi. La presenza sull’App Store come requisito di marketing da cui la tua attività dipende davvero.

Se nessuno di questi punti si applica, una PWA è molto probabilmente la risposta giusta, e l’onere della prova sta in capo a chi vuole tre basi di codice.

Altre due considerazioni la inclinano ancora di più. Se i tuoi utenti stanno soprattutto su desktop o Android, i divari di iOS toccano una minoranza del pubblico. E se l’app è una facciata verso il tuo server e non verso il dispositivo, cosa che descrive quasi tutto il software aziendale, le capacità del dispositivo contano appena.

Scenario uno: assistenza sul campo per un facility contractor

Duecento tecnici, schede di intervento, foto dei lavori conclusi, acquisizione della firma, segnale a singhiozzo in locali tecnici e scantinati. È il caso che si presume richieda il nativo, ed è quello in cui una PWA vince nel modo più netto.

Ogni requisito è coperto. La fotocamera funziona con getUserMedia. Le firme sono un elemento canvas. I dati degli interventi si mettono in cache in IndexedDB e la coda di scrittura si svuota alla riconnessione, scritta a mano perché Background Sync non è affidabile su tutti i browser. Gli avvisi di dispacciamento partono come push web, che funziona su Android e su iOS per i tecnici che hanno aggiunto l’app alla schermata Home, e l’installazione è un punto da cinque minuti nel corso di inserimento anziché un problema di acquisizione utenti.

Non c’è alcun requisito di scoperta negli store, perché gli utenti sono dipendenti. Non c’è fatturazione, quindi la commissione è irrilevante. I dispositivi sono misti Android e iOS, che è esattamente il caso che punisce di più due basi di codice native.

Costruisci una PWA per forse da £45.000 a £70.000 invece di due app native da £120.000 a £200.000, rilascia le correzioni lo stesso pomeriggio anziché passando da una revisione, e spendi la differenza sul backend di dispacciamento, che è ciò che determina davvero se la cosa funziona.

Scenario due: una catena di saloni che vuole prenotazioni e promemoria

Quattordici filiali, rivolte al consumatore, prenotazione degli appuntamenti, promemoria, un programma fedeltà, pagamenti presi alla cassa e non nell’app. L’istinto dice app nativa perché i concorrenti ne hanno una.

L’elenco dei requisiti non ha niente di notevole: moduli di prenotazione, un calendario, promemoria, un’area account. I promemoria sono l’unico punto interessante, e in questo mercato sono serviti meglio da SMS ed e-mail che dal push, perché una cliente che prenota due volte l’anno non avrà installato nulla.

La scoperta è il fattore decisivo, e favorisce il web in modo netto. La gente trova i saloni con la ricerca e con le mappe, non sfogliando uno store di app, quindi le pagine che descrivono i servizi e raccolgono le prenotazioni devono posizionarsi. Un’app nativa è del tutto invisibile a tutto questo. Il costo del sito stesso è la vera voce di budget, con lo strato app aggiunto sopra come installabilità.

Costruisci bene il sito di prenotazione, rendilo installabile perché le clienti abituali possano tenerlo sulla schermata Home, e aggiungi il push web per la minoranza che lo accetta. Una realizzazione nativa qui spende £80.000 o più per raggiungere meno clienti di quanti il sito ne raggiunga già.

Scenario tre: un prodotto fitness in abbonamento

Allenamenti guidati, contenuti video, un’integrazione con un dispositivo indossabile, £12,99 al mese, vendita diretta al consumatore, crescita finanziata dall’acquisizione a pagamento. Questo scenario va nella direzione opposta, e vale la pena mostrare perché.

La scoperta negli store conta qui, perché il fitness è una categoria che si sfoglia e una scheda è un vero canale di acquisizione. L’integrazione con l’indossabile significa HealthKit, che il web non può raggiungere. L’audio in background e il comportamento dello schermo durante un allenamento sono migliori sul nativo. Il download di video per l’uso offline su larga scala è fattibile sul web ma non comodo.

La fatturazione è la parte interessante. La commissione dello store su £12,99 al mese è circa £23 all’anno per abbonato al 15 % e £47 al 30 %, che con 20.000 abbonati fa da £460.000 a £940.000 all’anno. È un argomento forte per incassare sul web e trattare l’app come un client, cosa che diversi grandi prodotti in abbonamento ora fanno.

La risposta sono app native per il prodotto e una PWA o una normale web app per iscrizione, fatturazione e content marketing. Entrambe esistono, e la divisione è deliberata anziché accidentale.

Come decidere in un pomeriggio

La decisione non ha bisogno di una fase di discovery. Ha bisogno di quattro risposte, messe per iscritto.

Primo, elenca le capacità del dispositivo di cui hai davvero bisogno, poi verifica ciascuna sulla documentazione del fornitore anziché su un riassunto. Quasi tutti gli elenchi si accorciano parecchio a questo passaggio. Secondo, stabilisci da dove arrivano i tuoi utenti: se la risposta è la ricerca, il web ha già il vantaggio, e se è la navigazione negli store, non ce l’ha.

Terzo, quota tutte e tre le strade su tre anni anziché su uno, incluse le cifre di manutenzione qui sopra, e includi la commissione dello store su tutto ciò che intendi vendere. Quarto, sii onesto sulla tua squadra. Una base di codice mantenuta da tre ingegneri rilascia più di tre basi di codice mantenute da tre ingegneri, ogni volta.

Se dopo tutto questo la risposta resta ambigua, costruisci prima la PWA. È l’opzione più economica da invertire. Passare da una PWA al nativo più avanti significa scrivere i client nativi contro un’API che esiste già ed è collaudata, mentre fare il contrario significa ricominciare da capo. Quell’asimmetria vale più della maggior parte dei confronti di funzionalità qui sopra.

Che cosa comporta per te

Lo sviluppo di progressive web app non è un compromesso per chi non può permettersi il nativo, e non è nemmeno una risposta universale. È l’architettura giusta per una categoria definita e ampia di prodotti: software aziendale, strumenti interni, sistemi di prenotazione e di account, prodotti di contenuto e tutto ciò i cui clienti arrivano dalla ricerca.

I divari di iOS sono reali, specifici e per lo più aggirabili anziché fatali. Il push funziona se l’utente installa. L’archiviazione è generosa ma espellibile. L’esecuzione in background non esiste e comunque il suo posto è sul tuo server. Bluetooth e NFC non funzionano su iPhone, e nessuna quantità di ingegneria lo cambia.

Mecanik costruisce entrambe le strade e ti dirà quando la risposta è il nativo. Se vuoi il confronto fatto sui tuoi requisiti reali anziché su un elenco generico, le pagine su sviluppo di siti web e sviluppo software descrivono come lo inquadriamo, e la nostra guida per costruire una web app nel 2026 tratta le scelte di stack che ne discendono.

Domande frequenti

Che cos’è una progressive web app? Una progressive web app è un’app costruita con tecnologie web che si comporta come un’app specifica per piattaforma. Tecnicamente è un’applicazione web servita su HTTPS con un manifest che ne descrive nome, icone e comportamento all’avvio, più un service worker capace di servire richieste da una cache e di ricevere messaggi push. MDN la definisce come software che gira su più piattaforme da un’unica base di codice restando installabile e utilizzabile offline.

Una PWA può inviare notifiche push su iPhone? Sì, a una condizione. Apple ha aggiunto il push web in iOS e iPadOS 16.4, ma WebKit richiede che la web app sia stata prima aggiunta alla schermata Home e che il permesso sia richiesto in risposta a un’interazione diretta dell’utente, per esempio il tocco su un pulsante di iscrizione. Il push non funziona per un sito che gira in una scheda di Safari. Declarative Web Push, aggiunto in iOS e iPadOS 18.4, semplifica l’implementazione ma mantiene lo stesso requisito della schermata Home.

Quanto costa lo sviluppo di una progressive web app nel Regno Unito? Per un’app aziendale di media complessità metti in conto da £35.000 a £75.000 per costruire un’unica base di codice PWA e da £8.000 a £20.000 all’anno per mantenerla. La strada nativa comparabile, con app iOS e Android separate più un sito vetrina, va da £110.000 a £250.000 di costruzione e da £35.000 a £80.000 all’anno dopo. Sono fasce di agenzia britannica e non preventivi, e la differenza ricorrente di solito conta più di quella di costruzione.

Si può pubblicare una PWA sull’App Store o su Google Play? Su Google Play sì, sull’App Store no. Su Android una Trusted Web Activity avvolge la tua PWA in un guscio nativo sottile verificato tramite i Digital Asset Links, così la stessa base di codice ottiene una scheda su Play con qualche giorno di lavoro di confezionamento. Apple non ha un equivalente e le sue linee guida di revisione trattano un contenitore attorno a un sito come insufficiente, quindi una presenza sull’App Store significa costruire qualcosa di davvero nativo.

Quando conviene scegliere un’app nativa invece di una PWA? Scegli il nativo quando ti serve il tracciamento della posizione in background ad app chiusa, i widget della schermata Home, le integrazioni con orologio o automobile, il Bluetooth o l’NFC su iPhone, HealthKit o Apple Pay dentro l’app, il calcolo pesante e prolungato come l’elaborazione video in tempo reale, oppure la presenza sull’App Store come vero canale di acquisizione. Se nessuno di questi casi si applica, una PWA è molto probabilmente giusta e l’onere della prova sta in capo a chi vuole mantenere tre basi di codice.