Scrivi una volta, distribuisci ovunque: quando diventare nativo?

Write Once, Deploy Everywhere (WODE) è stata la promessa di molti framework di sviluppo negli ultimi dieci anni, il cui obiettivo è alleviare il dolore di scrivere più applicazioni native. Determinare quale percorso intraprendere è una delle decisioni più critiche che un project manager deve prendere a causa del suo alto costo di avvio, dell'impatto sul team di sviluppo e della potenziale impossibilità di invertire.

Le soluzioni ibride come Ionic sfruttano le tecnologie web per eseguire il rendering delle applicazioni su più piattaforme, ma spesso il prodotto finale non soddisfa le aspettative dell'utente in merito a un aspetto e una sensazione nativi .

Tuttavia, anche il termine "nativo" è stato recentemente confuso da framework che compilano fino a codice nativo (ad esempio, React Native, Xamarin, ecc.).

Questo articolo analizza i pro e i contro dei vari percorsi di sviluppo mobile e li valuta rispetto alla composizione del team, ai costi e all'esperienza utente nel tentativo di consentire ai product manager di prendere una decisione più informata.

Scrivi una volta, distribuisci ovunque

Il concetto di Write Once, Deploy Everywhere si riferisce alla capacità di un team di sviluppo di scrivere un'applicazione una volta, utilizzando un unico stack di sviluppo, astratto della piattaforma o delle piattaforme su cui verrà distribuita l'applicazione, mantenendo tuttavia la capacità di distribuire l'applicazione su tutte le piattaforme desiderate, ad es. Android, iOS, Windows, ecc. Idealmente, ciò si ottiene senza sacrificare la manutenibilità, le prestazioni o l'esperienza utente (UX).

Il metodo alternativo - e storico - per lo sviluppo di applicazioni mobili prevede il semplice processo di scrittura di un'applicazione separata per ciascuna piattaforma, che, ovviamente, comporta un potenziale elevato costo di tempo e risorse.

In generale, i fattori da considerare nella scelta di un percorso di sviluppo includono:

• Età del progetto
• Composizione e dimensioni del team di sviluppo
• Piattaforme desiderate per la distribuzione
• Cronologia richiesta per il mercato
• Larghezza di banda disponibile per passare a un altro percorso, se necessario

Sfortunatamente, applicare ciascuno di questi fattori a ciascuno dei percorsi disponibili, oltre a guadare tra la miriade di opinioni disponibili sull'argomento, può essere piuttosto scoraggiante. Inoltre, questo processo lascia spesso il project manager con un senso di incertezza su quale sia il percorso migliore per soddisfare i requisiti dell'applicazione.

Ad alto livello, i diversi percorsi di sviluppo mobile possono essere suddivisi in due categorie: nativi o WODE, ovvero nativi o altro. In parole povere, si scrive un'applicazione nativa oppure no. La categoria WODE è ulteriormente suddivisa in due gruppi:

• Framework ibridi : quelli che sfruttano le tecnologie Web per eseguire il rendering di applicazioni su più piattaforme.
• Framework non ibridi : quelli che utilizzano componenti dell'interfaccia utente nativi (ad es. pulsanti, campi di testo e persino gestori di layout) invece di eseguire il rendering di una vista Web all'interno di un'applicazione come fanno i framework ibridi.

La maggior parte dei framework WODE sono ibridi ; tuttavia, al fine di migliorare sia le prestazioni che i limiti UX dei framework ibridi pur fornendo i vantaggi di un framework WODE, l'attuale tendenza è verso il non ibrido . A causa di questa tendenza, i framework come React Native, Xamarin e Appcelerator stanno guadagnando popolarità.

Ciascuno di questi percorsi, nativo, ibrido e non ibrido, ha diversi punti di forza e di debolezza e, di conseguenza, ognuno ha diversi casi d'uso per i quali è più adatto. Il resto di questo articolo analizza i pro ei contro di ogni percorso di sviluppo mobile quando si considerano le priorità concorrenti come la composizione del team, il costo del progetto e l'esperienza utente. Con l'eccezione di alcuni casi d'uso specializzati, la scrittura di applicazioni native massimizza l'esperienza dell'utente a un costo leggermente superiore.

