Flutter, React Native o nativo: come scegliere con criteri
Flutter, React Native e sviluppo nativo a confronto su prestazioni, team, manutenzione, funzioni del dispositivo e budget, per scegliere l'approccio giusto.
Team rabbitclipPubblicato: 7 min di lettura
In breve
La scelta tra Flutter, React Native e nativo è una decisione su come costruire l'app per i due store: da una sola base di codice o da codice separato per ciascuna piattaforma e, se si tratta di una sola base di codice, con quale strumento. Nativo significa scrivere codice separato per iOS e per Android e usare gli strumenti propri di ciascuna piattaforma. Flutter e React Native puntano entrambi alle due piattaforme con codice in gran parte condiviso; ciascuno è un approccio maturo e molto diffuso, creato per questo scopo. La scelta giusta non nasce da una classifica. Nasce dalle esigenze del prodotto, dalle competenze del team e dal piano di manutenzione.
Questo articolo non elogia nessuna delle parti. Mette i tre approcci uno accanto all'altro rispetto agli stessi criteri e spiega in quale situazione ciascuno comporta meno rischi. Anche i nostri articoli sulla realizzazione di un'app mobile con Flutter e su app mobile contro PWA toccano l'argomento; qui l'attenzione è su dove si collocano i tre approcci di sviluppo l'uno rispetto all'altro.
In che cosa si differenziano i tre approcci?
Nello sviluppo nativo l'app iOS è scritta nel linguaggio e con gli strumenti propri della piattaforma, e l'app Android nei suoi. Si ottengono due basi di codice. Si ha accesso per primi alle nuove funzioni di ciascuna piattaforma e il collegamento più diretto con le capacità del dispositivo, ma il lavoro viene fatto due volte.
Flutter è uno strumento che disegna da sé l'interfaccia con il proprio motore di rendering e usa il linguaggio Dart. React Native si scrive in JavaScript o TypeScript e mostra l'interfaccia attraverso i componenti propri della piattaforma. Entrambi mirano a pubblicare su due store con un solo team; si differenziano per il modo in cui viene prodotta l'interfaccia e per il linguaggio che il team conosce.
Su quali criteri conviene confrontarli?
Perché la scelta non si trasformi in un dibattito tecnologico, scriva prima i criteri e dia un punteggio a ciascuno per il suo prodotto. Se un criterio è critico per lei, decide la questione per quanto buoni possano sembrare gli altri.
A ogni criterio si pone la stessa domanda: quanto poco rischio comporta questo approccio nel soddisfare le esigenze di questo prodotto? Le risposte di solito non escono come numeri, ma come una distinzione del tipo «agevole», «richiede attenzione» e «difficile».
- Team: il linguaggio e l'esperienza degli sviluppatori che ha o può trovare
- Funzioni del dispositivo: esigenze vicine alla piattaforma, come fotocamera, sensori, Bluetooth e lavoro in background
- Interfaccia e animazione: specifica del marchio e visivamente impegnativa, oppure l'aspetto standard della piattaforma
- Manutenzione: chi seguirà gli aggiornamenti di versione e i cambiamenti delle librerie di entrambe le piattaforme, e come
- Tempo e budget: uno o due team, e quanto è urgente la prima pubblicazione
In quale situazione ciascun approccio si distingue?
Se il prodotto è molto vicino alla piattaforma, per esempio con uso intenso di fotocamera e sensori, lavoro che gira in continuazione in background, estensioni per orologio e auto, o bisogno delle funzioni più recenti della piattaforma fin dal primo giorno, il nativo di solito riserva meno sorprese. Il costo è mantenere due basi di codice e di solito due team.
Se vuole che l'interfaccia sia identica e specifica del marchio su entrambe le piattaforme e il team è disposto a imparare un nuovo linguaggio, Flutter è un candidato naturale. Se il suo team comprende sviluppatori web che già conoscono JavaScript o TypeScript, React Native è la via più breve per usare le competenze esistenti, e anche la condivisione di codice e conoscenze tra web e mobile può diventare più facile.
Queste frasi descrivono tendenze generali, non regole. App di successo, veloci e attraenti si scrivono con tutti e tre gli approcci; i problemi nascono di solito da uno squilibrio tra prodotto e strumento, non dallo strumento. Prima di decidere, quindi, una piccola prova che metta ciascun candidato davanti alla schermata o alla funzione più rischiosa del prodotto accorcia il dibattito.
Come influiscono team e manutenzione sulla scelta?
Il lavoro non finisce quando l'app viene pubblicata. Ogni anno entrambe le piattaforme rilasciano nuove versioni, le librerie cambiano e le regole degli store vengono aggiornate. Con gli strumenti multipiattaforma questi cambiamenti devono essere assorbiti sia dalla piattaforma sia dallo strumento stesso. Nel nativo lo stesso cambiamento si fa due volte in due basi di codice separate.
Conta anche il lato umano. Pensi a chi sostituirebbe la persona che conosce lo strumento scelto se se ne andasse, e a quanto siano vive la comunità e la documentazione dello strumento. Lo valuti non a occhio, ma in base alla situazione reale del suo mercato nel trovare sviluppatori in quel linguaggio.
- Chi seguirà gli aggiornamenti annuali di versione di entrambe le piattaforme
- Chi risolverà un'incompatibilità di librerie nello strumento scelto
- Con quanta facilità si può sostituire un membro del team che se ne va
- Quanto sono aggiornate la documentazione e la comunità dello strumento
Quali errori sono comuni nella scelta di una tecnologia?
L'errore più comune è lasciare la scelta alla popolarità o alle argomentazioni lette online. Uno strumento che ha funzionato in un'altra azienda può non dare lo stesso risultato con il suo team e il suo prodotto. Il secondo è dare per scontato che il multipiattaforma costi sempre meno; una sola base di codice riduce il lavoro di sviluppo, ma le parti specifiche di ciascuna piattaforma e la manutenzione richiedono comunque impegno.
Il terzo è pensare solo alla prima pubblicazione al momento di decidere. Chi manterrà l'app tra tre anni conta spesso più della rapidità con cui è uscita la prima versione.
- Lasciare la scelta alla popolarità o al dibattito online
- Dare per scontato che il multipiattaforma costi meno in ogni caso
- Pensare solo alla prima pubblicazione, senza contare la manutenzione
- Decidere senza aver provato la funzione più rischiosa
Quando questo confronto è la domanda sbagliata?
Se il suo prodotto mostra soprattutto contenuti, compila moduli e ha poco bisogno di funzioni come la presenza negli store o le notifiche, la vera domanda è se debba essere un'app mobile o una PWA; uno dei tre approcci di sviluppo discende da quella domanda. Verifichi prima che il prodotto abbia davvero bisogno di un'app.
Se è ancora alla fase dell'idea, anche scegliere una tecnologia è prematuro. Provi prima l'idea con un prototipo; la scelta sarà più sana quando sarà chiaro che cosa verrà davvero costruito. Esistono altre opzioni, ma capire il ragionamento dietro questi tre le dà anche una buona base per giudicarle.
Non esiste un'unica risposta giusta per Flutter, React Native e nativo. La risposta giusta nasce dalle esigenze del prodotto, dalle competenze del suo team e dal suo piano di manutenzione. Scriva prima i suoi criteri, provi la funzione più rischiosa in una piccola prova e conti la manutenzione oltre la prima pubblicazione. Se desidera valutare i tre approcci per il suo prodotto, può fissare un colloquio di scoperta con rabbitclip.
Domande frequenti
È meglio Flutter o React Native?
In generale nessuno dei due è migliore dell'altro; uno comporta meno rischio a seconda del linguaggio del team, delle esigenze dell'interfaccia e del piano di manutenzione. I team che conoscono o vogliono imparare Dart e desiderano un'interfaccia specifica del marchio si orientano verso Flutter, quelli che conoscono JavaScript verso React Native.
Lo sviluppo nativo è ancora necessario?
Per prodotti molto vicini alla piattaforma, come le app che richiedono molto lavoro con fotocamera, sensori o background, e quando servono le funzioni più recenti della piattaforma fin dal primo giorno, il nativo riserva meno sorprese. Per molte app aziendali non è indispensabile.
Un'app multipiattaforma costa sempre meno?
No. Una sola base di codice di solito riduce lo sforzo di sviluppo, ma le parti specifiche di ciascuna piattaforma, i test e la manutenzione richiedono comunque impegno. Il costo lo determinano l'ambito, il numero di integrazioni e il piano di manutenzione, non il nome dello strumento.
Si può passare in seguito da un approccio a un altro?
Si può, ma significa riscrivere gran parte dell'app. Per questo costa meno scegliere con cura all'inizio, provando la funzione più rischiosa in una piccola prova e contando la manutenzione.
