App mobile nativa o cross-platform?

Secondo Mesterséges Intelligencia Központ Kft., azienda di sviluppo software con sede a Budapest, un'app nativa serve quando l'applicazione usa a fondo il dispositivo; se sulle due piattaforme servono le stesse funzioni, un'unica base di codice comune è più semplice da mantenere.

In sintesi: la decisione dipende dalle funzioni, non dalla moda: quanto a fondo l'app deve accedere al dispositivo, quali prestazioni richiede e chi la manterrà per anni. Se la presenza negli store e l'accesso profondo al dispositivo non sono importanti, può bastare anche un'applicazione web (PWA). Qualunque strada si scelga, il backend, le regole degli store e i regolari aggiornamenti dei sistemi operativi costituiscono una parte rilevante del lavoro.

Che cosa significano app nativa, cross-platform e web?

Un'app mobile si può realizzare in tre modi: separatamente per ogni piattaforma, con gli strumenti propri della piattaforma; da un'unica base di codice comune, compilata per entrambe le piattaforme; oppure con tecnologie web, eseguita nel browser. Tutte e tre le strade danno un'app funzionante; la differenza sta nell'accesso, nella manutenzione e in chi detta le regole con cui l'app deve aggiornarsi.

App nativa

In un'app nativa le versioni per iOS e per Android si realizzano separatamente, nel linguaggio e con gli strumenti di interfaccia propri di ciascuna piattaforma. Su iOS oggi si tratta tipicamente del linguaggio Swift e di SwiftUI: secondo Apple, SwiftUI, con una sintassi dichiarativa e basandosi sul linguaggio Swift, consente di costruire l'interfaccia su tutte le piattaforme Apple (Apple: SwiftUI). Su Android si tratta di Kotlin e Jetpack Compose: Google definisce Jetpack Compose il toolkit moderno consigliato da Android per creare interfacce native (Android Developers: Jetpack Compose) e per una nuova app Android consiglia di partire con Kotlin (Android Developers: Kotlin-first). Il vantaggio della strada nativa è che ogni nuova possibilità della piattaforma è disponibile direttamente fin dal primo giorno; lo svantaggio è che bisogna sviluppare e mantenere due basi di codice.

Framework cross-platform

Con i framework cross-platform l'app per iOS e quella per Android nascono da un'unica base di codice comune. Quattro approcci diffusi:

Flutter: framework basato sul linguaggio Dart. Secondo la documentazione, Flutter implementa in proprio ogni elemento dell'interfaccia invece di usare quelli del sistema, e per il disegno usa il motore chiamato Impeller; il codice proprio della piattaforma si può richiamare attraverso il cosiddetto canale di piattaforma (platform channel) (Flutter: Architectural overview).
React Native: basato su React e JavaScript; secondo la formulazione del progetto si scrive in JavaScript, ma viene visualizzato con codice nativo, perché i suoi componenti di base corrispondono ai mattoni nativi dell'interfaccia della piattaforma (React Native). Dalla versione 0.76 è predefinita la cosiddetta nuova architettura, che sostituisce il bridge asincrono con la JavaScript Interface (JSI) (React Native: New Architecture).
Kotlin Multiplatform: tecnologia open source di JetBrains con cui il codice si può condividere tra destinazioni Android, iOS, desktop, web e server. Si può condividere solo la logica di business, con un'interfaccia nativa, oppure, con Compose Multiplatform, anche l'interfaccia (Kotlin: Kotlin Multiplatform). Secondo la documentazione di Kotlin, Compose Multiplatform è al livello stabile anche su iOS (Kotlin: stability of supported platforms, verificato il 17 ottobre 2026).
.NET MAUI: il framework di Microsoft in C# e XAML con cui si possono sviluppare app per Android, iOS, macOS e Windows da un'unica base di codice comune; è l'evoluzione di Xamarin.Forms. Per compilare le app per iOS e macOS serve un Mac (Microsoft Learn: What is .NET MAUI?).

Applicazione web progressiva (PWA)