In generale, si applica l'adagio " ottieni quello per cui paghi ", quindi se il costo conta più dell'esperienza del cliente, nativo potrebbe non essere la scelta giusta. Tuttavia, una volta che l'UX diventa vitale, le applicazioni native diventano la scelta chiara poiché, al fine di migliorare l'UX, le applicazioni basate su WODE comportano un costo considerevole sotto forma di tempo o esperienza nativa, il che vanifica lo scopo di scegliere un non nativo percorso di sviluppo in primo luogo.

Inoltre, anche se tale costo viene pagato, il prodotto finale basato su WODE fornirà sempre un'esperienza utente inferiore rispetto alla sua controparte nativa. Di conseguenza, il nativo è quasi sempre la scelta giusta per la maggior parte dei team di sviluppo e per la maggior parte dei progetti.

Applicazioni native

Le applicazioni native sono scritte nel linguaggio principale della piattaforma data. Ad esempio, le applicazioni Android sono scritte in Java, mentre le applicazioni iOS sono scritte in Obj-C o Swift. Richiedono all'ingegnere di sviluppo di comprendere il linguaggio e le sfumature specifiche della piattaforma, che includono, ad esempio, l'integrazione di pacchetti di terze parti, la gestione del layout, l'interazione del sistema operativo (OS) e così via.

Professionisti

Altamente personalizzabile . Poiché ogni applicazione è scritta utilizzando componenti nativi, l'unico limite alla personalizzazione è l'interfaccia ai framework sottostanti, e talvolta nemmeno allora. Come attestano la maggior parte degli ingegneri di sviluppo nativi, spesso c'è un modo per svolgere un determinato compito nonostante un'interfaccia limitata.

Una semplice prova di questa idea può essere trovata sfogliando le community di supporto per una determinata piattaforma. Si troveranno numerosi esempi di come portare a termine un compito che potrebbe essere "fuori riserva", nonostante i limiti delle strutture sottostanti.

Un esempio iOS concreto di un'attività così apparentemente semplice potrebbe essere quello di mostrare una sovrapposizione a schermo intero, al di sopra di tutti gli elementi esterni dell'interfaccia utente, ad esempio una barra delle schede, una barra di navigazione, ecc. Come mostrato nella Figura 1 , questo è normalmente al di fuori dell'ambito del livello dell'interfaccia utente normale attualmente presentato. Pertanto, per avere una sovrapposizione a schermo intero, deve essere aggiunta al livello nascosto sopra la barra delle schede nello stack di visualizzazione. Questo tipo di personalizzazione è in genere possibile solo su applicazioni native.

Massime prestazioni . Come previsto, un'applicazione nativa definisce il punto di riferimento per le prestazioni. Poiché la maggior parte degli altri tipi di framework aggiunge uno o più livelli intermedi, vengono eseguiti intrinsecamente più lentamente rispetto a un'applicazione nativa.

Il più manutenibile . I sistemi operativi cambiano costantemente. Periodo. Quando lo fanno, a seconda che siano state apportate modifiche sostanziali, un'applicazione deve essere aggiornata in modo tempestivo in modo da non perdere la parte della propria base di utenti che esegue l'aggiornamento al nuovo sistema operativo. Ovviamente, meno tempo passa tra il momento in cui la modifica viene resa disponibile ai propri utenti e l'aggiornamento di un'applicazione, meglio è. Questo tempo è ridotto al minimo quando non ci sono dipendenze che devono essere aggiornate per supportare questo nuovo sistema operativo, come accade quando si lavora su un'applicazione nativa.

contro

