Il dibattito sulle app mobile
Introduzione
Le app mobile e HTML5 sono due delle tecnologie più in voga al momento e hanno molti punti in comune. Le app web vengono eseguite nei browser mobile e possono anche essere riconfezionate come app native sulle varie piattaforme mobile. Grazie all'ampia gamma di piattaforme da supportare, combinata con la potenza dei browser mobile, gli sviluppatori si rivolgono a HTML5 come soluzione "scrivi una volta, esegui ovunque". Ma è davvero fattibile? Esistono ancora validi motivi per passare al nativo e, chiaramente, molti sviluppatori stanno seguendo questa strada. Questo articolo è un dibattito tra app native e web.
Ricchezza delle funzionalità
Punto: Native può fare di più
Possiamo dividere la funzionalità mobile in due dimensioni: l'esperienza dell'app stessa e il modo in cui si integra nell'ecosistema del dispositivo, ad esempio per Android, si tratta di funzionalità come widget e notifiche. Il formato nativo eccelle in entrambe le dimensioni.
In termini di esperienza con le app, le app native possono fare di più. Possono facilmente ottenere eventi di scorrimento e multitocco per le piattaforme che li supportano. In genere possono agire sui tasti fisici premuti, come il pulsante di ricerca e i controlli del volume di Android. Possono accedere anche all'hardware, come il GPS e la fotocamera. Inoltre, con l'autorizzazione dell'utente, alcune piattaforme forniscono accesso illimitato al sistema operativo. Prova a rilevare la carica residua della batteria con HTML5.
Tuttavia, non si tratta solo dell'esperienza in-app. Un sistema operativo come Android offre diversi modi per le app di interagire con gli utenti e, in effetti, con altre app. Hai widget attivi nella home page. Hai notifiche che vengono visualizzate nella barra di stato del dispositivo. Inoltre, hai gli intent, che consentono alla tua app di annunciarsi come fornitore di un servizio generale che altre app potrebbero richiedere di tanto in tanto.
Controargomentazione: le funzionalità native possono essere migliorate e il web sta recuperando terreno
È vero che molte funzionalità in-app sono semplicemente fuori portata per un'app HTML5. Non importa quanto siano elevate le tue competenze web, se la tua app è bloccata in una sandbox senza API della fotocamera, non scatterà foto a breve. Fortunatamente, non devi trovarti in quella sandbox. Se hai davvero bisogno che la tua app web scatti una foto, puoi creare un'app nativa con una visualizzazione web incorporata che fornisca la maggior parte dell'interfaccia utente. È così che funziona il framework open source PhoneGap: colma il divario esponendo le funzionalità native come servizi web, che la visualizzazione web chiama utilizzando un'API di rete standard. Quando crei un'app ibrida come questa, puoi anche sfruttare le funzionalità della piattaforma come widget, notifiche e intent.
Creare un'app ibrida, nativa e web, non è certo la soluzione ideale. Aumenta la complessità e si applica solo alle app web incluse come app native, anziché ai siti web tradizionali a cui si accede da un browser mobile. Ma potrebbe non essere necessario a lungo. Gli standard web si evolvono rapidamente e i browser mobile moderni tengono il passo. Archiviazione offline, geolocalizzazione, grafica canvas e riproduzione di video/audio sono tutte funzionalità ampiamente supportate dagli smartphone moderni, ad esempio. Anche la fotocamera sta iniziando a essere supportata. A partire da Android 3.1, è possibile acquisire foto e video utilizzando gli standard web. Inoltre, l'ultima versione del browser iOS supporta WebSocket per lo streaming bidirezionale, nonché il rilevamento dell'orientamento del dispositivo.
Nel complesso, il mobile è in continua evoluzione. Ma anche il web si sta evolvendo, e rapidamente. Solo tra i browser desktop, esistono cinque principali fornitori di browser che evolvono gli standard e aggiungono funzionalità a una velocità fulminea. Sebbene non sia un processo banale portare queste funzionalità sui dispositivi mobili, molte di loro sono già state integrate nei browser mobile.
Le app native sono un obiettivo in rapido movimento, ma il web sta colmando il divario.
Rendimento
Punto: l'app nativa viene eseguita più velocemente
Le app native non devono affrontare la barriera del runtime web. Vengono eseguiti in modo nativo e possono sfruttare i miglioramenti delle prestazioni come l'accelerazione GPU e il multithreading.
Controargomentazione: i runtime web sono molto più veloci oggi e la maggior parte delle app non ha comunque bisogno di questa velocità
Sarebbe riduttivo dire che il web è diventato più veloce negli ultimi anni. V8, il motore JavaScript fornito con Chrome, è stato uno sviluppo importante nelle prestazioni web al momento del lancio e, da allora, è diventato sempre più veloce:
Anche i motori di rendering grafici hanno velocizzato il web e ora sta iniziando a verificarsi l'accelerazione hardware. Dai un'occhiata al rallentamento fornito da hardware accelerated-canvas:
Inoltre, la nuova API Web Workers rende possibile il multithreading e gli sviluppatori web moderni possono anche utilizzare una serie di librerie ottimizzate per il rendimento e tecniche di ottimizzazione del rendimento ben studiate. Anche se la maggior parte di queste è nata sul web da computer, sono ancora pertinenti per il mobile e c'è una maggiore attenzione al mobile, ad esempio l'esperto di rendimento Steve Souders ha una pagina dedicata agli strumenti per il rendimento sui dispositivi mobili.
Non tutti i progressi compiuti sui computer sono ancora disponibili su tutte le piattaforme mobile, ma le tendenze indicano che sono in arrivo. È anche importante notare che la maggior parte delle app mobile non sono giochi 3D all'avanguardia, ma si basano fondamentalmente su informazioni: notizie, posta, orari, social network e così via. Visita alcuni siti da dispositivo mobile, ad esempio Gmail, Amazon, Twitter, e potrai verificare che le prestazioni del web mobile sono più che adeguate. Per quanto riguarda i giochi, quelli di base sono già fattibili con la tela 2D e WebGL sta iniziando a comparire sui dispositivi mobili. Vedi Firefox 4. Fino a quando non sarà ampiamente diffuso, esiste una famiglia crescente di framework che compilano app WebGL in app native che possono sfruttare OpenGL, ad esempio ImpactJS.
Esperienza di sviluppo
Punto: le app native sono più facili da sviluppare
Le app native utilizzano linguaggi di programmazione robusti (ad es. Java, Objective C, C++) progettati per lo sviluppo di applicazioni complesse e con una comprovata esperienza. Le API sono state progettate da zero per supportare la piattaforma in questione. Puoi eseguire facilmente il debug delle app negli emulatori desktop che forniscono una rappresentazione fedele del dispositivo di destinazione.
Ciò che rende lo sviluppo web particolarmente problematico è l'enorme diversità di browser e runtime. Quando l'app viene eseguita, non è garantito che la funzionalità X sia disponibile. E anche se lo è, come lo implementerà il browser? Gli standard sono aperti all'interpretazione.
Controindicazione: il web è spesso più facile da sviluppare, soprattutto se il targeting è rivolto a più dispositivi
Iniziamo dalla tecnologia di base. È vero che gli standard web sono stati originariamente concepiti in un'epoca in cui il web era fondamentalmente basato su documenti, non su app, con JavaScript creato e implementato in soli 10 giorni. Ma si sono rivelati molto più capaci di quanto immaginato: gli sviluppatori web hanno imparato a sfruttare le parti buone e a domare quelle cattive, con pattern ora compresi per la progettazione scalabile. Inoltre, gli standard non sono statici e iniziative come HTML5, CSS3 ed EcmaScript Harmony stanno migliorando l'esperienza degli sviluppatori. La scelta tra C++, Java o JavaScript è una questione di dibattito religioso e dipende anche dalla codebase legacy. Ma al giorno d'oggi JavaScript è sicuramente un serio contendente.
Il rovescio della medaglia della frammentazione di browser/runtime è il fatto che tutti questi ambienti esistono. Sviluppi un'app per Android in Java e devi eseguire il porting completo a Objective C per supportare iOS. Sviluppa un'app web una sola volta e verrà eseguita su Android e iOS, per non parlare di WebOS, BlackBerry, Windows Mobile e… beh, questa è la teoria. In pratica, dovrai modificare le impostazioni per ogni piattaforma se vuoi davvero ottenere l'esperienza giusta. Ma dovresti farlo anche in modo nativo per la maggior parte dei sistemi operativi mobile, in quanto esistono versioni e dispositivi diversi.
La buona notizia è che la "frammentazione" è sempre stata così sul web e ci sono tecniche ben note per gestirla. Ancora più importante, il principio del potenziamento progressivo esorta gli sviluppatori a scegliere come target un dispositivo di base e ad aggiungere strati di funzionalità specifiche della piattaforma dove sono disponibili. Anche il mantra del rilevamento delle funzionalità aiuta e, al giorno d'oggi, abbiamo il supporto di librerie come Modernizr per supportare il responsive web design. Con un uso giudizioso di queste tecniche, puoi estendere la tua copertura alla stragrande maggioranza dei dispositivi, anche ai "feature phone" di vecchia scuola, anche a fattori di forma come smartwatch e TV, indipendentemente dalla marca e dal sistema operativo. Guarda la nostra dimostrazione di più UI al Google I/O 2011, dove abbiamo preso di mira fattori di forma distinti (feature phone, smartphone, tablet, computer, TV) con un codebase comune di logica e markup.
Aspetto e design
Punto: l'esperienza nativa si adatta all'aspetto della piattaforma
Una delle caratteristiche distintive di qualsiasi piattaforma è il suo aspetto e la sua atmosfera. Gli utenti si aspettano che i controlli vengano presentati in modo coerente e manipolati nello stesso modo. Esistono alcuni idiomi che variano da piattaforma a piattaforma, ad esempio cosa succede quando l'utente esegue una "pressione prolungata" (tocca un elemento per diversi secondi)? Le piattaforme hanno espressioni standard per queste cose e non puoi soddisfarle tutte con una singola app HTML5.
Inoltre, l'aspetto della piattaforma è orchestrato dalla libreria software nativa della piattaforma, i cui widget racchiudono il tipo di aspetto che gli utenti si aspettano. Ottieni gran parte dell'aspetto previsto "senza costi" semplicemente utilizzando il toolkit nativo.
Controparte: il web ha il suo aspetto e puoi anche personalizzare l'interfaccia web per le piattaforme che ti interessano di più
Come spiegato nella sezione precedente, il modo di sviluppare il web è scrivere una versione di base "adatta a tutti" e poi migliorarla progressivamente. Anche se il miglioramento si basa in genere sulle funzionalità, puoi migliorarlo anche scegliendo come target le piattaforme che ti interessano di più. Si tratta di una sorta di "rilevamento del browser", che a volte è malvisto dalla community web, soprattutto perché esistono moltissimi browser possibili. Tuttavia, se visualizzi due o tre piattaforme con una priorità molto elevata e vuoi impegnarti di più per competere con le alternative native, questa potrebbe essere la soluzione ideale.
Per quanto riguarda la versione di base, il web ha il suo aspetto e la sua esperienza utente e possiamo persino dire che ogni piattaforma mobile ha il suo "aspetto e la sua esperienza utente web" stabilita dal browser predefinito e dal runtime web. L'aspetto web potrebbe essere adatto ai tuoi utenti e, di fatto, ti consente di ottenere un maggiore grado di coerenza con l'esperienza di navigazione da computer, nonché con quella su altri dispositivi che l'utente potrebbe utilizzare. Inoltre, esistono molte app di successo che non supportano molto l'aspetto nativo. Ciò vale sicuramente per i giochi (il tuo gioco mobile preferito segue l'aspetto del tuo sistema operativo mobile?) e anche per le app più convenzionali. Ad esempio, dai un'occhiata ai client Twitter nativi più popolari sulla piattaforma che preferisci e vedrai una vasta gamma di meccanismi di interfaccia utente in funzione.
Visibilità
Punto: le app native sono più facili da scoprire
I meccanismi di distribuzione delle app, come Android Market e l'App Store di Apple, sono stati estremamente popolari negli ultimi anni e rappresentano una delle principali forze trainanti dell'intero settore mobile. Qualsiasi sviluppatore può inviare la propria app nativa al marketplace, dove gli utenti possono scoprirla tramite una combinazione di navigazione, ricerca e ricezione di consigli. Inoltre, se hai fatto un buon lavoro, le valutazioni e i commenti positivi convinceranno gli utenti a fare clic sul pulsante di installazione, che è fondamentale.
Controargomentazione: in realtà, le app web sono più facili da scoprire
Il web è probabilmente il mezzo più facilmente reperibile mai creato. Nell'umile URL, abbiamo (almeno in teoria) un identificatore univoco per tutto ciò che è stato pubblicato sul web, incluse le app pubblicate su siti web standard. I motori di ricerca semplificano la scoperta di questi contenuti e altri siti web possono collegarsi a essi, inclusi cataloghi di app web simili ai marketplace mobile. Infatti, qualsiasi persona può condividere app web con i propri amici semplicemente inserendo un link nelle email e nei messaggi dei social network. I link possono essere inviati anche tramite SMS, in modo che gli utenti di dispositivi mobili possano fare clic sul link e avviare l'app nel browser del proprio dispositivo.
Non abbiamo ancora gli stessi marketplace in cui gli utenti possono valutare e commentare le app, ma anche questo sta cambiando. Continua a leggere…
Monetizzazione
Punto: gli annunci nativi possono essere monetizzati
"Bambino di 6 anni crea un'app durante la pausa pranzo e vende un milione di copie a 3 $l'una". Vedi spesso questo titolo di giornale di questi tempi, quindi non c'è da stupirsi che gli sviluppatori grandi e piccoli si rivolgano ai marketplace mobile per la monetizzazione. Le piattaforme mobile offrono diversi modi per consentire agli sviluppatori di addebitare direttamente il costo delle loro app. La più semplice è il pagamento una tantum per sbloccare l'app per sempre. In alcune piattaforme sono disponibili anche meccanismi di pagamento e abbonamento in-app, che sono strettamente integrati in un meccanismo coerente e sicuro. Queste nuove forme di pagamento consentono agli sviluppatori di trasformare un'app di successo in un flusso di entrate a lungo termine.
Oltre ai pagamenti in-app, puoi monetizzare con i modelli web tradizionali, come la pubblicità e le sponsorizzazioni.
Controargomentazione: è sempre stato possibile monetizzare sul web e le opportunità sono in crescita
Il web non sarebbe il motore dell'industria moderna se non ci fossero ampie opportunità di guadagno. Sebbene i meccanismi diretti di "pagamento a consumo" non si siano ancora diffusi, esistono varie nicchie in cui le soluzioni "Software as a Service" basate su abbonamento sono diventate effettivamente praticabili. Esempi includono Google Apps, la gamma di prodotti di 37Signals e le versioni premium di vari servizi email. Inoltre, i pagamenti diretti non sono l'unico modo per trarre profitto dalle app web. Esistono pubblicità online, link di affiliazione, sponsorizzazioni, promozioni incrociate di altri prodotti e servizi.
Detto questo, è perfettamente ragionevole che uno sviluppatore web legga i titoli e provi un pizzico di invidia per i pagamenti. Non puoi inviare un URL web ai marketplace nativi, quindi cosa deve fare uno sviluppatore web? Quello che devi fare è creare un'app wrapper nativa. Per ogni piattaforma di destinazione, crea un'app nativa vuota che contenga semplicemente una visualizzazione web. La visualizzazione web è il punto in cui incorpori l'app reale. A questo punto, non ti resta che inviare queste app ai vari marketplace (e, si spera, vedere i soldi entrare!). Probabilmente esistono centinaia, se non migliaia, di app basate sul web nei principali marketplace oggi, alcune delle quali così astutamente assimilate che non conosciamo nemmeno le loro app web.
Lo svantaggio è l'onere della compilazione incrociata per ogni piattaforma. È qui che può essere utile un framework esistente come PhoneGap. Ancora meglio, sono in fase di sviluppo servizi web come PhoneGap Build e Apparatio. Indica questi siti web al tuo repository di codice e otterrai un'app per Android, un'app per iOS e così via… pronte per essere inviate ai rispettivi store. Non è necessario installare SDK nativi sul tuo computer. Per creare tutte queste app native, ti servono solo un editor di codice e un browser web.
I marketplace supporteranno mai direttamente le app web, senza tutti i costi operativi del wrapping nativo? Non è ancora chiaro. Sappiamo che Google ha introdotto il Chrome Web Store l'anno scorso e anche se si applica solo al desktop, lo store ha suscitato l'interesse di altri fornitori di browser e fa parte di una tendenza generale verso i cataloghi di app web, inclusi alcuni tentativi specifici per il mobile. Il concetto di web store è ancora agli inizi, ma i segnali sono promettenti.
Conclusioni
Mi piacerebbe dichiarare un vincitore, ma al momento non ce n'è uno chiaro. Alcune app sono più adatte per le app native e altre per il web. Lo stack web ha probabilmente più slancio, ma in termini di funzionalità e qualità di esecuzione, anche le app native si muovono rapidamente. A meno che non arrivi un momento in cui le tecnologie web siano considerate di prima classe nella maggior parte dei sistemi operativi mobile, le app native saranno sempre un aspetto importante da considerare.
Una tecnica menzionata in questo articolo sono le app ibride, che potrebbero essere il miglior compromesso per alcuni sviluppatori: visualizzazione web dove è possibile e componenti nativi specifici della piattaforma dove non lo è.
Se scegli il percorso web, tieni presente gli standard web e il principio del potenziamento progressivo. Il web è una tecnologia che sa come scegliere come target la moltitudine di dispositivi e sistemi operativi esistenti. Che tu scelga di chiamarla "frammentazione" o "diversità", il web la accoglie e voi sviluppatori potete trarre vantaggio da tutto il materiale precedente disponibile.