TAZIO MIRANDOLA Web Applications Developer

Mobile Web, Ibrido e Nativo a confronto

Questa è una domanda su cui si ragiona parecchio negli ultimi anni, i recenti sviluppi nella tecnica(dispositivi più veloci, tool di programmazione più evoluti) hanno cambiato il panorama rispetto a quello che abbiamo visto nel 2009-2010. Raccolgo in questo articolo i pro e i contro di ogni possibile via, alla luce delle tecniche a disposizione oggi e per sfatare opinioni diffuse che ad oggi non hanno più fondamento.

Innanzitutto, nessuna delle 4 modalità è perfetta ed esente da problemi, ogni approccio ha vantaggi e svantaggi, idealmente su due assi: qualità/controllo e tempi/costi, dipende dalle priorità e dal budget dell'organizzazione committente quale tradeoff sia prioritario.

HTML5: Single Page Application e web Responsive

• si evita la burocrazia(costi e tempi) dell'AppSstore, l'app può essere modificata in modo continuo, anziché 2/3 volte l'anno come con ilmetodo Nativo.
• con l'eccezione delle push notifications, praticamente tutte le funzioni native sono disponibili su tutti i devices. Ma il grado di controllo che si ha a disposizione non è lo stesso.
• una codebase unica per tutte le piattaforme. questo significa che i costi di sviluppo e mantenimento sono anche 10 volte inferiori(10x) al sistema nativo. questo è il sistema più economico
• sostanzialmente, non funziona offline(senza connessione di rete).
• l'applicazione non sarà mai scorrevole e veloce come una applicazione nativa, tuttavia con le tecniche giuste(backbone,react) si arriva a risultati accettabili nella maggioranza dei casi.
• non si tratta di adattare la grafica di una applicazione tradizionale legacy, ma di riscriverla con il paradigma Single Page Application e altre tecniche moderne, altrimenti il risultato sarà per lo più inutilizzabile
• la user experience tipica di una piattaforma va rispettata/occorre tenerne conto.
• HTML5 è il sistema più facile per i dipartimenti IT da gestire(utenze,sicurezza,installazione dei client, magari su vecchi dispositivi,gestione degli ospiti,revoca delle utenze,backup dei dati,problemi di connettività,gestione dei bugs). praticamente tutte le app di tipo business possono essere realizzate con successo con questa tecnica.

Cordova/PhoneGap: HTML5 in applicazione nativa

• può accedere a tutte le capacità della piattaforma nativa attraverso plugin.
• funziona offline.
• funziona su iOs, Android, Windows. permette di scrivere e testare l'app una volta sola e iniziare a lavorare su tutte le piattaforme.
• per sviluppare e debuggare i plugin occorre comunque conoscere la piattaforma nativa.
• l'app risulterà leggermente più pesante confrontandola con un equivalente completamente nativo, ma più veloce di una app web.
• sviluppare in questo modo è molto più economico rispetto al sistema nativo, per capirci almeno 2/3 volte meno per ogni piattaforma target.
• permette un forte riutilizzo delle competenze necessaria alla presenza web(ecommerce, sito istituzionale, intranet) e al backend aziendale
• richiede approvazione Apple AppStore.
• è comunque necessario avere un mac e l'account sviluppatore ($99/yr o $399/yr for enterprise)
• la gestione risulta più impegnativa per i dipattimenti IT aziendali perché i dati vengono distribuiti fuori dal perimetro dell'organizzazione.
• adatto a gestire centinaia di utenze, il limite è dato dal back-end, come per le app native.

Xamarin/FireMonkey: cross-platform native