Risorse aggiuntive . Quando si scrivono applicazioni per più piattaforme, un team di sviluppo è in genere composto da uno o più ingegneri software mobili per ciascuna piattaforma supportata. Questo, ovviamente, aumenta intrinsecamente le dimensioni e il costo di un team di sviluppo. Richiede inoltre che il team di ingegneri abbia una varietà di abilità, invece di avere una base di abilità omogenea. Questo ha il potenziale per frammentare una squadra per quanto riguarda il supporto e la collaborazione.

Ciclo di sviluppo più lento . Le app native hanno il potenziale per avere un ciclo di sviluppo più lento semplicemente perché è necessario scrivere un'applicazione separata per ogni piattaforma desiderata. Il caso estremo è quando c'è un unico ingegnere di sviluppo mobile nel team poiché ogni applicazione è essenzialmente scritta in serie.

Prestazioni basse . Potrebbe sembrare strano avere prestazioni sia come pro che come contro. Da un lato, le applicazioni native offrono allo sviluppatore spazio sufficiente per creare un'applicazione ottimizzata e ad alte prestazioni. D'altra parte, tuttavia, danno anche allo sviluppatore abbastanza corda per impiccarsi. Se non sanno cosa stanno facendo, alla fine, finiranno con un'applicazione scadente.

Nota: in generale, ciò si applica a tutti i percorsi del framework (nativo, ibrido e non ibrido). Se gli ingegneri che sviluppano un'applicazione non hanno competenze sufficienti per quello che stanno tentando, l'applicazione risultante probabilmente non soddisferà i requisiti di progettazione né sarà ben accettata dagli utenti.

Applicazioni ibride

Le applicazioni ibride vengono in genere scritte utilizzando HTML/CSS/LESS per progettare l'interfaccia utente: la "V" nel modello di progettazione MVC. La "C", o controller, viene quindi generalmente scritta in JavaScript, idealmente utilizzando un framework MVC JavaScript come AngularJS. L'uso di un framework come AngularJS consente una migliore separazione delle classi e delle responsabilità rispetto a quanto è tipicamente possibile utilizzando solo jQuery.

Un esempio di questo tipo di stack di framework ibrido sarebbe un livello di visualizzazione ionico supportato da AngularJS, che viene infine convertito e visualizzato in una visualizzazione Web sulla piattaforma desiderata utilizzando PhoneGap e Cordova. Ovviamente, questo tipo di framework WODE ha il costo di una maggiore complessità.

Inoltre, l'uso di JavaScript porta con sé le proprie limitazioni basate sul design e problemi basati sul linguaggio. L'obiettivo di questo articolo non è quello di discutere i pregi oi difetti di una sola lingua; tuttavia, come project manager, la scelta di utilizzare JavaScript nel proprio stack tecnico mobile non dovrebbe essere presa alla leggera. I seguenti sono solo alcuni esempi di articoli ben scritti sul perché JavaScript dovrebbe essere evitato, se possibile:

• Il problema JavaScript
  
• Perché non sono uno sviluppatore nativo di React

Professionisti

Team di sviluppo minimo . I framework ibridi consentono a un piccolo team di sviluppo, e in particolare a uno la cui base di conoscenze principale è lo sviluppo Web, di produrre rapidamente applicazioni semplici su più piattaforme. Ciò consente a un project manager di mantenere il suo team piccolo e di eliminare la necessità che il suo team impari le lingue native e i framework per più piattaforme.

Ciclo di sviluppo più veloce . Oltre a un team più piccolo, i framework ibridi consentono un ciclo di sviluppo più rapido durante la distribuzione su più piattaforme poiché è necessario progettare un solo livello di visualizzazione utilizzando le tecnologie Web.

contro

UX potenzialmente scadente . Lo svantaggio di dover scrivere un solo livello di visualizzazione è che uno rimane con un unico livello di visualizzazione. Ciò può comportare un'esperienza utente scadente poiché un approccio valido per tutti alla progettazione dell'interfaccia utente non riesce a conferire alla propria applicazione un aspetto confortevole e familiare agli utenti su tutte le piattaforme. Inoltre, poiché le applicazioni ibride sono essenzialmente una visualizzazione Web incorporata nell'interfaccia utente, possono dare agli utenti l'impressione di visualizzare effettivamente una pagina Web anziché interagire con un'applicazione nativa. Questa esperienza ha quasi sempre un impatto negativo sulla soddisfazione degli utenti e, in definitiva, sulla fidelizzazione.

