App nativa o multipiattaforma: Flutter, React Native o PWA?

Prima di ogni progetto mobile arriva la stessa domanda: conviene un'app nativa, un'app multipiattaforma o una web app installabile? La risposta non è ideologica. Dipende da che cosa deve fare l'app, da chi la userà, da quanto budget e tempo ha a disposizione e da quanto vuole controllare l'esperienza su ogni dispositivo. In questa guida confrontiamo le tre strade: app nativa con Kotlin e Swift, app multipiattaforma con Flutter o React Native, e PWA (Progressive Web App). Troverà i criteri di scelta, i compromessi reali e alcuni scenari tipici, senza promettere che una soluzione sia sempre la migliore.

Le tre strade in breve

App nativa. Si scrive un'app separata per ciascun sistema, con gli strumenti ufficiali: Kotlin (e Jetpack Compose) per Android, Swift per iOS. Si ottiene il massimo accesso alle funzioni del dispositivo, ma si mantengono due basi di codice.

App multipiattaforma. Una sola base di codice produce app per Android e iOS. I due framework più diffusi funzionano in modo diverso:

• Flutter: usa il linguaggio Dart e, secondo la documentazione ufficiale, consente di distribuire su più dispositivi da un'unica base di codice (mobile, web, desktop, embedded) e di controllare ogni pixel dell'interfaccia.
• React Native: usa JavaScript e React; secondo il sito ufficiale, le primitive di React vengono rese come componenti dell'interfaccia nativa della piattaforma, e per i nuovi progetti è raccomandato un framework come Expo.

PWA. Un sito web progettato come app: si apre nel browser, può essere installato sulla schermata iniziale, funzionare in parte offline e inviare notifiche. Secondo web.dev, una PWA installata ha una propria finestra, e i service worker gestiscono la cache e le risposte offline. Non passa dagli store: è una pagina web, con tutti i pro e i contro del caso.

Confronto in tabella

La tabella è una sintesi qualitativa, non un benchmark: i risultati reali dipendono dal progetto e dalla qualità dell'esecuzione.

App nativa: quando ha senso

Lo sviluppo nativo è la scelta più solida quando l'app dipende fortemente dall'hardware o dal sistema operativo. Alcuni casi tipici:

• elaborazione intensiva di audio, video o immagini in tempo reale;
• uso avanzato di sensori, Bluetooth, NFC, fotocamera o realtà aumentata;
• funzioni in background molto specifiche o integrazioni profonde con il sistema;
• app destinata a una sola piattaforma, per esempio uno strumento interno su dispositivi Android aziendali;
• necessità di adottare subito le novità di un nuovo sistema operativo.

Il prezzo è il lavoro doppio: due app da progettare, sviluppare, testare e mantenere. In compenso, ciascuna segue le convenzioni della propria piattaforma e può essere ottimizzata fino in fondo.

Un esempio dal nostro lavoro: Park France è un'app per parcheggi costruita con Kotlin e Jetpack Compose su dati aperti pubblici. È un esempio di app sviluppata direttamente con gli strumenti ufficiali Android.

Flutter e React Native: una base di codice, due piattaforme

La promessa del multipiattaforma è semplice: scrivere una volta, pubblicare su entrambi gli store. In pratica, il risparmio è reale soprattutto su logica applicativa, interfaccia e test, che non vanno ripetuti due volte. Non è però zero: restano da gestire le differenze tra piattaforme, i permessi, la pubblicazione e le integrazioni con funzioni specifiche del dispositivo.

Flutter

È indicato quando l'interfaccia è personalizzata e deve apparire identica su Android e iOS, o quando si vuole una sola squadra su un unico linguaggio. Il disegno dell'interfaccia è controllato dal framework, il che dà libertà visiva e coerenza; in cambio, l'app non adotta automaticamente i componenti nativi del sistema e bisogna curare con attenzione l'aderenza alle convenzioni di ciascuna piattaforma.

