Flutter, Kotlin Multiplatform o React Native: quale scegliere per tipo di app e di team, quanto costa davvero pubblicarla e cosa chiede l'Europa
In Italia, a luglio 2026, il traffico web da dispositivo mobile si divide fra Android al 64,86% e iOS al 35,13%, secondo StatCounter. È esattamente lo scenario in cui lo sviluppo cross-platform smette di essere una preferenza tecnica e diventa una questione economica: nessuna delle due piattaforme è ignorabile, e scrivere due volte la stessa applicazione significa raddoppiare non solo lo sviluppo, ma anche il collaudo, gli aggiornamenti e le persone che devono restare in squadra per i prossimi tre anni.
Il mercato ha risposto. Secondo le rilevazioni di Appfigures, che analizza gli SDK presenti dentro le app pubblicate, Flutter è rilevato nel 25% delle app su Google Play e nel 16% di quelle su App Store, React Native rispettivamente nel 19% e nel 15%. Sono stime dichiarate tali dalla fonte, e le percentuali non si sommano perché un'app può contenere più SDK, ma l'ordine di grandezza è chiaro: una app su quattro o cinque, oggi, non è scritta due volte.
Le strade mature per farlo sono tre, e sono profondamente diverse fra loro — non tre modi di fare la stessa cosa, ma tre idee opposte di che cosa significhi "condividere il codice". Questa guida serve a scegliere quella giusta per il progetto che hai davanti e per il team che dovrà mantenerlo, a sapere quanto costa portare l'app negli store e a non farsi trovare impreparati dalle regole europee, che dal 2025 sono entrate nel mestiere.
INDICE DEI CONTENUTI
- Cosa significa davvero "cross-platform" nel 2026
- Flutter: un motore grafico tuo, su ogni schermo
- React Native: componenti nativi, logica in JavaScript
- Kotlin Multiplatform: condividere la logica, non lo schermo
- Quale framework per quale tipo di app
- Quale approccio per quale tipo di team
- Quanto costa davvero portare un'app negli store
- Le regole europee che ora fanno parte del mestiere
- Competenze necessarie per un freelance mobile
- Ruoli e abilità in un progetto di app
- Tariffe: quanto si guadagna sviluppando app in Italia
- Cosa significa per le aziende italiane
- Conclusioni
-
Domande frequenti
- Meglio Flutter o React Native nel 2026?
- Kotlin Multiplatform conviene se ho già due app native?
- Quanto costa mantenere un'app negli store ogni anno?
- Un'app cross-platform costa la metà di due app native?
- Devo preoccuparmi dell'European Accessibility Act?
- Quanto guadagna un freelance che sviluppa app in Italia?
Cosa significa davvero "cross-platform" nel 2026
Tre filosofie, non tre framework
Flutter disegna tutto da sé. Non usa i componenti dell'interfaccia del sistema operativo: porta il proprio motore grafico e dipinge ogni pixel. Il risultato è identico su Android e iOS perché non è né l'uno né l'altro — è Flutter.
React Native usa i componenti nativi, pilotati da JavaScript. Un pulsante è un vero pulsante di sistema; il codice che decide cosa farne gira in un motore JavaScript accanto. L'aspetto segue la piattaforma, il comportamento lo scrivi una volta sola.
Kotlin Multiplatform non condivide l'interfaccia affatto, a meno che tu non lo voglia. Condivide la logica — modelli, regole, rete, database, validazioni — e lascia che ogni piattaforma abbia la sua interfaccia scritta nel suo linguaggio, SwiftUI su iOS e Compose su Android. Se poi vuoi condividere anche la UI, esiste Compose Multiplatform, ma è una scelta successiva e separata.
Questa distinzione non è filosofia: determina cosa succede quando qualcosa non torna. Con Flutter, se un widget non si comporta come l'utente iPhone si aspetta, devi rifarlo tu. Con React Native, se una libreria nativa non è aggiornata, sei fermo. Con Kotlin Multiplatform scrivi due interfacce, con tutto il lavoro che comporta, ma nessuna delle due potrà mai sembrare fuori posto.
Quello che non si condivide mai
È la parte che fa saltare i preventivi, perché non compare in nessun confronto fra framework. Le firme e i profili di distribuzione, i permessi, le notifiche push, gli acquisti in-app, i moduli sulla privacy da compilare in due formati diversi, la revisione degli store, le schermate per due negozi, il collaudo su dispositivi reali, l'accessibilità. Tutto questo si fa due volte comunque, qualunque sia la tecnologia scelta, e su un'app di media dimensione pesa fra un quarto e un terzo del progetto.
In sintesi
Il cross-platform non dimezza il costo di un'app: dimezza il costo della parte che sta fra il modello dati e lo schermo. È moltissimo, ma è solo una parte, e chi vende "un'app a metà prezzo perché è cross-platform" sta preparando un contenzioso.
Flutter: un motore grafico tuo, su ogni schermo
La versione stabile corrente è la 3.47, di agosto 2026, con Dart 3.13, e il progetto rilascia una versione importante ogni trimestre. È il framework cross-platform più adottato secondo i dati Appfigures citati sopra, e ha alle spalle Google.
I vantaggi
Un solo comportamento, ovunque. Se l'app deve avere un'identità visiva forte, animazioni curate e un aspetto che non cambia fra dispositivi, disegnare tutto da sé è un vantaggio, non un compromesso. È il motivo per cui molte app di prodotto — quelle in cui il brand conta più della convenzione di sistema — scelgono Flutter.
Le prestazioni grafiche hanno una spiegazione tecnica, non solo uno slogan. Il motore Impeller compila gli shader in fase di build invece che a runtime, che è la ragione per cui sono spariti gli scatti alla prima esecuzione di un'animazione — il difetto più visibile delle versioni vecchie. Dalla 3.47 è il renderer predefinito anche su macOS, Windows e Linux.
La community è solida e lo dice con i numeri. Nella survey ufficiale del secondo trimestre 2026 la soddisfazione complessiva è al 93% e la fiducia nel progetto all'83%. C'è però un dato che va letto per intero, ed è il più interessante di tutti: la fiducia in Google si ferma al 62%, oltre venti punti sotto. Chi usa Flutter si fida di Flutter più di quanto si fidi di chi lo paga.
Il desktop ha finalmente un custode. Con la versione 3.44 di maggio 2026 Google ha annunciato che Canonical diventa manutentore e responsabile strategico di Flutter Desktop, con la titolarità degli embedder Linux, Windows e macOS. Per chi valuta Flutter anche per un applicativo da scrivania, è la differenza fra una promessa e un impegno.
Gli svantaggi
L'aspetto iOS è il punto debole, e lo dicono i suoi utenti. Nella stessa survey, i widget Cupertino — quelli che imitano l'interfaccia Apple — sono l'area con la soddisfazione più bassa: 61%, in calo di sei punti. Tradotto: un'app Flutter che deve sembrare nativa su iPhone richiede lavoro aggiuntivo, e chi promette il contrario non ha mai consegnato a un cliente che usa iPhone tutti i giorni.
Il web è supportato ma resta il fanalino di coda, con il 72% di soddisfazione e nessun supporto Impeller: sul browser si usa ancora Skia. Flutter web ha senso per applicativi interni, molto meno per una pagina pubblica che deve essere leggera e indicizzabile.
Nessuno sa quanto pesi davvero un'app Flutter. L'unico dato ufficiale sulla dimensione è quello di un'app di esempio su Flutter 1.17: 5,4 MB compressi, 13,7 MB installati. È del 2020. Vale come ordine di grandezza — il motore grafico si porta dietro alcuni megabyte — ma è un'informazione che nel 2026 andrebbe misurata sul proprio progetto, non citata.
Si dipende da un solo azionista. Non è una fondazione indipendente: è un progetto Google con licenza BSD. La community lo sa, e il divario di fiducia visto sopra è la misura di quella consapevolezza.
React Native: componenti nativi, logica in JavaScript
La versione corrente è la 0.87, dell'11 agosto 2026. Gli ultimi due anni sono stati i più importanti della sua storia, per due ragioni che vanno raccontate insieme.
I vantaggi
La riscrittura interna è finita davvero. La cosiddetta New Architecture — Fabric, TurboModules, Bridgeless — è predefinita dalla versione 0.76 dell'ottobre 2024, ed è l'unica architettura dalla 0.82 dell'ottobre 2025. Il vecchio ponte asincrono fra JavaScript e nativo, cioè la causa storica della fama di lentezza di React Native, non esiste più. Chi ha in mano un progetto fermo a una versione precedente sta lavorando su un framework che non c'è più: è un lavoro di aggiornamento da mettere a preventivo, non da scoprire.
Non dipende più da una sola azienda. Il 24 febbraio 2026 è nata ufficialmente la React Foundation sotto la Linux Foundation, con Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion e Vercel come membri fondatori. Meta ha conferito il progetto alla fondazione. È il percorso opposto a quello di Flutter, ed è un argomento concreto quando un cliente chiede chi garantisce la tecnologia fra cinque anni.
Se hai già un team web, hai già metà del team mobile. Stesse abitudini, stesso linguaggio, stesso modo di ragionare sui componenti. È la ragione economica per cui React Native vince quasi sempre nelle aziende che hanno già un prodotto web in React.
Expo ha reso semplice la parte noiosa. Build in cloud, aggiornamenti distribuiti senza passare dagli store, gestione dei certificati. Il piano gratuito dà 15 build per piattaforma al mese e mille utenti attivi per gli aggiornamenti, poi si passa a 19 dollari al mese e a 199 per il piano di produzione.
Gli svantaggi
Il ritmo è impegnativo. Sei versioni importanti negli ultimi diciotto mesi, con requisiti che cambiano — la 0.87 chiede Node 22, Kotlin 2, AGP 9. Un'app React Native lasciata ferma due anni non si aggiorna in un pomeriggio, e questo va detto al cliente quando si firma la manutenzione, non quando serve.
Fuori da telefoni e tablet, il supporto è indietro. È un fatto verificabile sul registro npm, non un'opinione: al 21 agosto 2026 il pacchetto principale è alla 0.87, React Native per Windows è alla 0.84, quello per macOS alla 0.81 — circa un anno di distanza — e React Native per il web non pubblica una versione dall'ottobre 2025. Chi promette "un codice per mobile, desktop e web" con questo stack sta descrivendo un'intenzione, non lo stato delle cose.
Le librerie native di terze parti sono il vero rischio. Il framework è solido; l'ecosistema di pacchetti che accede a fotocamera, bluetooth, mappe o pagamenti è fatto di progetti singoli, ognuno con la sua velocità di adeguamento. La domanda da porsi prima di firmare non è "React Native regge?", è "il pacchetto che mi serve è mantenuto?".
Kotlin Multiplatform: condividere la logica, non lo schermo
È l'approccio più diverso dei tre. Kotlin Multiplatform è stabile dal novembre 2023, la versione corrente del linguaggio è Kotlin 2.4, e Compose Multiplatform per iOS è stabile dal maggio 2025, con la versione 1.11 rilasciata a giugno 2026.
I vantaggi
È l'unico che si adotta a fette. Questo è il punto che decide la maggior parte dei progetti reali: non serve riscrivere niente. Si prende un pezzo di logica — la validazione degli ordini, il livello di rete, il database offline — lo si sposta in un modulo condiviso e lo si usa da entrambe le app native che già esistono. Flutter e React Native, per essere adottati, chiedono un'app nuova; Kotlin Multiplatform chiede un modulo.
Google lo sostiene ufficialmente, e lo scrive. La documentazione Android dichiara che "Kotlin Multiplatform è ufficialmente supportato da Google per condividere la logica di business fra Android e iOS", e diverse librerie Jetpack — lifecycle, paging, datastore, room, sqlite — sono di livello 1, cioè costruite e collaudate anche per iOS. Google Docs per iOS usa Kotlin Multiplatform in produzione.
Nessun compromesso sull'interfaccia. L'app iOS è SwiftUI, l'app Android è Compose. Nessuno dovrà mai chiedersi perché quel selettore di date si comporta in modo strano: è quello di sistema.
Va oltre il telefono. La stessa logica si riusa sul backend JVM, sul desktop e — con Compose Multiplatform, ancora in beta per il web — anche nel browser. Per un'azienda che ha già Kotlin lato server, il codice condiviso arriva fino al database.
Gli svantaggi
Il ponte verso Swift è ancora il suo limite tecnico. L'interoperabilità passa storicamente da Objective-C, e per questo si perdono pezzi di linguaggio per strada. L'export diretto verso Swift esiste ma la documentazione del repository Kotlin lo descrive come lavoro in fase molto iniziale; nel frattempo lo strumento di riferimento per colmare il divario è SKIE, che genera i wrapper Swift durante la compilazione. Funziona, ma è una dipendenza in più da spiegare al cliente.
Due interfacce restano due interfacce. Se il progetto è piccolo e l'interfaccia è la maggior parte del lavoro, condividere solo la logica fa risparmiare poco. Kotlin Multiplatform dà il meglio quando la logica di dominio è ricca: banche, sanità, logistica, sincronizzazione offline.
Serve comunque un Mac e serve conoscere iOS. Non è una scorciatoia per chi non ha competenze Apple: è un modo di non duplicarle sulla parte che non si vede.
Il tooling è più giovane. Il nuovo sistema di build di JetBrains, oggi chiamato Kotlin Toolchain, è dichiarato in alpha e non pronto per la produzione, e nel frattempo si lavora con Gradle. Chi arriva da Flutter, dove il comando di build è uno solo, lo sentirà.
Quale framework per quale tipo di app
App di prodotto con identità visiva forte (fidelizzazione, wellness, editoria, food delivery) — Flutter. Se il disegno è lo stesso su tutti i telefoni per scelta, disegnare tutto da sé smette di essere un compromesso.
App che deve sembrare nativa, soprattutto su iPhone (finanza, sanità, servizi pubblici, pubblica utilità) — Kotlin Multiplatform con SwiftUI e Compose, o in seconda battuta React Native. Con Flutter si arriva vicini, ma il capitolo Cupertino resta lavoro tuo.
App con molta logica di dominio e sincronizzazione offline (gestionali di campo, logistica, assicurazioni, contabilità) — Kotlin Multiplatform. La parte difficile è quella condivisa, ed è esattamente quella che non vuoi scrivere due volte con due bug diversi.
Estensione mobile di un prodotto web già in React — React Native. Il risparmio non è solo di codice: è di persone che non devono imparare niente di nuovo.
MVP da validare in poche settimane — React Native con Expo, per gli aggiornamenti distribuiti senza passare dalla revisione degli store, oppure Flutter se l'interfaccia è il fulcro della dimostrazione.
App aziendale interna — quasi sempre vince lo stack che l'azienda ha già. Se c'è un team Android, Kotlin Multiplatform; se c'è un team front-end, React Native.
App che vive di funzioni di sistema recenti (widget, live activity, salute, NFC, fotocamera avanzata) — il nativo resta il riferimento, e Kotlin Multiplatform è il compromesso che costa meno. Ogni framework che disegna da sé arriva su quelle API con un ritardo che non controlli.
Giochi — nessuno dei tre. Si usa un motore di gioco, e dirlo al cliente è un servizio che gli si rende.
App che potrebbe essere un sito — e capita più spesso di quanto si creda. Un catalogo che si consulta due volte l'anno non giustifica due store, due revisioni e un ciclo di aggiornamenti obbligatori a vita.
In sintesi
Flutter quando comanda il disegno, Kotlin Multiplatform quando comanda la logica, React Native quando comanda il team che c'è già. E se l'app esiste già in versione nativa, la domanda non è quale framework adottare: è quale pezzo conviene condividere per primo.
Quale approccio per quale tipo di team
Il freelance che lavora da solo
Flutter, nella maggior parte dei casi: un linguaggio, un comando di build, un solo insieme di problemi da conoscere a fondo. L'eccezione è chi arriva dal web con anni di React alle spalle — lì React Native accorcia i tempi più di qualunque argomento tecnico.
Team piccolo che costruisce un prodotto
Conta più la distribuzione che il linguaggio. Con due o tre persone, poter mandare una correzione agli utenti senza aspettare la revisione dello store vale più di qualche millisecondo di prestazioni: è il vantaggio principale di Expo, ed è la ragione per cui molti prodotti giovani restano su React Native anche quando avrebbero potuto scegliere altro.
Azienda con app native già in produzione
Kotlin Multiplatform, e non c'è davvero una seconda opzione. È l'unico approccio che si adotta senza buttare via niente: un modulo condiviso alla volta, con le due app che continuano a funzionare mentre la migrazione procede. Proporre a un'azienda con due app native funzionanti di riscrivere tutto in Flutter è la strada più rapida per far bocciare il progetto — e giustamente.
Team con front-end e mobile separati
React Native fa risparmiare più di quanto sembri, perché elimina un confine organizzativo: la stessa persona può correggere il bug sul web e sull'app. Il rischio speculare è illudersi che chi sa fare React sappia fare mobile: notifiche, permessi, cicli di vita e store restano competenze da acquisire, e vanno messe a piano.
Team che cambia spesso persone
Flutter, per la stessa ragione per cui Django vince nei progetti web con turnover alto: la strada è una sola e la trovano tutti. React Native paga il fatto che ogni progetto monta un insieme di librerie diverso, e Kotlin Multiplatform richiede persone che conoscano sia Android sia iOS — un profilo raro e caro.
Team che ha già Kotlin sul backend
Kotlin Multiplatform diventa la scelta ovvia: modelli e validazioni scritti una volta e usati sul server, su Android e su iOS. È il caso in cui il risparmio non riguarda solo le due app, ma l'intero sistema.
In sintesi
La domanda giusta non è quale framework sia migliore, è quale competenza il team ha già e quale è disposto a mantenere per tre anni. Un framework che nessuno in azienda sa aggiornare è un debito che matura da solo.
Quanto costa davvero portare un'app negli store
Le quote sono la voce più piccola
Apple Developer Program: 99 dollari l'anno. Google Play: 25 dollari una tantum. Sono cifre trascurabili, e proprio per questo ingannano: fanno pensare che pubblicare costi poco.
La voce che domina è la macchina che compila per iOS
Ecco il numero che nessun confronto fra framework racconta: su GitHub Actions un minuto di runner macOS costa 0,062 dollari contro gli 0,006 di un runner Linux. Dieci volte tanto. Ogni build iOS, di ogni framework, passa da un Mac, e quel moltiplicatore vale per tutti. Le alternative dedicate al mobile partono da un piano gratuito: Codemagic dà 500 minuti su Mac mini M2 al mese e poi chiede 0,095 dollari al minuto, con formule a prezzo fisso da 3.990 dollari l'anno per chi compila di continuo.
La manutenzione non è opzionale, è un calendario
Un'app non si aggiorna quando si hanno idee nuove: si aggiorna quando lo dicono Apple e Google. Dal 28 aprile 2026 ogni caricamento su App Store Connect richiede l'SDK di iOS 26, e quindi una versione recente di Xcode. Entro il 31 agosto 2026 le app su Google Play devono puntare ad Android 16, API 36, con proroga richiedibile fino al 1° novembre. Sono scadenze annuali, e vanno messe nel contratto di manutenzione: un'app ferma per diciotto mesi non è "stabile", è fuori dagli store al primo aggiornamento che serve.
Le commissioni, in Europa, sono cambiate tre giorni fa
Il 18 agosto 2026 Apple ha annunciato nuovi termini per l'Unione europea, in vigore dal 1° ottobre. Il cambiamento che conta per chi sviluppa app piccole: la Core Technology Fee, la tariffa per singola installazione, è abolita e sostituita da una commissione del 5% sulle transazioni per le app distribuite fuori dall'App Store. Le aliquote diventano 26% con pagamento Apple, 20% con pagamento alternativo, 15% con link a un checkout web, con versioni ridotte per il programma piccole imprese. Per un'app gratuita che diventa virale, il rischio economico peggiore del vecchio modello — pagare per ogni installazione — sparisce.
In sintesi
Il costo ricorrente di un'app non sono le quote degli store, sono tre voci: le build su Mac, gli aggiornamenti imposti dal calendario delle piattaforme e il collaudo su dispositivi reali. Un contratto di manutenzione annuale non è un extra da vendere: è la condizione perché l'app esista ancora fra due anni.
Le regole europee che ora fanno parte del mestiere
Dal 2025 in poi chi pubblica app in Europa ha obblighi che prima non aveva, e sono la parte del lavoro che i clienti scoprono peggio: tardi.
Identificazione del venditore (DSA). Dal 17 febbraio 2025 chi distribuisce app nell'Unione europea deve dichiarare il proprio stato di "trader", con indirizzo e contatti verificati che diventano pubblici sulla scheda dell'app. Le app senza questa dichiarazione vengono rimosse dallo store europeo — e ne sono state rimosse a decine di migliaia. Per un freelance con partita IVA che pubblica app proprie dal salotto di casa, significa che l'indirizzo di casa finisce sull'App Store: è il momento di valutare un domicilio professionale, e va detto prima, non dopo.
Store alternativi (DMA), con un asterisco grande. L'Europa ha aperto la distribuzione fuori dall'App Store, ma i requisiti per accedervi — fra gli altri, una lettera di credito da un milione di dollari oppure un milione di installazioni nell'anno precedente — mettono di fatto quella porta fuori dalla portata di un freelance o di una microimpresa. È una libertà reale per chi è grande, teorica per tutti gli altri.
Accessibilità, ed è la novità che pesa di più. L' European Accessibility Act si applica dal 28 giugno 2025 e riguarda le app attraverso cui vengono erogati servizi di e-commerce, bancari, di trasporto, di comunicazione e di media. In Italia le regole tecniche sono arrivate con la determinazione AgID n. 38 del 4 marzo 2026, pubblicata in Gazzetta Ufficiale il 24 marzo, che include una scheda dedicata proprio alle applicazioni mobili. Il punto che quasi nessuno spiega correttamente: l'obbligo ricade sull'operatore economico che eroga il servizio, cioè sul committente, non sul freelance che sviluppa in appalto. Ma si trasferisce per contratto — e un capitolato che chiede conformità senza che nessuno dei due sappia cosa significa è un contenzioso già scritto. Sapere leggere la norma tecnica, qui, è un servizio che si fattura.
In sintesi
Il freelance che nel 2026 sa dire a un cliente in quale categoria ricade la sua app, cosa deve dichiarare e cosa deve rendere accessibile non sta facendo consulenza legale: sta togliendo dal tavolo il motivo per cui quel progetto è fermo da sei mesi.
Competenze necessarie per un freelance mobile
Il framework è meno della metà del lavoro
Chi conosce solo il framework consegna un'app che gira sul simulatore. Quello che serve davvero è il resto: firme e provisioning, ciclo di vita delle app, permessi, gestione della memoria su dispositivi vecchi, comportamento quando la rete non c'è.
Saper scendere nel nativo
È la competenza che separa chi può prendere un progetto intero da chi si blocca al primo requisito fuori dal seminato. Non serve saper scrivere un'app iOS da zero: serve saper leggere codice Swift e Kotlin, capire un errore di build di Xcode o Gradle e scrivere un piccolo modulo nativo quando la libreria che serve non esiste. In tutti e tre i framework, prima o poi, quel momento arriva.
Il mestiere degli store
Schede, screenshot, dichiarazioni sulla privacy in due formati diversi, gestione delle versioni, distribuzione ai collaudatori, revisioni respinte e come rispondere. È lavoro poco appassionante ed è quello che i clienti non sanno fare da soli: si fattura, e va fatturato.
Prestazioni percepite, non misurate
Nessun utente misura i millisecondi: nota lo scatto durante lo scorrimento, l'attesa bianca all'avvio e la lista che si blocca al centesimo elemento. Saper diagnosticare questi tre casi vale più di qualunque confronto fra framework — e va detto che non esiste ad oggi un benchmark comparativo indipendente e recente fra Flutter, React Native e Kotlin Multiplatform: quasi tutto ciò che circola è materiale di agenzie che vendono uno dei tre.
Offline, sincronizzazione e conflitti
Un telefono perde la rete: è la sua condizione normale, non un caso limite. Progettare cosa succede quando due dispositivi modificano lo stesso dato è la parte più difficile di quasi ogni app aziendale, ed è anche quella che nessun framework risolve al posto tuo.
Accessibilità
Da competenza opzionale è diventata materia normata. Etichette per il lettore di schermo, contrasti, dimensioni del tocco, supporto ai caratteri grandi: sono cose che si fanno mentre si costruisce e che costano il triplo se si aggiungono alla fine.
Le competenze che non stanno nel CV
Dire a un cliente che la sua idea non ha bisogno di un'app. Stimare un progetto in cui metà del rischio sta nei requisiti degli store, non nel codice. Spiegare perché la manutenzione annuale non è un extra. Sono le competenze che fanno la differenza fra un progetto e un rapporto che dura anni.
Ruoli e abilità in un progetto di app
Sviluppatore mobile cross-platform — il centro del progetto: interfaccia, logica applicativa, integrazione con le API.
Specialista nativo iOS o Android — serve a ore, non a tempo pieno, quando bisogna scrivere un modulo che tocca funzioni di sistema o risolvere un rifiuto dello store.
Designer con esperienza mobile — non è un designer web che ridisegna più stretto. Conosce le convenzioni delle due piattaforme, le aree raggiungibili col pollice e i sistemi di design di riferimento.
Backend developer — un'app senza API è una demo. Chi progetta le API per il mobile deve pensare a payload piccoli, versioni multiple in circolazione e client che restano indietro per mesi.
Chi si occupa di build e distribuzione — certificati, pipeline, canali di collaudo. Su progetti piccoli è lo stesso sviluppatore, ed è tempo che va contato.
QA su dispositivi reali — il simulatore non riproduce fotocamera, notifiche, memoria bassa e reti lente. Serve un parco dispositivi minimo, ed è un costo.
Come si combinano
Su un progetto piccolo una persona fa tutto tranne il design. La decisione critica da prendere il primo giorno non è quale framework usare, ma chi possiede gli account degli store: devono essere intestati al cliente, con il freelance invitato come collaboratore. Un'app pubblicata sull'account personale di chi l'ha scritta è un problema che esplode il giorno in cui il rapporto finisce.
Tariffe: quanto si guadagna sviluppando app in Italia
Il dato italiano non esiste, e va detto
Nessuna delle fonti tariffarie usate in Europa copre il mobile italiano in modo affidabile. Malt non ha un barometro per l'Italia; le statistiche italiane disponibili hanno campioni di poche decine di rilevazioni e non contengono affatto i profili mobile. Ancora più interessante: né Malt né Upwork pubblicano una voce tariffaria dedicata a Flutter o a React Native — i barometri segmentano ancora per iOS, Android e Swift. È un vuoto che dice qualcosa sul ritardo con cui le piattaforme di rilevazione seguono il mercato.
I riferimenti europei utilizzabili
Il barometro 2026 di Malt in Francia colloca uno sviluppatore mobile freelance a 550 euro al giorno di media per i profili esperti — 306 sotto i due anni di esperienza, 597 oltre i quindici — con iOS a 561 e Android a 548. Sullo stesso strumento, in Spagna, la media scende a 291 euro. Un fattore 1,9 per lo stesso mestiere dentro lo stesso mercato unico: è il dato più istruttivo di tutta la sezione, e suggerisce dove si colloca realisticamente l'Italia, che sta più vicina alla Spagna che alla Francia.
Su Upwork la mediana di uno sviluppatore di app mobile è di 27 dollari l'ora, con React Native a 30: sono tariffe di un mercato globale, dove la concorrenza sul prezzo arriva da paesi con costi della vita diversi, e servono più come termine di paragone che come obiettivo.
Il riferimento da dipendente in Italia
Su Glassdoor uno sviluppatore mobile dipendente sta a 31.800 euro di retribuzione media, con base fra 26.000 e 35.000, su un campione di cinquanta segnalazioni aggiornate a luglio 2026 — sostanzialmente alla pari con un backend developer. Il riferimento più ampio disponibile in Italia resta il ruolo generico di sviluppatore su TechCompenso, con 37.779 euro medi su circa 1.900 rilevazioni e 52.363 oltre i dieci anni.
La domanda italiana, con i suoi limiti
Il 21 agosto 2026 su Indeed Italia gli annunci erano 98 per "android developer", 89 per "ios developer", 83 per "kotlin", 68 per "flutter" e 55 per "react native". Vanno letti con tre avvertenze: sono ricerche a testo libero e non si sommano, un annuncio compare in più query, e metà agosto è il minimo stagionale della pubblicazione di annunci in Italia. Come rapporti relativi però dicono due cose utili: il nativo pesa ancora più del cross-platform, e fra i due framework principali Flutter è davanti a React Native di circa una volta e un quarto.
In sintesi
La fascia realistica per un freelance mobile italiano parte dai 300-350 euro al giorno e supera i 500 su progetti con responsabilità di pubblicazione e manutenzione. Il moltiplicatore non lo dà il framework: lo danno la capacità di consegnare fino agli store, la competenza nativa che permette di non fermarsi mai, e il dominio in cui si lavora.
Cosa significa per le aziende italiane
Con un mercato diviso circa 65 a 35 fra Android e iOS, per un'azienda italiana pubblicare su una sola piattaforma significa rinunciare a un terzo del pubblico o a due terzi. Il cross-platform non è quindi una scelta di risparmio: è il modo normale di stare su entrambe con un team che si può permettere.
Il rovescio della medaglia, da mettere in preventivo con onestà: un'app è un impegno ricorrente. Ogni anno il calendario delle piattaforme impone almeno un aggiornamento tecnico, le regole europee aggiungono adempimenti, e un'app abbandonata sparisce dagli store nel giro di un paio di cicli. Se il budget copre lo sviluppo ma non i due anni successivi, la scelta corretta è spesso un'applicazione web installabile — e un consulente che lo dice sta facendo il proprio mestiere, non perdendo un lavoro.
Conclusioni
I tre approcci non competono sullo stesso terreno. Flutter porta il proprio motore grafico e vince quando l'identità visiva conta più della convenzione di sistema. React Native usa i componenti nativi, ha chiuso la sua riscrittura interna e da febbraio 2026 ha una fondazione indipendente alle spalle: è la scelta naturale per chi ha già un team React. Kotlin Multiplatform non condivide l'interfaccia e proprio per questo è l'unico che si può adottare a fette, dentro app native che già esistono e che nessuno vuole riscrivere.
La scelta si fa guardando due cose, e nessuna delle due è tecnica: la forma dell'app — comanda il disegno, la logica o l'integrazione? — e il team che la manterrà nei prossimi tre anni. Il resto, cioè store, aggiornamenti obbligatori, accessibilità e conformità europea, è identico per tutti e tre, ed è la parte che decide se il progetto sopravvive.
Per chi lavora da freelance, il messaggio dei dati è coerente: il framework è ormai una competenza di base e da sola vale poco. Quello che sposta la tariffa è saper accompagnare un'app dalla prima riga fino alla pubblicazione, saper scendere nel codice nativo quando serve e saper rispondere a un cliente che chiede "e per l'accessibilità come siamo messi?". Se stai valutando anche il lato server della stessa applicazione, la scelta del framework backend è un discorso a sé: ne abbiamo parlato nella guida a Python per lo sviluppo web e le API.
Domande frequenti
Meglio Flutter o React Native nel 2026?
Dipende da chi scrive il codice. Se il team viene dal web ed è a suo agio con React, React Native fa risparmiare mesi di apprendimento e permette a una persona sola di lavorare su web e app. Se il team parte da zero o l'app deve avere un'identità visiva molto curata, Flutter è più lineare: un linguaggio, un comando di build, un solo insieme di problemi. Sui numeri di adozione Flutter è avanti — è rilevato nel 25% delle app su Google Play contro il 19% di React Native — ma non è un divario che deve decidere al posto tuo.
Kotlin Multiplatform conviene se ho già due app native?
È il caso in cui conviene più di ogni altro, ed è l'unico dei tre approcci che si adotta senza riscrivere niente: si sposta un modulo alla volta — rete, database, regole di dominio — mentre le due app continuano a funzionare. Google lo supporta ufficialmente per la condivisione della logica di business e lo usa in produzione su Google Docs per iOS. Se invece l'app è nuova e piccola, condividere solo la logica fa risparmiare poco: l'interfaccia resta doppia.
Quanto costa mantenere un'app negli store ogni anno?
Le quote sono la voce minore: 99 dollari l'anno per Apple e 25 una tantum per Google. Il costo vero sono le build su macchine Mac — su GitHub Actions un minuto macOS costa dieci volte un minuto Linux — e soprattutto gli aggiornamenti imposti dal calendario delle piattaforme: nel 2026 l'SDK di iOS 26 obbligatorio da aprile e il target Android 16 entro agosto. Un contratto di manutenzione annuale non è un extra, è la condizione perché l'app esista ancora fra due anni.
Un'app cross-platform costa la metà di due app native?
No, e prometterlo è il modo più rapido di litigare con il cliente. Si dimezza la parte che sta fra il modello dati e lo schermo, che è moltissimo, ma resta doppio tutto il resto: schede degli store, dichiarazioni sulla privacy, firme e certificati, collaudo su dispositivi reali, revisioni. Su un progetto di media dimensione quella parte vale fra un quarto e un terzo del totale.
Devo preoccuparmi dell'European Accessibility Act?
Se l'app eroga un servizio di e-commerce, bancario, di trasporto, di comunicazione o di media a consumatori europei, sì: la direttiva si applica dal 28 giugno 2025 e in Italia le regole tecniche sono arrivate con la determinazione AgID 38 del marzo 2026, che ha una scheda dedicata alle app mobili. L'obbligo però ricade sull'operatore economico che eroga il servizio, cioè sul committente, non sullo sviluppatore che lavora in appalto: per il freelance la responsabilità è contrattuale, quindi va scritta nel contratto invece di essere data per scontata.
Quanto guadagna un freelance che sviluppa app in Italia?
La fascia realistica parte da 300-350 euro al giorno e supera i 500 su progetti in cui ci si prende anche la pubblicazione e la manutenzione. Le fonti italiane sono deboli — non esiste un barometro tariffario nazionale, e i profili mobile mancano dalle poche statistiche disponibili — quindi il riferimento migliore resta quello europeo: 550 euro al giorno in Francia contro 291 in Spagna sullo stesso mestiere, con l'Italia più vicina al secondo valore che al primo.