• le prestazioni sono praticamente indistinguibili da quelle di una applicazione swift/java
• funziona offline
• parte del codice(circa 30%) non sarà perfettamente portabile su tutte le piattaforme, tuttavia si riutilizza le stesse competenze, linguaggio librerie strumenti di sviluppo
• il carico cognitivo è paragonabile agli altri metodi nativi, ma si riutilizzano le competenze su più piattaforme, risparmiando tempo o migliorando la qualità
• la disponibilità di soluzioni pronte per la piattaforma è minore
• costi degli strumenti di sviluppo aumentano, ma sono ben spesi perchè permette sensibili risparmi di tempo
• questo non elimina il passaggi da AppStore
• è comunque necessario avere un mac e l'account sviluppatore ($99/yr o $399/yr for enterprise)
• la gestione risulta più difficile per i dipattimenti IT aziendali
• il costo maggiore è giustificabile se l'applicazione è usata da centinaia di utenze

altri prodotti che rientrano in questa categoria:

• React Native (Facebook )
• NativeScript (Telerik )
• Titanium (Appcelerator)
• j2objc (Google)

Nativo: migliore qualità, grossa spesa

• è necessario avere un mac e l'account sviluppatore ($99/yr o $399/yr enterprise)
• il carico cognitivo e l'investimento in termini di tempo per acquisire l'esperienza necessaria sono significativi, questo tipo di applicazioni se non sviluppate correttamente portano a risultati deludenti
• il supporto e la documentazione migliore da parte di apple sarà sempre su ObjectiveC/XCode. stesso vale per Google e Microsoft.
• concentrarsi solo su una piattaforma e ignorare tutte le altre non è una strategia molto solida.
• è il modo più lento di sviluppare e testare. non è possibile riutilizzare codice tra le diverse piattaforme. se il time-to-market deve essere breve questa scelta è penalizzante.
• se ben sviluppata, permette di ottenre i risultati migliori. il difficile è capire se valga la spesa necessaria per arrivarci. direi che non vale la pena per 10-100 client(meglio le soluzioni descritte in precedenza), mentre può essere ragionevole per almeno 500+ utenze
• è necessario il passaggi da AppStore, che aumenta i costi di gestione e testing
• la gestione risulta più difficile per i dipattimenti IT aziendali per le ragioni descritte in precedenza

non esiste una soluzione perfetta, la via nativa da potenzialmente risultati qualitativamente migliori ma costa dalle 4 alle 10 volte più di una soluzione bsata su web o cordova. la tua azienda ha reale necessità o altre soluzioni sono sufficienti? la tua azienda ha badget sufficiente?

il mio suggerimento prima di spendere è chiarirsi le idee vedendo dei prototipi, partendo dalle soluzioni meno impegnative e arrivando se necessario a quelle più costose e dai tempi di realizzazione più incerti, nel caso ci sia bisogno.

Sconsiglio vivamente di confrontare le proprie esigenze, magari limitate a decine o poche centinaia di utenze, con aziende digitali che investono milioni di dollari, essendo il loro core business, e hanno milioni di utenti da servire(gli ovvi paragoni con Facebook e Twitter), occorre invece concentrarsi su ciò che è possibile ottenere realisticamente con i budget a disposizione.

Una possibile soluzione è un investimento che diversifichi su più metodi di sviluppo senza legarsi eccessivamente a una sola strada. Ad esempio affiancare all'applicazione web l'applicazione cordova multipiattaforma ed eventualemnte se il budget e i ritotni lo permettono, una app nativa mirata su una piattaforma.

Un paoi di considerazioni finali: innanzi tutto ci sono ancora moltissimi clienti da servire che necessitano dell'applicazione web tradizionale e si collegano con un pc desktop, in alcuni contesti questi utenti sono numericamente importantissimi e vanno serviti al meglio, l'app mobile poi utilizza i dati esposti dal vostro sistema informativo aziendale attraverso webservice, anche detto back-end, anche questa parte della soluzione va curata ed è inprescindibile. In secondo luogo sia lo sviluppo di una soluzione web o ibrida, sia a maggior ragione la soluzione nativa, pone problemi tecnici di sviluppo/manutenzione, responsabilità e sicurezza dei dati non trascurabili, non va presa alla leggera, per cui avrete comunque bisogno per ottenere risultati di professionisti con solide basi tecniche.