App nativa, web app o PWA: una scelta architetturale, non di moda

La domanda «ci serve un'app?» arriva quasi sempre con una risposta già in testa: l'icona nello store. Ma la scelta tra app nativa, multipiattaforma, web app e PWA non riguarda l'icona. Riguarda accesso all'hardware, distribuzione, costi di manutenzione nel tempo e quante basi di codice si dovranno tenere vive. È una scelta di architettura, e conviene farla con criteri tecnici.

Le quattro opzioni, in breve

• App nativa: Swift per iOS, Kotlin per Android. Due basi di codice, pieno accesso alle API del sistema, massime prestazioni.
• Multipiattaforma: React Native o Flutter. Gran parte del codice è condivisa, con integrazioni specifiche per piattaforma. React Native usa componenti nativi; Flutter disegna principalmente l’interfaccia tramite il proprio motore.
• Web app: un'applicazione nel browser, con un solo codice per tutti i dispositivi e aggiornamenti immediati.
• PWA: una web app che offre un’esperienza installabile tramite manifest e browser compatibili. Offline e notifiche richiedono implementazioni dedicate, spesso basate su service worker: non sono conseguenze automatiche dell’installazione.

A metà strada c'è Capacitor: una web app incapsulata in un guscio nativo, pubblicabile negli store e con accesso ai plugin del dispositivo.

I limiti reali delle PWA

Le PWA sono state promosse a lungo come la soluzione universale. Oggi sono molto più mature, ma su iOS restano differenze da conoscere:

• le notifiche push funzionano da iOS 16.4 solo per le PWA aggiunte alla schermata Home, e l'utente deve fare quel passaggio manualmente;
• la sincronizzazione in background e alcune API (Bluetooth, NFC, accesso esteso al file system) non sono disponibili o lo sono in modo parziale;
• lo spazio di archiviazione può essere liberato dal sistema se l'app non viene usata per un po';
• la distribuzione web non richiede gli store; per entrarvi possono servire pacchetti o wrapper e verifiche specifiche per piattaforma.

Su Android e su desktop i limiti sono molto minori. Se il pubblico è soprattutto interno (collaboratori, soci, clienti già acquisiti) e su dispositivi misti, una PWA può coprire i requisiti, da verificare sui dispositivi e sulle versioni di sistema effettivamente usati.

Quando serve davvero il nativo

Il nativo o il multipiattaforma diventano necessari quando:

• l'app usa hardware in modo intenso: Bluetooth Low Energy, sensori, fotocamera con elaborazione in tempo reale, geolocalizzazione in background;
• servono prestazioni grafiche elevate o animazioni complesse a 60 fps su dispositivi di fascia bassa;
• lo store è il canale con cui le persone trovano il servizio;
• l'app deve funzionare a lungo offline con sincronizzazione affidabile.

Tra nativo puro e multipiattaforma, per la gran parte dei progetti che vedo il multipiattaforma è il compromesso migliore: un codice, due store, moduli nativi solo dove servono.

Il costo che non si vede nel preventivo

Un'app negli store non si consegna una volta. Ogni anno Apple e Google rilasciano nuove versioni del sistema, cambiano i requisiti di pubblicazione, deprecano API, impongono nuovi livelli minimi di SDK. Le librerie native del progetto vanno aggiornate di conseguenza. Con due app native, il lavoro raddoppia.

Una web app o una PWA si aggiornano con un deploy, senza revisione degli store e con una distribuzione centralizzata degli aggiornamenti. Cache, service worker e sessioni già aperte richiedono comunque una strategia per il passaggio di versione. È una differenza di costo operativo che pesa più del costo iniziale.

Il backend è la parte che resta

Qualunque sia il client, la parte che dura di più è il backend: API, autenticazione, dati, integrazioni. Progettarlo bene, con API documentate e indipendenti dal client, permette di partire con una web app e aggiungere un client nativo riutilizzando backend e integrazioni, pur dovendo sviluppare e verificare il nuovo client. È l'errore più costoso che vedo: un'app costruita con la logica dentro il client, che diventa impossibile da portare su un'altra piattaforma.

