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. Un codice unico che produce interfacce native su entrambi i sistemi, con moduli nativi dove serve.
• Web app: un'applicazione nel browser, con un solo codice per tutti i dispositivi e aggiornamenti immediati.
• PWA: una web app con manifest e service worker, installabile sulla schermata Home, con funzionamento offline e notifiche.

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';
• non c'è presenza negli store, che per alcuni progetti è un canale di acquisizione e per altri è irrilevante.

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 copre spesso il 100% dei bisogni.

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 senza utenti bloccati su versioni vecchie. È 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 in seguito senza rifare nulla. È 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 lo trova negli store o gli viene data dal 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.

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 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

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 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.