Costoso da personalizzare . Il miglioramento dell'esperienza utente progettando interfacce utente personalizzate per ciascuna piattaforma si traduce in framework di interfaccia utente complessi e unici che possono essere costosi da creare e difficili da mantenere nel tempo. Inoltre, per creare elementi dell'interfaccia utente che aiutino a far risaltare la propria applicazione (ad es. animazione, visualizzazioni personalizzate, ecc.), è necessario creare componenti bridge personalizzati per tradurre la progettazione dell'interfaccia utente di alto livello in qualcosa che il framework di livello inferiore , come Cordova, capirà. In generale, più si personalizza e migliora l'UX di un'applicazione ibrida, più diminuisce il vantaggio di un ciclo di progettazione veloce ed economico.

Prestazioni inferiori . Poiché le applicazioni ibride rendono le visualizzazioni dell'applicazione all'interno di una visualizzazione Web, esiste un grande potenziale per commettere errori di implementazione quando si ha a che fare con i framework del sistema operativo (ad esempio, rete, Bluetooth, contatti sul dispositivo, ecc.), che si traducono in prestazioni notevolmente ridotte. Vale anche la pena notare che, anche se viene prestata molta attenzione alle prestazioni poiché tutto viene visualizzato tramite una visualizzazione web, le prestazioni massime delle applicazioni ibride saranno sempre leggermente inferiori rispetto alle loro controparti native.

Gestione dei plugin non banale . Ricordi quelle funzionalità personalizzate che il team di progettazione ha trascorso settimane a lucidare, seguite da altre poche settimane mentre il team di sviluppo ha creato i componenti del ponte necessari in modo che Cordova potesse lavorarci? Bene, non funzioneranno a meno che non ci sia un plug-in Cordova di supporto per ciò che il team sta cercando di ottenere. Ciò significa una delle due cose: o il team lo crea da solo o sarà necessario trovare un plug-in di terze parti adatto che faccia il lavoro. Sfortunatamente, il più delle volte, l'opzione due non esiste. Di conseguenza, richiede tempo di sviluppo aggiuntivo per creare i plug-in personalizzati, seguito da un impegno di supporto per la compilazione, nel tempo, per gestire la libreria in crescita di plug-in Cordova richiesti dall'applicazione. Ovviamente, quando si verificano aggiornamenti Cordova, c'è un'alta probabilità che anche questi plugin debbano essere aggiornati.

Ritardo di supporto del sistema operativo . Il problema del componente del ponte a cascata/plug-in Cordova menzionato in precedenza viene ulteriormente esacerbato quando il sistema operativo cambia la funzionalità di base. Una volta che Cordova, PhoneGap e Ionic sono stati aggiornati per supportare le modifiche, è possibile che anche i plug-in personalizzati e i componenti del bridge debbano essere aggiornati. Indipendentemente dall'ordine di grandezza richiesto da questo lavoro, si traduce in un tempo aggiuntivo durante il quale l'applicazione non supporta gli utenti finali che hanno eseguito l'aggiornamento al nuovo sistema operativo. Questo, ovviamente, è uno scenario peggiore in cui Apple o Google apportano modifiche non compatibili con le versioni precedenti, cosa che non accade mai... giusto? In generale, qualsiasi framework intermedio fuori dal controllo dello sviluppatore e che deve essere prima aggiornato serve solo a ritardare il processo. Infine, fare affidamento su un framework intermedio può essere un grattacapo per i project manager da pianificare poiché i tempi di questi framework sono così sconosciuti.

Applicazioni non ibride

