App nativa o web app? Quando basta una PWA

Immagini una riunione in cui qualcuno dice: «Ci serve un'app». Qualche settimana dopo l'azienda sta già confrontando i preventivi per due app native, benché nessuno si sia chiesto con quale frequenza le persone apriranno il prodotto né se abbiano bisogno di qualcosa che il browser non è in grado di fare.

La scelta della piattaforma dipende da quanto spesso e dove le persone useranno il prodotto, da che cosa deve saper fare il dispositivo e da quanto costa mantenere più versioni in parallelo. Scegliere app nativa o web app, quindi, non è una questione di gusti del fornitore.

«Ci serve un'app» è un riflesso, non un brief

La richiesta di un'app nasce spesso guardando la concorrenza e dà un nome alla soluzione prima ancora di averlo dato al problema. L'ordine sensato è quello inverso: prima capire l'azienda e il processo, eliminare i passaggi superflui, poi progettare l'esperienza utente e solo alla fine scegliere la tecnologia. Nel modello a livelli dell'azienda, la scelta della piattaforma appartiene al livello Experience: determina dove la persona incontra il prodotto e quanto sforzo le richiede.

Le opzioni spiegate alla direzione aziendale

L'app nativa è un software scritto direttamente per un singolo sistema operativo, separatamente per iOS e per Android. Questo significa due codebase, cioè due insiemi di codice sorgente mantenuti in modo indipendente.
L'app multipiattaforma nasce dallo sviluppo multipiattaforma: da un'unica codebase si ottiene l'app sia per iOS sia per Android. Un esempio è Flutter di Google, che secondo le proprie FAQ (aggiornate il 14 settembre 2026) permette di riunire gli sviluppatori in un solo team e di allineare i rilasci; si tratta però di un'affermazione del produttore. Flutter richiama il codice nativo tramite i cosiddetti platform channels, quindi le competenze su iOS e Android non spariscono del tutto dal team.
La web app funziona nel browser senza installazione. Nel corso Learn PWA (aggiornato il 20 settembre 2024) Google osserva che con il web vengono meno la pacchettizzazione, i controlli aggiuntivi sui contenuti e i ritardi negli aggiornamenti.
La PWA, progressive web app, è una web app installabile. Secondo lo stesso corso, una volta installata ha un'icona sulla schermata Home e una finestra propria, senza l'interfaccia del browser. La modalità offline, cioè il funzionamento senza rete, è affidata al service worker: uno script che il browser esegue all'occorrenza e che, secondo la documentazione MDN di Mozilla, può salvare i file dell'app in una cache locale.

I criteri che decidono prima della tecnologia

Frequenza d'uso. Uno strumento aperto più volte al giorno merita un'icona sulla schermata Home, ma questa la offre anche una PWA. Per un servizio che il cliente usa qualche volta all'anno, l'installazione aggiunge solo un passaggio prima del primo utilizzo.
Contesto. Il tecnico in uno scantinato senza segnale, il magazziniere con i guanti, l'autista in auto. Per la modalità offline occorre definire con precisione che cosa deve succedere senza rete: lettura, scrittura, sincronizzazione e anche risoluzione dei conflitti tra modifiche.
Funzionalità del dispositivo. Fotocamera, localizzazione in background, Bluetooth, NFC, notifiche, biometria. Verifichi il supporto di quelle di cui non può fare a meno sui dispositivi di destinazione, con riferimento alla data della decisione, perché cambia nel tempo. Attenzione al lavoro in background: MDN (13 settembre 2026) precisa che il service worker non è sempre in esecuzione e che Chrome probabilmente lo termina, per esempio, dopo 30 secondi di inattività.
Distribuzione. Una web app si apre con un link o un codice QR. Le app native, secondo Google, sui dispositivi mobili si installano soprattutto dagli store, che stabiliscono chi può pubblicare e che cosa.
Aggiornamenti. Secondo Google, un aggiornamento nativo richiede un nuovo pacchetto, la firma, l'approvazione e l'installazione. Finché l'utente non lo installa, il Suo server deve gestire anche la versione precedente.
Destinatari. Il dipendente lo strumento lo riceve, il cliente va convinto: con i clienti ogni passaggio in più può costare una parte delle conversioni.

I costi che il primo preventivo non mostra