La PWA è un'applicazione web eseguita nel browser, che si può installare nella schermata iniziale e che, con funzioni che si ampliano gradualmente (progressive enhancement), offre un'esperienza più affidabile. Secondo la sintesi di web.dev, le app di piattaforma sono le più forti nelle capacità, le applicazioni web nella diffusione: un'unica base di codice raggiunge chiunque, su qualsiasi dispositivo (web.dev: Progressive Web Apps). Su iOS e iPadOS, dalla versione 16.4, anche un'applicazione web aggiunta alla schermata iniziale può chiedere il permesso per le notifiche push (WebKit: Web Push for Web Apps). Un limite importante: secondo il punto 4.2 delle linee guida dell'App Store, un'app deve offrire più di un sito web riconfezionato, quindi non conviene portare nello store un sito web semplicemente impacchettato come app (Apple: App Store Review Guidelines).

Il confronto in una tabella

Criterio	Nativa (Swift, Kotlin)	Cross-platform (Flutter, React Native, KMP, .NET MAUI)	PWA
Prestazioni	ottimizzabili direttamente con gli strumenti della piattaforma	le parti ad alto carico di calcolo si possono spostare in codice nativo	le determinano il browser e la tecnologia web
Accesso al dispositivo	ogni funzione della piattaforma, dal primo giorno	tramite il framework o un plugin; una nuova funzione arriva più tardi o con codice nativo aggiuntivo	limitato alle interfacce web supportate dal browser
Aspetto (look and feel)	esattamente gli elementi propri della piattaforma	in Flutter elementi disegnati in proprio, in React Native elementi nativi	simile a un sito web, dipende dal browser
Condivisione del codice	nessuna, due basi di codice separate	la logica e per lo più anche l'interfaccia sono comuni	un'unica base di codice per ogni dispositivo
Team	competenze iOS e Android separate	un solo team, ma serve anche conoscenza dei livelli nativi	un team di sviluppo web
Manutenzione	due basi di codice seguono i regolari cambiamenti delle piattaforme	una base di codice, più gli aggiornamenti propri del framework	nessuna pubblicazione negli store, bisogna seguire i cambiamenti dei browser
Dimensione dell'app	si basa sulle librerie proprie del sistema	anche il motore del framework finisce nell'app	nessun pacchetto di installazione, il browser usa la cache
Presenza negli store	sì	sì	non necessaria; se impacchettata per lo store, vale il limite del punto 4.2