Le applicazioni non ibride iniziano la loro vita proprio come le loro controparti ibride: un livello dell'interfaccia utente progettato in un linguaggio di piattaforma non nativo: React Native usa HTML/CSS supportato da JavaScript o Xamarin, che si basa su C# a causa delle sue radici .NET.

Tuttavia, è qui che finisce la somiglianza. Le applicazioni non ibride si compilano fino al codice nativo ed eseguono il rendering dell'applicazione utilizzando componenti nativi della piattaforma anziché eseguire il rendering tramite una visualizzazione Web. Ciò si traduce in una struttura WODE che, almeno in superficie, ha il meglio di entrambi i mondi.

Come discusso in precedenza, la scelta di utilizzare JavaScript non dovrebbe essere una decisione presa alla leggera e potrebbe essere un problema per un team di sviluppo che non desidera imparare o non ha interesse a utilizzare JavaScript.

Professionisti

Prestazioni superiori rispetto agli ibridi . Come ci si potrebbe aspettare, i non ibridi hanno intrinsecamente prestazioni superiori rispetto alle applicazioni ibride grazie alla loro capacità di eseguire il rendering dell'applicazione utilizzando componenti dell'interfaccia utente nativi (pulsanti, viste, gestori di layout, ecc.) invece di fare affidamento su una visualizzazione Web incorporata. Naturalmente, gli sviluppatori sono ancora liberi di scrivere un'applicazione con prestazioni straordinarie o orribili. Il vantaggio delle applicazioni non ibride è semplicemente che hanno prestazioni di base più elevate rispetto ad applicazioni ibride simili.

Team di sviluppo minimo . Analogamente ai framework ibridi, i non-ibridi consentono a un piccolo team di sviluppo, e in particolare a uno la cui base di conoscenze principale è lo sviluppo Web, di produrre rapidamente applicazioni semplici su più piattaforme. Ciò consente ai project manager di mantenere il proprio team piccolo e di precludere al team l'apprendimento delle lingue native e dei framework per più piattaforme.

Ciclo di sviluppo più veloce . Oltre a un team più piccolo, i framework non ibridi consentono un ciclo di sviluppo più rapido durante la distribuzione su più piattaforme, poiché è necessario progettare un solo livello di visualizzazione.

Iterazioni più veloci (React) . Il framework React fornisce una potente funzionalità che consente il rendering delle modifiche all'applicazione in tempo reale: non è necessario ricompilare, ricostruire, ecc. Di conseguenza, l'emulatore React è uno strumento di sviluppo incredibilmente potente che riduce drasticamente la durata di ogni implementazione ciclo.

contro

Costoso da personalizzare . Proprio come la sua controparte ibrida, quando le applicazioni non ibride richiedono il miglioramento dell'esperienza utente progettando interfacce utente personalizzate per ciascuna piattaforma, si ottengono componenti dell'interfaccia utente complessi e unici che possono essere costosi da creare e difficili da mantenere nel tempo. Ciò significa anche scrivere componenti bridge personalizzati per integrare le lacune nel supporto degli elementi nativi del framework. Come per gli ibridi, questo costo riduce i vantaggi di un ciclo di progettazione veloce ed economico, ma a differenza delle applicazioni ibride, i componenti del bridge sono scritti per ogni piattaforma desiderata nella loro lingua nativa . Ciò significa che invece di applicazioni non ibride che rappresentano un'alternativa flessibile a un team composto principalmente da sviluppatori Web, i team che scelgono il percorso non ibrido devono imparare non solo il particolare linguaggio del framework (ad es. JSX o C#) ma anche la lingua madre di ciascuna piattaforma (Java, Obj-C o Swift).

Dipendenze di terze parti . Questa limitazione assume due forme diverse. Nel caso di React Native, assume la forma di numerose dipendenze, cioè circa 650. Il risultato è che c'è una buona possibilità in un dato momento che una o più di queste dipendenze non siano aggiornate. Significa anche che, in caso di una grande modifica a livello di sistema operativo, c'è un'alta probabilità che la maggior parte o tutte queste dipendenze debbano essere aggiornate. La potenziale grazia salvifica è che Facebook usa React, quindi uno avrà il gorilla da 300 libbre nel suo angolo.

