Sin dagli inizi della nostra avventura ci siamo focalizzati sullo studio e sulla ricerca delle migliori soluzioni disponibili sul mercato per la realizzazione delle app. Come accade più o meno in ogni ambito, l’esito della nostra ricerca può essere sintetizzato dicendo che il silver bullet che risolve ogni problema non esiste ma, sulla base del caso specifico, sono disponibili diverse soluzioni, ognuna con pro e contro.

Possiamo dividere le soluzioni disponibili per la realizzazione di app in due grandi famiglie: app native ed app ibride. Abbiamo già trattato questo argomento in un precedente articolo che trovate qui:

Riassumendo il contenuto dell’articolo precedente, possiamo dire che le app native:

  • Richiedono sviluppi ad hoc per ogni piattaforma (N codebase distinte), 
  • Garantiscono massime performance e possibilità di integrazione con il sistema operativo,
  • Hanno costi elevati

Le app ibride dall’altro lato:

  • Permettono di sviluppare tramite una singola codebase una app che può essere eseguita su diversi sistemi operativi
  • Richiedono competenze e costi inferiori rispetto alle app native,
  • Permettono l’integrazione con il sistema operativo tramite “plugin”,
  • E’ necessario porre molta attenzione alle performance in quanto le app ibride sono basate principalmente su WebView

Esistono dei framework “borderline” come Native Script o React Native che utilizzano un motore Javascript per l’esecuzione dell’app ma sfruttano la UI nativa del sistema operativo. Anche in questo caso però le performance sono un terno al lotto, in quanto il motore Javascript ed il relativo bridge di comunicazione possono essere un collo di bottiglia considerevole.

Le nostre esperienze

In questi anni abbiamo avuto modo di realizzare app con diverse tecnologie e valutare poi di volta in volta eventuali problematiche riscontrate durante il ciclo di sviluppo.

Per quanto riguarda le app native, abbiamo già detto praticamente tutto: il risultato ottenuto è sempre performante, ma i costi sono molto elevati e mantenere allineate diverse codebase è veramente oneroso.

Ci siamo ritrovati molto spesso a realizzare app con tecnologie ibride in quanto ci sembrava la soluzione più adatta al caso specifico. Inizialmente tutto fila liscio: una volta presa dimestichezza con il framework di turno (noi abbiamo sempre usato Ionic) si è subito produttivi e gli sviluppi procedono spediti. I problemi iniziano a palesarsi quando si inizia a testare l’app su dispositivi reali: su alcuni dispositivi l’app è perfetta, fluida e responsiva, su altri arranca vistosamente. Paradossalmente i dispositivi più problematici sono quelli marchiati Apple: ci è capitato ad esempio che solo su alcuni modelli di iPad l’app avesse dei vistosi glitch grafici se nella pagina era presente un tag <ul>! Vi sembrerà assurdo, ma è così. La nostra esperienza con le app ibride è quindi agro dolce: se da un lato effettivamente è possibile essere produttivi ed efficaci in poco tempo, ottenendo dei risultati veramente validi, dall’altro il fattore “bug random sul dispositivo X” è sempre in agguato e praticamente impossibile da stimare in termini di tempi e costi.

Quindi?

Tutto questo per argomentare quanto detto all’inizio ovvero, scordiamoci il silver bullet per la realizzazione delle app. Ma è davvero così?  Siamo destinati per sempre ad app dai costi elevati oppure vincolate alle performance di un browser? Fino a poco tempo fa sembrava così, ma poi è stato rilasciato Flutter.

Cos’è Flutter

Flutter è un framework realizzato da Google, basato su Dart, per la realizzazione di app. Tuttavia è profondamente diverso sia dalle app native che dalle app ibride analizzate in precedenza in quanto permette di realizzare tramite una singola codebase una app che può essere poi eseguita su diverse piattaforme, ma non lo fa ne tramite una WebView ne tramite un bridge Javascript e garantisce quindi performance native.

Come funziona

Flutter usa un approccio reattivo: non dovremo quindi mai preoccuparci di mantenere sincronizzata la UI con lo stato logico dell’applicazione: per ogni Widget dovremo solo definire la struttura ed informare Flutter ogni volta che aggiorniamo lo stato del Widget stesso. Sarà il framework poi a decidere il modo più efficiente per aggiornare la UI tramite appositi algoritmi.

Da un punto di vista grafico, Flutter mette a disposizione tantissimi widget dal look and feel nativo, sia per Android che per iOS. Attenzione però: non sono i veri widget nativi di Android e iOS, ma sono una copia (praticamente perfetta) realizzata da zero dal team di Flutter. Questo permette di svincolarsi completamente da eventuali modifiche apportate ai widget dai relativi sistemi operativi e offre ovviamente, la possibilità di profonde e radicali personalizzazioni.

Per quanto riguarda invece l’interfacciamento con il sistema operativo, avviene tramite un meccanismo molti simile ai “plugin” delle app ibride. L’ecosistema di plugin disponibile online è in rapida espansione, ma al momento non è assolutamente paragonabile all’ecosistema di ionic native o, più in generale, di Cordova.

Developer experience

Un aspetto su cui noi sviluppatori ci focalizziamo sempre troppo poco quando valutiamo un framework è l’esperienza di sviluppo che propone. Su questo aspetto Flutter è quasi commovente in quanto offre un Hot Reload come i migliori framework Javascript del momento. Sembra una cosa da poco, ma attendere 2 secondi invece di 30 fra la modifica del sorgente e la visualizzazione del risultato, a fine giornata, fa la differenza. 

A differenza dei framework come Ionic che si basano su tecnologie web, Flutter si basa su Dart, un linguaggio ideato anch’esso da Google. Questo inizialmente temevamo potesse essere un ostacolo, ma in realtà Dart è solo l’ennesimo linguaggio ad oggetti, nulla di impossibile da assimilare in tempi rapidi.

Concludendo

La nostra unica preoccupazione al momento resta legata alla poca maturità del framework: viviamo in un periodo in cui i framework nascono e vengono abbandonati nel giro di pochi mesi o anni e Google, a questo proposito, è abbastanza famosa per non farsi troppi problemi a chiudere i progetti che non hanno il successo sperato (basta guardare ad esempio Polymer).

Che dire quindi? Abbiamo già utilizzato Flutter su un paio di app e i risultati ottenuti sono assolutamente in linea con le aspettative. Il framework è veramente giovane, e certe cose che diamo per scontate mancano. Il framework però funziona, è semplice da utilizzare e l’hot reload è veramente una manna dal cielo. Di questo passo Flutter diventerà il nostro standard per lo sviluppo di app, mettendo finalmente fine all’annosa questione: app native o app ibride?