TL;DR — scelta per scenario
- Create una web app se il vostro prodotto è un SaaS B2B, uno strumento interno o un servizio basato sui contenuti dove gli utenti arrivano tramite ricerca o link condivisi. Nessuna barriera di installazione, ogni dispositivo, iterazione più semplice.
- Create una PWA se avete bisogno di una web app più la presenza sulla schermata home, notifiche push e accesso offline — senza mantenere due basi di codice native. La scelta migliore per e-commerce, media, dashboard B2C e marketplace.
- Create un’app nativa (iOS + Android) se la vostra app dipende da ARKit/ARCore, pagamenti NFC, HealthKit, localizzazione in background, machine learning on-device o integrazioni OS strette come CarPlay e Android Auto. Anche la scelta predefinita per prodotti consumer dove l’uso quotidiano attivo è il KPI centrale fin dal primo giorno.
- Per la maggior parte dei prodotti B2C nel range di budget 50.000–200.000 €, una PWA ben eseguita vi dà l’80% dell’esperienza nativa al 40–60% del costo. Non sovra-costruite senza una ragione concreta.
Web app, native, PWA: cosa significa ciascuna davvero nel 2026
Questi termini vengono spesso usati in modo improprio. Ecco una definizione precisa di ciascuno, perché la scelta tra loro dipende dalla comprensione di cosa siano davvero.
Web app
Un’applicazione web viene eseguita in una scheda del browser. Può essere un semplice sito multi-pagina, una SPA React o un’app Next.js renderizzata lato server — la caratteristica distintiva è che l’utente naviga verso un URL e il browser ospita l’esperienza. Nessuna installazione. Nessun App Store. Qualsiasi sistema operativo e dispositivo dotato di un browser moderno può utilizzarla. Questa è la scelta predefinita per SaaS B2B, strumenti interni e qualsiasi prodotto in cui l’acquisizione proviene dalla ricerca organica o da link diretti.
App nativa
Un’app nativa viene compilata per una piattaforma specifica — Swift/SwiftUI per iOS, Kotlin/Jetpack Compose per Android — o sviluppata con un framework cross-platform come React Native o Flutter che punta a entrambe. Viene distribuita tramite l’App Store o Google Play, installata sul dispositivo e dispone di pieno accesso alle API hardware, ai servizi OS e all’esecuzione in background. Il prezzo di questo potere sono due basi di codice (o una base cross-platform con moduli specifici per piattaforma), la latenza di revisione App Store e un passaggio di installazione obbligatorio che esclude il 20–50% degli utenti occasionali prima che vedano il vostro prodotto. Consultate il nostro confronto di React Native vs Flutter nel 2026 per maggiori dettagli sulla scelta del framework cross-platform.
Progressive Web App (PWA)
Una PWA è una web app che aggiunge tre elementi: un service worker (abilita la memorizzazione nella cache e il funzionamento offline), un Web App Manifest (abilita l’installazione e l’icona sulla schermata home) e HTTPS (richiesto per entrambi). Questa combinazione sblocca l’installabilità, le notifiche push e l’accesso offline — capacità che erano esclusive delle app native fino a poco tempo fa. L’utente può aggiungere una PWA alla propria schermata home direttamente da Safari o Chrome, e si apre in una finestra autonoma senza chrome del browser, con aspetto e comportamento simili a un’app nativa. La distribuite comunque come URL; il browser si occupa del resto.
Cosa le PWA possono e non possono fare su iOS & Android oggi
L’idea sbagliata più comune che sentiamo dai clienti US e UE nel 2026 è ancora “le PWA non funzionano su iPhone”. Era in gran parte vera prima del 2023. Non lo è più. Ecco lo stato attuale, piattaforma per piattaforma.
iOS (Safari 17+, 2026)
- Web Push: Supportato da iOS 16.4 (marzo 2023). Gli utenti che aggiungono una PWA alla schermata home possono ricevere notifiche push tramite lo standard Web Push. Safari su iOS (PWA non installate) richiede ancora un prompt di autorizzazione, coerentemente con le app native.
- Installazione: “Aggiungi alla schermata Home” funziona; la PWA installata si apre in una finestra autonoma con un’icona personalizzata. iOS 17+ supporta l’API BeforeInstallPrompt per i prompt di installazione in-app, anche se l’implementazione di Safari presenta alcune peculiarità rispetto a Chrome.
- Offline: I service worker funzionano completamente. Cache, background sync e IndexedDB sono tutti disponibili.
- Lacune su iOS: Nessun NFC, nessun ARKit/RealityKit, nessuna API HealthKit o Motion & Fitness, nessun audio in background in modalità schermo bloccato, nessun accoppiamento Bluetooth LE. Questi rimangono territori esclusivi delle app native su iOS nel 2026.
Android (Chrome, 2026)
Android dispone da anni del supporto PWA più completo e non ha fatto che migliorare. Web Push, installazione, offline, Bluetooth LE, NFC (sperimentale dietro un flag in Chrome), background sync e accesso al file system sono tutti disponibili. Il divario tra una PWA ben costruita e un’app React Native è genuinamente piccolo su Android per la maggior parte dei casi d’uso. Il principale elemento mancante sono le integrazioni OS profonde: Android Auto, Wear OS, slot widget e canali di notifica con categorie granulari.
Costo & time-to-market a confronto
Questi numeri si basano sui nostri dati di consegna per clienti US e UE nel 2024–2026 e sui nostri benchmark di costo per lo sviluppo di app mobile nel 2026. Configurazione del team: 1 PM, 1 designer, 2–3 ingegneri, 1 QA. Ambito: 8–12 schermate, auth, push, pagamenti, analytics.
| Dimensione | Web App | PWA | Nativo (iOS + Android) |
|---|---|---|---|
| Costo di sviluppo (range tipico) | 30.000–80.000 € | 40.000–100.000 € | 80.000–250.000 € |
| Tempo al primo build utilizzabile | 4–6 settimane | 5–8 settimane | 8–14 settimane |
| Basi di codice da mantenere | 1 | 1 | 1–2 (cross-platform o nativo) |
| Ritardi di revisione App Store | Nessuno | Nessuno | 24–72 ore per release |
| Deploy di hotfix | Immediato | Immediato (aggiornamento service worker) | OTA per JS (RN); revisione per Flutter/nativo |
| Scoperta organica App Store | Nessuna | Limitata (Google Play Trusted Web Activity) | SEO completo App Store & Play Store |
| Attrito di installazione | Zero (URL) | Basso (prompt del browser) | Alto (download App Store) |
Il delta di costo tra una web app e una PWA è piccolo — spesso solo la configurazione del service worker e del manifest, che aggiunge da una a due settimane di lavoro ingegneristico a un progetto esistente. Il delta tra una PWA e il nativo è dove si trova la vera decisione. Consultate anche la nostra pagina sul nostro servizio di sviluppo di applicazioni web per vedere come definiamo l’ambito di questi progetti.
Offline, push & funzionalità del dispositivo
La capacità offline e le notifiche push sono le due ragioni più comunemente citate per scegliere il nativo rispetto a una web app. Nel 2026, entrambe sono raggiungibili con una PWA per la maggior parte dei casi d’uso. Ecco la situazione realistica.
Accesso offline
Un service worker può pre-cachare tutte le risorse e anche le risposte API, rendendo una PWA pienamente funzionale senza connessione. Funziona ugualmente bene su iOS e Android. La sfida progettuale consiste nel decidere cosa mettere in cache e come gestire i conflitti di scrittura — un utente che invia un modulo d’ordine offline ha bisogno di background sync per accodare quella scrittura e trasmetterla al ripristino della connettività. Librerie come Workbox (di Google) rendono la scrittura del service worker molto più gestibile per le app React e Vue. Se la vostra app è un lettore di contenuti statici, un catalogo prodotti o una dashboard con dati in sola lettura, “offline” è una funzionalità da uno sprint per una PWA.
Notifiche push
Web Push (RFC 8030) è ora supportato su Chrome (Android), Safari (iOS 16.4+, macOS Ventura+) e Firefox. L’UX delle autorizzazioni è quasi identica al push nativo — gli utenti vedono un prompt a livello di sistema e possono gestire le autorizzazioni nelle impostazioni OS. I tassi di consegna nelle nostre campagne e-commerce EU 2025 hanno raggiunto in media il 78–85% di quello che il push nativo equivalente ha ottenuto, il che rientra in un range accettabile per la maggior parte dei prodotti. La principale lacuna: il push non funziona se la PWA è aperta in una scheda del browser senza essere installata sulla schermata home su iOS.
Funzionalità del dispositivo: il quadro onesto
| Funzionalità | PWA (iOS) | PWA (Android) | Nativo |
|---|---|---|---|
| Fotocamera & microfono | Sì | Sì | Sì |
| Geolocalizzazione | Solo primo piano | Solo primo piano | Background + primo piano |
| Notifiche push | Sì (PWA installata) | Sì | Sì |
| NFC | No | Sperimentale | Sì |
| ARKit / ARCore | No | No | Sì |
| Bluetooth LE | No | Sì (Web Bluetooth) | Sì |
| Autenticazione biometrica | WebAuthn / Face ID | WebAuthn / impronta digitale | Biometria completa della piattaforma |
| Acquisti in-app | No (policy Apple) | Payment Request API | Fatturazione completa App Store / Play |
Distribuzione, App Store & scoperta
La distribuzione è dove il nativo ha ancora un vantaggio strutturale che una PWA non può replicare completamente.
Scoperta sull’App Store
L’App Store e Google Play insieme guidano una quota significativa delle nuove installazioni di app, in particolare per le app consumer negli Stati Uniti. La ricerca sull’App Store rappresenta il 65–70% della scoperta di app negli USA secondo diversi studi del 2025. Una PWA non appare in questi risultati di ricerca a meno che non la si incapsuli in una Trusted Web Activity (TWA) e la si invii a Google Play — cosa che alcuni team fanno con successo. Apple non consente le submission di PWA all’App Store.
Per i prodotti B2B ed enterprise, questo è molto meno rilevante. Gli utenti trovano gli strumenti B2B tramite la ricerca Google, le conversazioni commerciali e i loop di crescita basati sul prodotto — non l’App Store. Una web app o PWA è effettivamente vantaggiosa qui perché la zero-installation accorcia il tempo dalla consapevolezza al primo valore.
L’aspetto regolamentare europeo
Il Regolamento europeo sui mercati digitali (DMA) ha imposto ad Apple di consentire la distribuzione alternativa di app nell’UE da marzo 2024. In pratica, il sideloading tramite pagine web e marketplace alternativi è ora legalmente consentito per gli utenti UE su iOS. Questo modifica il calcolo della scoperta per i prodotti focalizzati sull’UE — non richiede più un’inserzione App Store per raggiungere gli utenti iPhone con un’esperienza installata. L’implementazione pratica sta ancora maturando, ma vale la pena considerarla nella strategia di prodotto a lungo termine.
Se il vostro prodotto punta ai mercati consumer statunitensi ed europei con una forte presenza organica App Store come leva di crescita, il nativo è la scelta giusta. Se state costruendo un SaaS B2B, uno strumento interno o un prodotto dove la ricerca e i link diretti guidano l’acquisizione, una PWA copre le vostre esigenze. Leggete il nostro confronto di iOS vs Android: quale piattaforma prima per il contesto della divisione US-vs-EU delle piattaforme.
Matrice decisionale
Utilizzate questa tabella per valutare la vostra situazione. Per ogni riga, indicate quale colonna si applica. La colonna con il maggior numero di segni è probabilmente la vostra risposta — ma ponderate le righe in base alla loro importanza per il vostro prodotto specifico.
| Fattore decisionale | Web App | PWA | Nativo |
|---|---|---|---|
| Canale di acquisizione principale | Ricerca, link, vendite | Ricerca + re-engagement | Ricerca organica App Store |
| Budget | 30.000–80.000 € | 40.000–100.000 € | 80.000 €+ |
| Tipo di pubblico | B2B, interno, enterprise | B2C, e-commerce, media | Consumer, app ad alta retention |
| Notifiche push necessarie | No | Sì (standard) | Sì (controllo massimo) |
| Utilizzo offline richiesto | No | Sì (la maggior parte degli scenari) | Sì (sincronizzazione complessa) |
| API hardware (NFC, AR, BLE, GPS in background) | No | Parziale (Android) | Completo |
| Priorità time-to-market | Più veloce | Veloce | Più lento |
| Monetizzazione tramite acquisti in-app | No (usare Stripe) | Solo pagamenti web | Fatturazione completa della piattaforma |
| Agilità di deploy (velocità hotfix) | Immediato | Immediato | 24–72 ore di revisione |
Un pattern che osserviamo ripetutamente nelle startup statunitensi ed europee: costruiscono in nativo troppo presto. Una PWA lanciata al mese 3 per 60.000 € che valida il product-market fit è molto più preziosa di un’app nativa da 180.000 € lanciata al mese 9 che nessuno usa. Il nativo ha senso una volta che i dati di retention dimostrano che l’uso quotidiano attivo e la scoperta App Store valgono l’investimento — non come assunzione di partenza.
FAQ
Una PWA è meno costosa di un’app nativa?
Sì, nella maggior parte dei casi. Una PWA si basa su tecnologie web condivise, quindi si mantiene una sola base di codice invece di build iOS e Android separate. Il costo di sviluppo è tipicamente del 40–60% inferiore a quello di due app native. Se avete bisogno di un’integrazione hardware profonda o di una forte presenza App Store, l’investimento nativo si ripaga.
Una PWA può funzionare offline?
Sì. Un service worker può mettere in cache risorse, risposte API e pagine intere in modo che l’app funzioni senza connessione. Le app a forte lettura (contenuti, dashboard, cataloghi) possono essere completamente funzionali offline. Le app a forte scrittura necessitano di background sync per accodare le scritture e trasmetterle al ripristino della connettività.
Le PWA funzionano su iOS nel 2026?
Meglio che mai. Apple ha introdotto il supporto Web Push in Safari da iOS 16.4 e continua a migliorarlo. Le PWA installate su iOS ricevono notifiche push, appaiono sulla schermata home e si aprono in una finestra autonoma. Rimangono lacune — NFC, ARKit e HealthKit sono esclusivi del nativo — ma iOS non è più un ostacolo per la maggior parte dei casi d’uso PWA.
Quando si dovrebbe creare una PWA invece di un’app nativa?
Create una PWA quando il vostro pubblico è ampio e orientato all’acquisizione, quando il budget è limitato o quando i casi d’uso principali funzionano senza accesso hardware profondo. Le PWA eccellono per e-commerce, media, dashboard B2B e strumenti SaaS. Rimanete sul nativo quando avete bisogno di ARKit/ARCore, localizzazione in background, pagamenti NFC o integrazioni OS strette come CarPlay.
Una web app è sufficiente al posto di un’app mobile?
Per la maggior parte dei SaaS B2B e degli strumenti interni, una web app responsive è la prima scelta giusta — raggiunge ogni dispositivo, non richiede installazione ed è la più facile da iterare. La questione si sposta quando la retention diventa importante: notifiche push, presenza sulla schermata home e accesso offline migliorano significativamente l’uso quotidiano attivo. Se quel KPI è critico fin dal primo giorno, investite almeno in una PWA.
Posso trasformare la mia web app in una PWA in seguito?
Sì, ed è spesso la progressione giusta. Aggiungere un service worker, un Web App Manifest e HTTPS a una web app esistente può richiedere una o due settimane per un ingegnere senior. Se la vostra app è già costruita su React, Vue o Angular, Workbox rende la scrittura del service worker molto più semplice. Il requisito principale è HTTPS su ogni pagina.
Ultimo aggiornamento: 1° giugno 2026. I dati sulle capacità PWA riflettono Chrome 124, Safari 17.4 e la baseline W3C Web Platform. Il supporto delle piattaforme cambia rapidamente — verificate MDN per lo stato attuale per API.
