Rispondi a 12 domande su prodotto, team e vincoli. Ottieni una raccomandazione motivata, il confronto di costi e prima release con il nativo e i punti a cui fare attenzione.
Scegli il mio stack
Lo strumento mostra quale stack si adatta meglio alle tue risposte e cosa ha fatto pendere la bilancia. Costi e tempi sono relativi al nativo e basati sui nostri articoli pubblicati: sono indicazioni di pianificazione, non un preventivo. Sviluppiamo in tutti e cinque gli stack, quindi il risultato segue le tue risposte, non le nostre preferenze.
Ogni risposta aggiunge punti ad alcuni stack e ne toglie ad altri, da −2 a +2. I punti vengono moltiplicati per il peso della domanda (da 1 a 3) e sommati. Il totale viene scalato su un punteggio di adattamento da 0 a 100. Le risposte “Non so” non aggiungono nulla e abbassano la fiducia; restano fuori dalla scala, così non spingono i punteggi verso il centro.
Alcune risposte impongono limiti rigidi. Se l’app ha bisogno di Bluetooth in background, dati sanitari, widget, NFC, CarPlay o di una fotocamera personalizzata, la PWA viene limitata a 20: una web app non accede a queste funzioni come un’app nativa. I limiti più morbidi tolgono qualche punto e vengono mostrati come punti di attenzione.
La fiducia è alta quando il primo classificato è avanti di 12 punti o più e sei stato sicuro di quasi tutte le risposte. Quando i primi due sono entro 6 punti, lo strumento lo segnala: hai due opzioni vicine e la scelta dipende dal tuo team e dalla roadmap.
| Domanda | Peso |
|---|---|
| Quali piattaforme ti servono al lancio? | 3 |
| Che tipo di prodotto è? | 2 |
| Come deve essere l’interfaccia? | 2 |
| Quali funzioni del dispositivo servono all’app? | 3 |
| Come deve funzionare l’app senza connessione? | 1 |
| Requisiti di sicurezza e conformità | 1 |
| Quali competenze ha già il tuo team? | 3 |
| Cosa hai già? | 2 |
| Come otterranno l’app gli utenti? | 2 |
| Quando ti serve la prima release? | 2 |
| Cosa conta di più per il budget? | 2 |
| Quanto deve durare l’app senza essere riscritta? | 1 |
| Stack | Quando | Effetto |
|---|---|---|
| PWA | L’app ha bisogno di Bluetooth in background, AR o fotocamera personalizzata, dati sanitari, widget o app per smartwatch, NFC o CarPlay | limitato a 20 · Non adatta: una PWA non accede a questa funzione del dispositivo come un’app nativa. |
| PWA | L’app deve essere su App Store e Google Play | −10 punti · Per la pubblicazione negli store serve un wrapper (Capacitor o Trusted Web Activity). |
| PWA | Offline-first con sincronizzazione | −8 punti · Su iOS lo storage offline delle web app è limitato e il sistema può cancellarlo. |
| iOS + Android nativo | Prima release entro 3 mesi e costo più basso | −10 punti · Due codebase raramente stanno in un brief da 3 mesi al costo più basso. |
| Kotlin Multiplatform | Nessuna competenza Kotlin nel team e nessun fornitore | −8 punti · Servono competenze Kotlin nel team. |
| Kotlin Multiplatform | Prima release entro 3 mesi | −6 punti · Ecosistema più giovane: prevedi tempo extra. |
| Flutter | Serve il web e il prodotto è di contenuti o media | −8 punti · Flutter sul web è più debole per i contenuti che vivono di traffico dalla ricerca. |
| React Native | Prodotto con grafica intensiva o stile gioco | −8 punti · Per una UI con rendering intensivo sono più adatti Flutter o il nativo. |
Flutter / Dart: una codebase per iOS e Android, più web e desktop
Il toolkit UI di Google in Dart. Disegna ogni pixel da sé, quindi un design di brand su misura e le animazioni appaiono identici su iOS e Android. Un team, una codebase e build web e desktop dallo stesso codice. I compromessi: un bacino di talenti più piccolo rispetto a JavaScript, e le nuove funzioni di piattaforma arrivano tramite plugin, a volte in ritardo.
React Native (incl. Expo): JavaScript / TypeScript, componenti UI nativi
Il framework di Meta in JavaScript o TypeScript, con Expo come toolchain predefinita e la nuova architettura attiva di default. Renderizza veri componenti di piattaforma, quindi le schermate standard sembrano di casa su ogni OS. Dà il meglio quando il tuo team scrive già in React o quando l’app condivide logica con un prodotto web. La grafica personalizzata pesante è il suo punto debole.
Swift / SwiftUI per iOS e Kotlin / Compose per Android: due codebase
Due app, ciascuna nel linguaggio e nel toolkit UI della propria piattaforma. Ottieni ogni nuova funzione dell’OS dal primo giorno, il miglior accesso all’hardware come Bluetooth, dati sanitari, widget e fotocamera, e la sensazione più familiare. Il prezzo sono due codebase: circa 1,4–1,8 volte il costo di sviluppo di un’app cross-platform e due team da tenere allineati.
Kotlin Multiplatform: logica di business condivisa, UI nativa o Compose Multiplatform
Condivide in Kotlin logica di business, networking e dati, mentre ogni piattaforma mantiene una UI nativa, oppure usa Compose Multiplatform per le schermate condivise. È adatto ai team che hanno già app native o sviluppatori Android e vogliono meno duplicazione senza riscrivere tutto. L’ecosistema è più giovane: prevedi tempo extra per tooling e integrazione iOS.
Progressive Web App, con eventuale pacchetto Capacitor o TWA per gli store
Una web app che si installa sulla schermata Home e funziona offline entro i limiti del browser. È la strada più economica e veloce quando basta un link o un codice QR e l’app è fatta soprattutto di contenuti e moduli. Su iOS notifiche push, attività in background, storage e accesso al dispositivo sono più limitati che in un’app nativa, e per gli store serve un wrapper.
| Fonte | Cosa ne prendiamo |
|---|---|
| Sviluppo di app native vs cross-platform nel 2026 | Il cross-platform costa il 55–70% del nativo; la prima release è più veloce del 30–40%; il nativo richiede 8–14 settimane |
| Web app vs nativo vs PWA nel 2026 | Una PWA richiede 5–8 settimane e 40–100k $ contro 80–250k $ per il nativo; limiti delle PWA su iOS |
| Costo di manutenzione di un’app mobile nel 2026 | La manutenzione costa il 15–25% dello sviluppo all’anno e il 30–50% il primo anno; il cross-platform costa il 20–35% in meno da mantenere |
| React Native vs Flutter nel 2026 | Dove si adatta ciascun framework e dove entra in gioco Kotlin Multiplatform |
I valori di Kotlin Multiplatform e PWA sono nostre stime tra le cifre pubblicate e sono in attesa di revisione da parte del nostro mobile lead.
Dipende dal tuo team e dall’interfaccia. React Native è adatto ai team che scrivono già in React o condividono codice con una web app; Flutter è adatto a un design di brand su misura e alle animazioni. Lo strumento valuta entrambi in base alle tue risposte, e il nostro confronto React Native vs Flutter approfondisce il tema.
Quando l’app dipende da funzioni di piattaforma come Bluetooth in background, dati sanitari, widget, CarPlay o una fotocamera personalizzata, quando deve sembrare esattamente parte dell’OS, o quando sicurezza rigorosa e lunga durata contano più del costo di sviluppo. È anche la scelta naturale per una sola piattaforma.
Kotlin Multiplatform condivide la logica di business tra iOS e Android, mentre ciascuna piattaforma mantiene un’interfaccia nativa. È adatto ai team con app native esistenti o sviluppatori Android che vogliono meno codice duplicato senza riscrivere tutto. L’ecosistema è più giovane, quindi prevedi tempo extra.
Spesso sì per contenuti, moduli e strumenti interni che si aprono da un link. Su iOS le web app hanno limiti più stretti su notifiche push, attività in background, storage e accesso al dispositivo, e nell’UE il supporto iOS alle web app sulla schermata Home è cambiato con il Digital Markets Act. Verifica il comportamento attuale prima di decidere.
Flutter e React Native costano di solito il 55–70% di due app native, quindi risparmi il 30–45%. Più codice specifico di piattaforma serve all’app, minore è il risparmio. Lo strumento adatta la cifra alle tue risposte e mostra la fascia.
Dai nostri progetti: il nativo richiede 8–14 settimane, Flutter e React Native sono più veloci del 30–40%, circa 5–9 settimane, e una PWA richiede 5–8 settimane. Kotlin Multiplatform si colloca nel mezzo. Il perimetro del progetto sposta questi numeri più dello stack.
Ogni risposta aggiunge o toglie punti a ciascuno stack, pesati in base all’importanza della domanda. I limiti rigidi penalizzano uno stack che non può soddisfare un requisito. La sezione “Come decide lo strumento” qui sopra elenca ogni domanda, peso e limite.
Sì. Sviluppiamo in Flutter, React Native, Swift e Kotlin nativi, Kotlin Multiplatform e come web app. Per questo lo strumento mostra il proprio ragionamento invece di spingere un’unica opzione.