Tra i progetti che abbiamo sviluppato, Cachet, un'app per fatture e preventivi che funziona offline con preimpostazioni fiscali per paese, e Flash-Destock, un marketplace di offerte lampo locali con pass QR e pannello per i commercianti, sono entrambi realizzati con Flutter. Per prodotti con molte schermate, logica propria e pubblicazione su due store, una sola base di codice riduce il lavoro di allineamento tra le versioni.

React Native

È la scelta naturale se l'azienda ha già competenze JavaScript o React, per esempio un team web che sviluppa anche l'app, o se si vuole condividere parte della logica con un sito. Poiché rende componenti nativi, l'aspetto è più vicino a quello del sistema. Il compromesso è un ecosistema di librerie molto ampio ma eterogeneo: alcune dipendenze richiedono manutenzione attenta ad ogni aggiornamento del framework e dei sistemi operativi.

Come scegliere tra i due

Non c'è un vincitore assoluto. Una regola pratica:

1. Che competenze ha già? Se ha o assume un team JavaScript, React Native riduce l'attrito. Se parte da zero, la scelta si sposta sulla maturità del fornitore con ciascun framework.
2. Quanto conta l'interfaccia su misura? Per un'identità visiva forte e identica ovunque, Flutter è molto adatto.
3. Quali funzioni del dispositivo servono? Verifichi in anticipo che i plugin o le librerie necessari esistano, siano mantenuti e coprano il suo caso. Se un componente chiave non esiste, bisognerà scrivere codice nativo comunque.
4. Che cosa sa fare bene il suo fornitore? Un framework conosciuto a fondo produce un prodotto migliore di quello «teoricamente ideale» usato per la prima volta.

PWA: l'app che è un sito

Una PWA è un sito web con alcune capacità aggiuntive: installabile, utilizzabile in parte offline, in grado di inviare notifiche. I suoi vantaggi sono concreti:

• un solo prodotto per tutti i dispositivi, compreso il desktop;
• nessuna approvazione degli store e nessuna commissione di pubblicazione dello store;
• aggiornamenti immediati: l'utente ha sempre l'ultima versione;
• costi di sviluppo e manutenzione tipicamente più contenuti, perché si lavora con competenze web;
• visibilità sui motori di ricerca, perché le pagine sono indicizzabili.

I limiti sono altrettanto reali. L'accesso alle funzioni del dispositivo è quello che il browser mette a disposizione, e il supporto varia da sistema a sistema. Su iOS, in particolare, il comportamento delle web app installate ha avuto una storia movimentata nell'Unione europea: nel febbraio 2024 Apple aveva annunciato la rimozione delle web app dalla schermata iniziale per gli utenti UE, poi, il 1° marzo 2024, ha dichiarato che avrebbe continuato a offrire la funzionalità esistente. Il fatto è utile a titolo di cautela: una strategia che dipende interamente da una funzione concessa da una piattaforma è esposta ai cambiamenti di quella piattaforma. Prima di scegliere una PWA, verifichi sempre lo stato attuale del supporto per le funzioni che le servono sui sistemi dei suoi utenti.

Inoltre, i pubblici abituati a cercare le app negli store trovano spesso meno naturale installare una web app, e la presenza negli store è anche un canale di scoperta e di fiducia.

Quando una PWA basta

• strumenti gestionali o di consultazione usati in ufficio o su cantiere, dove l'installazione dagli store è un ostacolo;
• cataloghi, prenotazioni e servizi informativi in cui contenuto e velocità contano più delle funzioni del dispositivo;
• un primo test di mercato prima di investire in un'app completa;
• servizi in cui la scoperta passa dalla ricerca su Google, non dagli store.

Se la sua esigenza è di questo tipo, può essere più sensato partire da una web app su misura, pensata per funzionare bene anche da telefono, e valutare l'app negli store in un secondo momento. Un esempio dal nostro lavoro: PDF Nova è un'applicazione web con 45 strumenti per i PDF che elabora gran parte dei file direttamente nel browser, mentre PDF Nova per Android è un'app Flutter con scanner, OCR e firme: due prodotti distinti per due esigenze diverse.

Un criterio decisionale in cinque domande