Sviluppo e codebase. Due app native e il web sono tre codebase. Ogni funzionalità va programmata, testata e rilasciata tre volte, con il tempo le versioni divergono e aumentano sia gli errori sia il costo dell'assistenza.
L'approvazione su App Store è il controllo con cui Apple valuta ogni app e ogni aggiornamento prima della pubblicazione. Apple stessa dichiara di esaminare in media il 90% degli invii in meno di 24 ore. Più dell'attesa, però, conta il fatto che la decisione sulla pubblicazione non spetta a Lei: in base al punto 2.1 delle App Review Guidelines (aggiornate l'8 giugno 2026), Apple respinge le app incomplete e quelle che vanno in crash.
Commissioni degli store. Le commissioni riguardano la vendita di contenuti e servizi digitali e incidono direttamente sul margine. Il punto 3.1.1 delle stesse linee guida richiede l'acquisto in-app (In-App Purchase) per sbloccare funzionalità, contenuti o abbonamenti, con eccezioni regionali. I beni fisici e i servizi fruiti al di fuori dell'app, invece, devono essere pagati con altri sistemi. Per le app distribuite nell'UE, Apple indica nelle condizioni in vigore dal 1° ottobre 2026 una commissione del 26% sulle vendite tramite In-App Purchase e del 15% per i membri dell'App Store Small Business Program. Google dichiara che il 97% degli sviluppatori distribuisce app su Google Play senza pagare commissioni e, per le transazioni nel SEE dal 30 giugno 2026, applica sul primo milione di USD di ricavi annui il 10% più una commissione del 5% per il proprio sistema di pagamento.
Aggiornamenti dei sistemi operativi. Ogni cambiamento importante di iOS o Android è un motivo per testare l'app e spesso per ripubblicarla; con due app native, due volte. Google considera obbligatori i test sulle nuove versioni di sistemi operativi e browser anche per le PWA.

Le PWA nella realtà: cosa sanno fare oggi e cosa no, soprattutto su iOS

Installazione. Secondo MDN (7 settembre 2026), il browser propone l'installazione solo per un sito dotato di manifest, cioè il file che descrive l'app, e di una connessione sicura HTTPS. Il service worker non è un requisito, quindi la modalità offline va progettata deliberatamente. Su Android installano le PWA come app a tutti gli effetti solo Chrome, sui dispositivi con Google Mobile Services, e Samsung Internet, sui dispositivi Samsung. Gli altri browser creano soltanto un collegamento che apre il sito nel browser.
iPhone e iPad. Su iOS 16.4 e versioni successive, secondo MDN, la PWA si installa dal menu Condividi. iOS non supporta un pulsante di installazione personalizzato all'interno del sito, quindi l'utente va guidato. In iOS 26 e iPadOS 26, secondo il blog WebKit (15 settembre 2025), ogni sito aggiunto alla schermata Home si apre per impostazione predefinita come web app, anche senza manifest.
Le notifiche push sono messaggi inviati dal server che il dispositivo mostra anche quando l'app non è in esecuzione. Sul blog WebKit, il 16 febbraio 2023, Apple ha annunciato che iOS e iPadOS 16.4 introducono il Web Push per le web app aggiunte alla schermata Home: stando a tale annuncio, il push è quindi legato a questo passaggio. Sempre secondo l'annuncio, l'autorizzazione si può richiedere solo dopo un'azione diretta dell'utente.
Attività in background. Background Sync, se il browser lo supporta, tenta di completare un'operazione quando la connessione torna disponibile. Secondo MDN (13 settembre 2026), tuttavia, l'operazione si può avviare solo con l'app aperta e i browser limitano sia il numero sia la durata dei tentativi. Il push silenzioso, senza notifica visibile, secondo la stessa fonte non è supportato da alcun browser.
Store. Secondo MDN una PWA si può anche pacchettizzare per Google Play o App Store, ma il punto 4.2 delle linee guida di Apple richiede più di un sito web reimpacchettato.
Rischio normativo. Secondo TechCrunch (1° marzo 2024), nella beta di iOS 17.4 Apple aveva ridotto le PWA nell'UE a semplici collegamenti, richiamando il regolamento sui mercati digitali (DMA), per poi fare marcia indietro dopo le critiche. Il documento di lavoro dei servizi della Commissione europea del 28 aprile 2026 riporta che Apple ha continuato a supportare le web app sulla schermata Home.

La nostra lettura: su iOS la PWA è un'opzione praticabile, ma i suoi confini li stabilisce Apple, così come i confini di un'app nativa li stabiliscono le regole dello store. Il rischio di piattaforma riguarda ogni opzione.

Strumenti interni e app per i clienti a confronto

A differenza del cliente, il dipendente arriva allo strumento interno attraverso il processo: un link nell'intranet, il login aziendale, un segnalibro nel browser. Qui cade l'argomento secondo cui l'app deve stare nello store perché le persone la trovino.

Gli strumenti interni gestiscono spesso moduli, approvazioni e report senza esigenze particolari in fatto di hardware. Fanno eccezione il magazzino, il lavoro sul campo o la produzione, dove il dispositivo è uno strumento di lavoro. Una modifica sul web, inoltre, arriva alle persone senza che debbano installare un aggiornamento. Nessuna piattaforma, però, salva uno strumento che complica il lavoro alle persone, come abbiamo scritto nell'articolo Il sistema più caro è quello che i Suoi collaboratori non usano.

Scenari esemplificativi

Gli scenari che seguono sono ipotetici e servono solo a illustrare il ragionamento.

Il tecnico sul campo

I tecnici di un'azienda di assistenza registrano gli interventi anche in assenza di segnale. Se bastano la registrazione offline e la sincronizzazione al ritorno della rete, la PWA è un progetto pilota ragionevole e i test sui telefoni dei tecnici mostreranno se la sincronizzazione è affidabile. Se invece l'azienda ha bisogno della posizione aggiornata per tutto il turno o del collegamento via Bluetooth a uno strumento di misura, la scelta più sicura è un'app multipiattaforma o nativa.

E-commerce

Il cliente acquista qualche volta all'anno e arriva da un motore di ricerca o da una newsletter. Un'app metterebbe installazione e login prima dell'acquisto. Rende di più investire nella chiarezza del sito, perché un'offerta poco chiara non la risolve un'app, come analizziamo nell'articolo Se il visitatore non capisce il Suo sito, paga traffico che non sfrutterà.

Ordini B2B

I clienti di un grossista ordinano ripetutamente lunghi elenchi di articoli. Contano la possibilità di ripetere velocemente un ordine, l'importazione da un foglio di calcolo e il collegamento all'ERP, cioè il sistema gestionale aziendale. Una web app è in grado di gestire tutto questo, ma prima verifichi se non basti il modulo B2B dell'e-commerce o dell'ERP che l'azienda possiede già.

Programma fedeltà

Una catena di caffetterie dovrebbe innanzitutto verificare se la funzione fedeltà non sia già offerta dal sistema di cassa che utilizza. Una via di mezzo è una PWA con notifiche push, che su iPhone arrivano solo dopo l'aggiunta alla schermata Home. L'app nativa ha senso quando il progetto pilota dimostra che i clienti usano spesso il programma e che a frenarli è proprio questo passaggio.

Strumento interno per le approvazioni

Un'azienda approva fatture e ferie via e-mail. Per prima cosa vanno eliminati i passaggi di approvazione che non controllano nulla e va verificato se il processo non sia già coperto dal software di contabilità o di gestione del personale che l'azienda già paga. In caso contrario basta una web app con login aziendale, eventualmente una PWA. Qui due app native aggiungerebbero costi di sviluppo e di rilascio senza un beneficio in grado di compensarli.

Il percorso graduale: web, misurazione e solo dopo l'app nativa

Per un prodotto senza un'esigenza nativa chiara consigliamo di procedere per fasi:

Prima versione sul web o come PWA: una sola codebase, aggiornamenti immediati e una risposta rapida sul fatto che le persone vogliano o meno il prodotto.
Misurazione: quanto spesso le persone tornano, da quali dispositivi, quante hanno installato la PWA e quali limiti si ripresentano.
Soglia definita in anticipo: la direzione stabilisce quale risultato giustificherà un'app nativa. Senza questa soglia la decisione ricade nel riflesso.
App nativa dove i dati la giustificano, spesso solo per il gruppo di utenti più attivo.

Una prassi comune è separare la parte server, con dati e logica, e renderla accessibile tramite API, cioè un'interfaccia concordata per lo scambio di dati tra programmi. L'app nativa si collega poi agli stessi dati e alle stesse regole, e il web resta un canale a pieno titolo, come approfondiamo nell'articolo Un sito premium non è estetica. È l'infrastruttura commerciale dell'azienda. Se però sa fin dall'inizio che il prodotto si regge su una funzionalità che il web non può coprire, il percorso graduale è una deviazione inutile.

Quando l'app nativa è la scelta giusta

Il prodotto si basa su un lavoro continuo in background, per esempio sul tracciamento della posizione per l'intero turno. Secondo MDN il service worker non è sempre in esecuzione, perciò a nostro avviso il web non basta.
L'app lavora in profondità con Bluetooth, USB, file o contatti, cioè con ambiti che Google indica tra i punti di forza delle app native.
L'app è il prodotto stesso, che le persone usano ogni giorno, e le prestazioni sono parte del suo valore.

Anche in questo caso valuti prima lo sviluppo multipiattaforma con un'unica codebase. La domanda «app nativa o web app» la ponga solo dopo aver definito con precisione il problema, l'utente e il contesto.

Cosa portarsi a casa

Sostituisca la domanda «ci serve un'app?» con queste: chi usa il prodotto, quanto spesso, dove e che cosa deve saper fare il dispositivo.
Calcoli i costi sull'intero ciclo di vita: ogni piattaforma nativa aggiunge una codebase, l'approvazione e i test e, se vende contenuti digitali, anche la commissione dello store.
Chieda che ogni affermazione sulle capacità delle PWA sia supportata da una fonte con data, soprattutto per iOS, dove le condizioni sono cambiate più volte dal 2023.
Per gli strumenti interni parta dal web e valuti un'app nativa solo per il lavoro sul campo, il magazzino o l'uso di hardware.
Prima di rilasciare la prima versione, concordi una soglia misurabile che giustifichi l'app nativa.