La documentazione di Flutter lo dice esplicitamente: il pacchetto di un'app Flutter è autonomo e contiene tutto il codice e tutte le risorse necessari per l'esecuzione, perciò la sua dimensione può essere un aspetto da considerare (Flutter: Measuring your app's size). In pratica la differenza raramente è decisiva, ma è bene saperlo se il pubblico di destinazione usa l'app su dispositivi meno recenti o con una connessione debole.

Quando conviene ciascuna?

Nativa, se

l'app usa a fondo il dispositivo: fotocamera, sensori, Bluetooth, attività in background;
richiede prestazioni elevate, ad esempio elaborazione di immagini o audio in tempo reale, animazioni complesse;
bisogna sfruttare subito le possibilità più recenti della piattaforma;
l'app serve per una sola piattaforma, oppure le due versioni differiscono in modo sostanziale.

Cross-platform, se

sulle due piattaforme servono le stesse funzioni, ed è importante che le modifiche compaiano contemporaneamente;
l'app è composta soprattutto da moduli, elenchi, visualizzazione di dati e notifiche, come la maggior parte delle app aziendali;
un solo team mantiene l'app nel lungo periodo;
l'azienda usa già il linguaggio del framework, ad esempio con competenze React dal web verso React Native, con un background .NET verso .NET MAUI.

PWA o applicazione web, se

gli utenti non cercano l'app nello store, ma arrivano da un link o dal sito web;
non serve un accesso profondo al dispositivo;
l'app deve funzionare allo stesso modo su computer e su telefono;
un aggiornamento rapido, senza la revisione dello store, è più importante delle funzioni della piattaforma.

Anche qui i confini non sono netti. Con Kotlin Multiplatform, ad esempio, la logica di business può essere comune mentre l'interfaccia resta nativa; in Flutter e in React Native una parte critica si può scrivere anche in codice nativo. Il gioco del nostro sito funziona come applicazione web: gira nel browser senza installazione, allo stesso modo su computer e su telefono. Della strada web parliamo nella pagina Realizzazione di siti web e sviluppo di applicazioni web.

Il backend e il pannello di amministrazione

Un'app mobile raramente è fine a se stessa. Non appena ha account utente, dati condivisi o notifiche, le serve un server alle spalle: lì risiedono gli account, i dati e i permessi, e da lì partono le notifiche. Le notifiche push il backend di solito le invia tramite un servizio dedicato; Firebase Cloud Messaging, ad esempio, è una soluzione di messaggistica multipiattaforma in cui un ambiente server attendibile compone e invia i messaggi alle app Apple, Android e web (Firebase: Cloud Messaging).

Il pannello di amministrazione è la console di gestione del backend: dal browser si modificano i contenuti e si gestiscono gli utenti e le impostazioni, così per le modifiche quotidiane non serve uno sviluppatore. Qui colleghiamo anche i sistemi aziendali esistenti, come un CRM, un gestionale di magazzino o un programma di fatturazione, perché l'app lavori con gli stessi dati del resto dell'azienda. Se un sistema del genere non esiste ancora, costruiamo anche quello come software su misura. La scelta tra nativa e cross-platform non riguarda il backend: lo stesso server può servire sia un'app nativa sia un'app realizzata con Flutter.

Pubblicazione negli store: a che cosa fare attenzione a ottobre 2026?

Le regole degli store cambiano spesso, perciò indichiamo la data dei punti seguenti (verificato il 17 ottobre 2026).

App Store (Apple)

Linee guida per la revisione: le App Store Review Guidelines sono state aggiornate l'ultima volta il 16 ottobre 2026. Secondo il punto 2.1 va inviata una versione completa, pronta per la revisione; se l'app prevede un accesso con credenziali, bisogna fornire un account demo, e il backend deve funzionare anche durante la revisione. Secondo il punto 5.1.1 ogni app deve rimandare alla propria informativa sulla privacy e, se consente di creare un account, deve offrire anche la cancellazione dell'account all'interno dell'app (Apple: App Store Review Guidelines).
Scheda sulla privacy: in App Store Connect bisogna indicare le pratiche di trattamento dei dati dell'app, comprese quelle dei componenti esterni integrati (ad esempio degli SDK di analisi); è necessario per inviare sia una nuova app sia un aggiornamento (Apple: App privacy details).
Requisito sugli strumenti di sviluppo: dal 28 aprile 2026 le app caricate in App Store Connect devono essere compilate con Xcode 26 o una versione successiva, con l'SDK di iOS 26, e dal 9 settembre 2026 le app per iOS e iPadOS devono avere come destinazione almeno iOS 13 (Apple: Upcoming requirements).
Account aziendale: per registrarsi come organizzazione l'azienda deve essere una persona giuridica e disporre di un numero D-U-N-S, e chi effettua la registrazione deve avere il potere di assumere obblighi per conto dell'azienda (Apple: Enrollment).
Status di operatore commerciale nell'UE: Apple chiede allo sviluppatore di dichiarare se è un operatore commerciale ai sensi del diritto dell'Unione; nell'UE i recapiti degli operatori commerciali sono mostrati nella pagina dell'app nello store (Apple: Digital Services Act trader requirements).

Google Play

Livello API di destinazione: dal 31 agosto 2026 le nuove app e gli aggiornamenti per telefono devono avere come destinazione almeno Android 16 (livello API 36); le app esistenti devono avere come destinazione almeno Android 15 (livello API 35) per restare disponibili ai nuovi utenti sui dispositivi con versioni di Android più recenti. Con una proroga richiesta in Play Console, la scadenza è il 1º novembre 2026 (Android Developers: Target API level).
Test per gli account personali: per gli account sviluppatore personali creati dopo il 13 novembre 2023, prima della pubblicazione in produzione bisogna eseguire un test chiuso con almeno 12 tester che vi partecipino ininterrottamente da almeno 14 giorni (Play Console Help: testing requirements).
Account organizzazione: non è possibile creare un account sviluppatore per un'organizzazione senza un numero D-U-N-S (Play Console Help: creating an account).
Modulo sulla sicurezza dei dati: va compilato per ogni app pubblicata su Google Play, anche se l'app non raccoglie dati degli utenti (Play Console Help: Data safety).
Cancellazione dell'account: se nell'app si può creare un account, la cancellazione dell'account e dei dati collegati deve poter essere richiesta sia all'interno dell'app sia tramite un link web (Play Console Help: account deletion requirements).

Queste regole valgono indipendentemente dalla tecnologia: un'app realizzata con Flutter o React Native deve soddisfare gli stessi requisiti di livello API di destinazione e di SDK di un'app nativa, e gli aggiornamenti del framework devono stare al passo con essi. Consigliamo che l'account sviluppatore appartenga all'azienda committente: così l'app compare con il nome della Sua azienda, e anche la scheda nello store resta all'azienda.

Accessibilità

Entrambe le piattaforme dispongono di un lettore di schermo integrato (VoiceOver su iOS, TalkBack su Android) e offrono interfacce perché le app collaborino con queste tecnologie assistive (React Native: Accessibility). La documentazione di Flutter, ad esempio, raccomanda che il lettore di schermo descriva ogni controllo in modo comprensibile, che il rapporto di contrasto tra testo e sfondo sia di almeno 4,5:1 e che ogni elemento toccabile misuri almeno 48×48 pixel (Flutter: Accessibility). La documentazione di Android consiglia le linee guida di Material Design, lo strumento Accessibility Scanner e verifiche automatiche per individuare i problemi (Android Developers: Accessibility).

Non è solo una buona pratica: secondo la direttiva (UE) 2019/882, gli Stati membri devono applicare dal 28 giugno 2025 i requisiti di accessibilità per i servizi di commercio elettronico forniti ai consumatori, compresi quelli forniti tramite app mobili; le microimprese che forniscono servizi devono esserne esentate (EUR-Lex: direttiva (UE) 2019/882). Le norme ungheresi si basano sul recepimento della direttiva. I dettagli relativi ai negozi online sono trattati nell'articolo Negozio online: piattaforma in abbonamento o sviluppo su misura?.

Intelligenza artificiale: sul dispositivo o nel cloud?

In un'app mobile una funzione di IA può girare in due posti: sul telefono stesso, oppure in un grande modello linguistico nel cloud, attraverso il backend.

Sul dispositivo (Apple): a partire da iOS 26 il framework Foundation Models di Apple dà accesso ai modelli progettati per Apple Intelligence, eseguiti sul dispositivo e su Private Cloud Compute; si può usare per la generazione di testo, l'output strutturato e il richiamo di strumenti propri, ma solo sui dispositivi che supportano Apple Intelligence (Apple: Foundation Models).
Sul dispositivo (Android): Gemini Nano gira nel servizio di sistema AICore di Android ed è accessibile tramite le interfacce GenAI di ML Kit, ad esempio per riassunti, correzione di testi, riformulazione e descrizione di immagini. Secondo Google funziona anche senza rete e i dati sensibili restano sul dispositivo, ma il modello è limitato dal limite di token e dall'hardware del dispositivo (Android Developers: Gemini Nano).
Nel cloud: i grandi modelli linguistici di OpenAI (ChatGPT), Anthropic (Claude) e Google (Gemini), per compiti più complessi, come un assistente che risponde a partire dai materiali dell'azienda, l'elaborazione di documenti e immagini o i riassunti. La chiave di accesso al servizio di IA resta sul backend, non sul telefono: così non può essere estratta dall'app, e l'utilizzo si può regolare sul server.

Il modello eseguito sul dispositivo è interessante per la protezione dei dati e il funzionamento offline, ma non è disponibile sul dispositivo di ogni utente, perciò di solito conviene progettarlo insieme a una riserva nel cloud. Del collegamento dei modelli parliamo nella pagina Integrazione dell'IA.

Da che cosa dipende la manutenzione?

Un'app mobile non è finita nemmeno dopo la consegna: il suo ambiente cambia continuamente. Il lavoro di manutenzione è determinato soprattutto da questi fattori:

I requisiti dei sistemi operativi e degli store: Apple impone versioni più recenti di Xcode e dell'SDK per i caricamenti, Google Play un livello API di destinazione più recente. Le date indicate sopra mostrano che questi requisiti salgono regolarmente.
Le modifiche alle linee guida degli store: nuove dichiarazioni sulla privacy, regole sulla cancellazione degli account o sui test.
Gli aggiornamenti del framework: in un'app cross-platform un cambio di versione principale di Flutter, React Native o .NET MAUI può richiedere lavoro sia nel codice proprio sia nei plugin utilizzati.
I componenti esterni: SDK di pagamento, di mappe e di analisi, che hanno anch'essi i propri requisiti di aggiornamento.
Il backend e le integrazioni: le modifiche alle interfacce dei sistemi aziendali collegati e dei servizi di IA.
Il numero di basi di codice: due app native richiedono modifiche in due punti.

Errori frequenti

La tecnologia viene scelta in base alle abitudini del team, non alle funzioni dell'app.
Si pianificano solo le schermate, senza tenere conto del backend e del pannello di amministrazione.
Un sito web viene semplicemente impacchettato come app, e lo store lo rifiuta.
L'account sviluppatore è intestato all'azienda di sviluppo, e in seguito la scheda nello store non può essere trasferita.
La cancellazione dell'account, la scheda sulla privacy o l'account demo vengono aggiunti il giorno dell'invio.
Nessuno si occupa degli aggiornamenti dopo la consegna, e dopo una modifica delle regole l'app non è più visibile ai nuovi utenti.

Domande frequenti

Nativa o Flutter/React Native?

Se l'app usa a fondo il dispositivo (fotocamera, sensori, processi in background) o richiede prestazioni elevate, lo sviluppo nativo è la strada più sicura. Se sulle due piattaforme servono le stesse funzioni, un'app con base di codice comune realizzata con Flutter o React Native è più semplice da mantenere. Con Kotlin Multiplatform è percorribile anche una via intermedia: logica di business comune, interfaccia nativa. Nella prima consulenza formuliamo una proposta in base alle funzioni concrete.

Quando basta un'applicazione web (PWA)?

Quando gli utenti arrivano da un link o dal sito web, non serve un accesso profondo al dispositivo ed è importante che l'app funzioni allo stesso modo su computer e su telefono. Si può installare nella schermata iniziale e può inviare notifiche push anche su iOS, ma non offre presenza negli store, e la gamma delle funzioni del dispositivo dipende dal browser.

Serve un backend?

Quasi sempre: non appena l'app ha account utente, dati condivisi o notifiche, le serve un server alle spalle. Fa eccezione l'app che conserva i dati solo sul dispositivo. Realizziamo anche il backend e il pannello di amministrazione, e li colleghiamo ai sistemi aziendali esistenti.

Chi pubblica l'app negli store?

Della pubblicazione ci occupiamo noi: prepariamo i materiali per la scheda nello store e le dichiarazioni sulla privacy, inviamo l'app e la seguiamo per tutta la revisione. Consigliamo che l'account sviluppatore appartenga alla Sua azienda; per un account organizzazione entrambi gli store chiedono un numero D-U-N-S, perciò conviene procurarselo per tempo.

Da che cosa dipende il costo della manutenzione?

Da quante basi di codice bisogna mantenere, da quanto spesso cambiano i sistemi operativi e i requisiti degli store, da quanti componenti esterni e integrazioni usa l'app e da quanto ulteriore sviluppo è previsto. Il prezzo dello sviluppo lo determiniamo in base alla dimensione funzionale; il metodo è descritto nella pagina Prezzi.

Come possiamo aiutarLa?

Sviluppiamo app per iOS e Android: realizziamo il backend e il pannello di amministrazione che stanno dietro, integriamo l'intelligenza artificiale e accompagniamo l'app fino alla pubblicazione negli store. La scelta tra nativa e cross-platform la facciamo insieme, in base alle funzioni. I dettagli del servizio sono descritti nella pagina Sviluppo di app mobili.

Misuriamo la dimensione funzionale dello sviluppo in punti funzione COSMIC (ISO/IEC 19761), e su questa base prepariamo l'offerta e la pianificazione. La prima consulenza è gratuita, su richiesta firmiamo un accordo di riservatezza (NDA) e dopo la consegna ci occupiamo anche della gestione e della manutenzione. Il codice sorgente e i diritti d'uso sono regolati dal contratto. Descriva in poche frasi la Sua idea e ci contatti.