1. L'app deve usare funzioni avanzate del dispositivo? Se sì, e sono centrali, propenda per nativo o per un multipiattaforma con moduli nativi mirati.
2. Il pubblico è su una sola piattaforma? Se sì, nativo su quella piattaforma può essere la via più semplice.
3. Il budget e i tempi sono limitati? Multipiattaforma o PWA riducono entrambi.
4. L'interfaccia deve essere identica ovunque? Flutter è adatto; React Native e nativo seguono più da vicino lo stile del sistema.
5. Gli utenti cercano l'app negli store? Se la presenza negli store è parte della strategia, escluda la PWA come unico canale.

Costi e manutenzione: che cosa cambia davvero

Per la stima dei costi di sviluppo rimandiamo alla nostra guida su quanto costa sviluppare un'app mobile, dove il confronto tra nativo e multipiattaforma è trattato con cifre e ipotesi dichiarate. Qui basta ricordare tre principi:

• Il multipiattaforma non dimezza i costi. Riduce il lavoro duplicato su logica e interfaccia, ma design, test, backend e pubblicazione restano.
• Il costo di manutenzione conta quanto quello di sviluppo. Due basi di codice significano due serie di aggiornamenti; una sola base di codice semplifica, ma dipende dalla manutenzione del framework e delle sue librerie.
• Il backend è indipendente dalla scelta. Server, database, autenticazione e pannello di gestione servono in tutti i casi, e spesso pesano più dell'app.

Errori frequenti nella scelta

• Scegliere la tecnologia prima dell'esigenza. Parta da ciò che l'utente deve fare, poi decida come.
• Dare per scontato che il multipiattaforma sia «più lento». Le differenze percepite dipendono soprattutto dalla qualità dell'implementazione, dall'ottimizzazione e dal tipo di app; per la maggior parte delle applicazioni di business non sono il fattore decisivo.
• Sottovalutare la pubblicazione. Account sviluppatore, schede degli store, privacy, revisioni: sono attività reali, a prescindere dal framework.
• Dimenticare l'accessibilità e le prestazioni su dispositivi economici. La provi su telefoni reali, non solo sull'ultimo modello.
• Non pianificare l'evoluzione. Chiedere in anticipo come si gestiranno aggiornamenti dei sistemi operativi e delle librerie.

Domande frequenti

Meglio Flutter o React Native?

Dipende dalle competenze disponibili e dalle priorità. Flutter offre un controllo visivo totale e un'unica base di codice anche per web e desktop; React Native riutilizza le competenze JavaScript e rende componenti nativi. Entrambi sono scelte mature per la maggior parte delle app di business. Le consiglieremo quello che il team conosce meglio e che copre le funzioni di cui ha bisogno.

Un'app multipiattaforma può essere approvata negli store?

Sì. Un'app Flutter o React Native viene pubblicata come qualsiasi altra su App Store e Google Play e segue le stesse regole di revisione, privacy e contenuti.

Una PWA può sostituire l'app negli store?

Per alcuni usi sì, per altri no. Funziona bene per servizi informativi, strumenti interni e cataloghi; è meno adatta quando servono funzioni avanzate del dispositivo o la presenza negli store come canale di acquisizione.

Posso iniziare con una PWA e passare a un'app più avanti?

È un percorso frequente e sensato: una web app permette di validare il servizio con costi contenuti, e la logica di business e il backend possono essere riutilizzati quando si passa a un'app negli store.

Quanto tempo serve per sviluppare un'app?

Dipende dal perimetro. Un prodotto minimo richiede in genere alcune settimane o pochi mesi; funzioni come pagamenti, notifiche, modalità offline e pannelli di gestione allungano i tempi. Un fornitore serio le darà un calendario per fasi, legato a rilasci verificabili.

Conclusione

Non esiste una tecnologia migliore in assoluto: esiste quella più adatta a funzioni, pubblico, budget e a chi dovrà mantenere il prodotto. Il nativo dà il massimo controllo a un costo maggiore; Flutter e React Native riducono il lavoro duplicato mantenendo una vera presenza negli store; la PWA è la strada più rapida e flessibile quando le funzioni del dispositivo non sono centrali. Se vuole discutere il suo caso, può contattarci per un confronto sul progetto, oppure consultare la nostra pagina sullo sviluppo di app mobile.