Nel caso di Xamarin, il problema delle dipendenze di terze parti è semplicemente che è estremamente difficile integrarle in primo luogo. Xamarin è a conoscenza di questo problema e fornisce uno strumento di utilità chiamato Sharpie. Lo scopo dello strumento è aiutare con alcune integrazioni, ma sfortunatamente Sharpie tenta spesso di compilare e collegare risorse errate, il che costringe lo sviluppatore a intraprendere il faticoso compito di modificare manualmente i parametri di compilazione di basso livello per completare con successo l'integrazione.

Ritardo di supporto del sistema operativo . Le applicazioni non ibride sono afflitte dallo stesso problema di quelle ibride. Qualsiasi framework intermedio che è fuori dal controllo dello sviluppatore e che deve essere aggiornato prima serve solo a ritardare il processo di aggiornamento della propria applicazione per supportare gli utenti all'avanguardia. Inoltre, come affermato in precedenza, fare affidamento su un framework intermedio può essere un grattacapo per i project manager da pianificare poiché i tempi di questi framework sono così sconosciuti.

Supporto a lungo termine (React Native) . Questo problema è specifico di React Native e riguarda il fatto strano che, ad oggi, Facebook non si è impegnato in un piano di supporto a lungo termine per il suo framework. Si può dire che questo è un rischio basso poiché l'azienda utilizza il proprio framework per le sue app mobili, ma vale la pena fare una pausa per qualsiasi project manager per considerare perché Facebook si è rifiutato di commentare l'argomento.

Scegliere l'approccio giusto

Quando il costo non è una considerazione primaria, la Figura 2 mostra che scrivere applicazioni native è quasi sempre la scelta migliore quando si sfrutta la composizione del team di sviluppo rispetto ai requisiti dell'applicazione. Quando ci sono meno ingegneri di sviluppo rispetto al numero di piattaforme desiderate, diventa un po' più interessante. In tal caso, usare React è la scelta corretta se il team ha un programma di rilascio molto serrato; altrimenti, andare nativo è ancora l'opzione migliore.

Quando il team è principalmente un team di sviluppo web ed è richiesta una UX personalizzata, è meglio che alcuni membri del team cambino cappello o aggiungano alcuni membri del team per rendere le proprie applicazioni native. Non esiste davvero un'opzione framework fattibile e gestibile se un'applicazione richiede elementi personalizzati, come fanno molte applicazioni.

Tuttavia, se non è richiesta una UX personalizzata, a seconda della pianificazione del rilascio, potrebbe essere meglio utilizzare Ionic o React. Se la propria squadra non ha tempo per imparare JSX, allora Ionic è la scelta giusta. Altrimenti, è meglio scegliere React poiché richiede già molte dipendenze di terze parti e l'aggiunta di altre non influirà sul proprio ciclo di sviluppo.

Una volta che il costo del progetto è una preoccupazione primaria, in genere, la composizione del team esistente diventa meno prioritaria poiché il primo passo sarebbe mettere in atto il team appropriato per eseguire il piano del progetto per il costo previsto. Come mostrato nella Figura 3 , le applicazioni native hanno un costo iniziale più elevato rispetto alle loro controparti WODE, ma anche una UX potenziale più elevata. Inoltre, le applicazioni WODE saranno sempre limitate nella loro UX, indipendentemente da quanti soldi e risorse vengono applicati al progetto.

Spero che questo articolo abbia fatto luce sui pro e sui contro dei vari percorsi di sviluppo mobile, oltre ad aver aiutato a valutare la composizione del team rispetto ai requisiti dell'applicazione e al costo del progetto. Il suo messaggio non era di trasmettere che i framework WODE sono inferiori e non dovrebbero mai essere cercati, ma piuttosto che anche se ci sono casi d'uso validi per non diventare nativi, si dovrebbero comprendere appieno le ramificazioni di farlo.