Come decido

Le domande che faccio all'inizio:

1. Chi usa l’app e come la scopre: negli store o attraverso il fornitore del servizio?
2. Quali funzioni del dispositivo servono davvero, non «potrebbero servire»?
3. Quanto deve funzionare offline, e con che tipo di sincronizzazione?
4. Chi la manterrà tra tre anni, e con quale budget annuale?
5. Esiste già una web app o un gestionale da cui partire?

Se le risposte non indicano hardware specifico o store come canale, propongo di partire dal web.

Offline e sincronizzazione, il punto più sottovalutato

«Funziona anche offline» è una frase che nasconde molto lavoro. In una PWA il service worker decide cosa servire dalla cache e cosa chiedere alla rete: le risorse statiche si servono dalla cache, i dati si chiedono alla rete con un ripiego sulla cache, le pagine si aggiornano in background. I dati che l'utente crea senza connessione vanno salvati in locale, in IndexedDB, e inviati al server quando la rete torna.

Il problema vero è il conflitto: due dispositivi modificano lo stesso dato offline, oppure il dato è cambiato sul server nel frattempo. Serve una regola esplicita, decisa con chi conosce il processo: vince l'ultima modifica, vince il server, oppure si chiede all'utente. Senza questa regola, la sincronizzazione perde dati in silenzio.

Su iOS la sincronizzazione in background delle PWA è limitata, quindi l'invio avviene alla riapertura dell'app. Per molti casi d'uso (checklist, note, moduli compilati sul campo) va benissimo; per un'app che deve sincronizzare dati di continuo anche da chiusa, è un argomento a favore del nativo o del multipiattaforma.

Verificare offline e concorrenza

Una coda locale non basta a garantire la sincronizzazione. Ogni operazione deve avere un identificativo stabile per evitare duplicati quando viene ritentata, e ogni record modificabile deve portare una versione letta dal client. Il server accetta la modifica solo se la versione coincide, altrimenti restituisce un conflitto da risolvere.

La prova minima comprende: creazione offline, riapertura dopo la chiusura dell’app, invio duplicato, sessione scaduta e modifica contemporanea da due dispositivi. I dati devono restare distinguibili tra salvati localmente, inviati e confermati dal server. Su iPhone verifico separatamente l’esperienza nel browser e quella aggiunta alla schermata Home: le notifiche richiedono installazione, permesso e un’interazione esplicita dell’utente.

Riferimento: Web Push per web app su iOS e iPadOS, WebKit.

Come la vedo io

La mia preferenza è chiara: web app o PWA come prima scelta, nativo quando i requisiti lo impongono. Non per pigrizia, ma perché un unico codice, aggiornato con un deploy, riduce il costo di tutto il ciclo di vita. Il gestionale di Altura Vela e la piattaforma di Fix and Sail sono applicazioni web in Nuxt.js usate ogni giorno da telefono, e nessuno dei due ha avuto bisogno di uno store per funzionare.

Quando serve qualcosa di più vicino al dispositivo, lo si fa con criterio: con VeWorld, per esempio, ho lavorato al frontend React di un'estensione Chrome, dove il contesto di esecuzione imponeva vincoli precisi. La scelta dello strumento viene sempre dopo i requisiti, mai prima.

Perché affidarlo a me

Ho cominciato a programmare nel 1999 e ho consegnato più di 300 progetti, molti dei quali app e siti per agenzie, da Roma e da remoto. Sviluppo web app, PWA e app multipiattaforma, e progetto il backend in modo che il client si possa cambiare senza rifare tutto.

Se stai valutando un'app, scrivimi: in una chiacchierata di circa 20 minuti capiamo quale architettura serve davvero al tuo caso. Il servizio è in App mobile.