Esistono tre modi per selezionare la tua esperienza con lo smartphone: per operatore, per dispositivo e per app. La scelta per operatore mette al primo posto la qualità del tuo servizio cellulare, mentre prendere una decisione in base al dispositivo significa che stai cercando un'esperienza specifica della piattaforma e funzionalità hardware. Ma la scelta per app può essere più complicata.
L'attuale gamma di ecosistemi mobili è simultaneamente frammentata e unificata tra le piattaforme. Alcune app principali sono disponibili su molte piattaforme, così come le app di sviluppatori più piccoli. Altre app sono esclusive di una piattaforma in virtù di funzionalità uniche per il sistema operativo o per i vincoli di risorse dello sviluppatore. Ma se hai davvero bisogno di quell'unica app, allora l'operatore o il dispositivo non sono così importanti.
Ma cosa succederebbe se tutte le app potessero essere disponibili su tutte le piattaforme? Lo sviluppo multipiattaforma è qualcosa di cui gli sviluppatori dovrebbero preoccuparsi e ci sono trappole da affrontare nel farlo? È meglio creare un'app specifica per ogni piattaforma o l'app dovrebbe essere costruita con un framework basato sul web multipiattaforma?
Utenti e sviluppatori possono concordare sul fatto che avere un'app disponibile indipendentemente dalla piattaforma è un ottimo ideale. Ma a quale costo?
Cominciamo la conversazione!
In realtà, la domanda è più complicata. Il più delle volte "la prossima grande cosa" è stata creata da uno sviluppatore davvero talentuoso o da un piccolo team che semplicemente non ha le risorse, le competenze o le capacità per programmare multipiattaforma. Lo abbiamo visto presto con Instagram e Android: la società dietro l'app aveva notoriamente solo tredici dipendenti. Tali limitazioni hanno ritardato per un po 'di tempo un'app Instagram per Android e anche ora dopo essere stata acquistata da Facebook per un miliardo di dollari non hanno ancora rilasciato un'app compatibile con BlackBerry 10 o Windows Telefono.
La piattaforma deve spesso colpire una metrica invisibile e ambigua con cui è considerata "accettata" dalle masse.
Le piccole imprese non sono sole qui, poiché spesso vediamo enormi società di media esitare a creare app multipiattaforma. La piattaforma in questione deve spesso colpire una metrica invisibile e ambigua con la quale viene considerata "accettata" dalle masse e solo allora le aziende considereranno la possibilità di realizzare un'app per essa. Di tanto in tanto gli sviluppatori che sono "fan" di un particolare sistema operativo costruiranno prima un'app per quella piattaforma, anche se la gigantesca quota di mercato non è presente. Questo è successo con l'app ufficiale di Disqus per Windows Phone, che è stata la prima (e finora l'unica) piattaforma mobile a ottenere un'app ufficiale dal servizio di commento.
Quindi sì, le aziende dovrebbero sempre sforzarsi di passare alla multipiattaforma quando possono e, se non possono, dovrebbero contattare gli sviluppatori di quella comunità per lavorare su una partnership. Foursquare ha fatto questo quando lo sviluppatore Zhephree ha realizzato in modo indipendente un'app Foursquare per webOS nel 2009 e l'app è diventata di fatto l'app Foursquare per la piattaforma. Sfortunatamente questo è un evento raro e troppo spesso i consumatori sono gravati da selezioni di app che non includono le ultime o le più grandi semplicemente a causa della loro scelta della piattaforma mobile.
Un linguaggio di programmazione multipiattaforma come HTML5 o Unity per i giochi sarebbe d'aiuto? Gli standard sono certamente migliori del caos, anche se, come abbiamo visto finora con HTML5, è stato per lo più una campagna pubblicitaria piuttosto che un successo.
WAnche se ci sono eccezioni a ogni regola, voglio davvero vivere in un mondo in cui la maggior parte delle app mobili sono multipiattaforma e funzionano solo quando e dove voglio. Prendi il web per esempio. Posso accedere a quasi tutti i siti Web da quasi tutti i dispositivi sul mercato. Al sito web di Facebook non interessa se sono su un Mac o un PC Windows, su uno smartphone o un tablet, su Android o BlackBerry 10.
Finché la piattaforma ha un browser web moderno, posso accedere praticamente a qualsiasi sito desidero. Posso creare e distribuire un sito Web su una gamma completa di dispositivi e tutti possono vederlo. Per la maggior parte, se il sito si attiene agli standard, "funziona e basta".
Lo stato delle app mobili multipiattaforma è molto diverso.
Prendi Android Central, CrackBerry, iMore e Windows Phone Central. I siti utilizzano un codice molto simile e funzionano sulla maggior parte dei browser desktop o mobili. Quattro siti web, tutti i browser. Buon affare.
Ma farlo con le app significherebbe utilizzare framework separati, sostanzialmente diversi, per Android, BlackBerry 10, iOS e Windows Phone per ciascuna delle app dei siti. Quattro app per quattro piattaforme per un totale di sedici app. Non è un buon affare.
Lo stesso si può dire per gli accessori che si basano su app connesse. Nike + FuelBand è stato lanciato come solo iOS, ma per l'investimento che Nike ha investito nel proprio hardware, idealmente supporterebbe tutte le piattaforme. Molti utenti non iOS avrebbero potuto acquistarne uno per le vacanze del 2012, ma il fatto che FuelBand non supportasse e ancora non supporti altre piattaforme limita il suo potenziale mercato. Agli utenti non interesserebbe la multipiattaforma: tutto ciò che importa è che funzioni con il loro dispositivo.
Spero che HTML5 sia abbastanza potente e flessibile da consentirti di produrre app quasi native al suo interno. E se è così, preferirei HTML5.
- Leo LaporteCapo TWiT, TWiT.TV
Nessuno vuole un'app su BlackBerry 10 che appaia esattamente come su iOS e non include il supporto per i gesti di BlackBerry 10.
I giochi sono spesso i più avanti in questo grazie a motori multipiattaforma come Unity e Titanium. Tuttavia, i giochi tendono ad avere le proprie interfacce non conformi alla piattaforma. Le app non di gioco sono diverse. Sebbene le app possano condividere funzionalità, servizi e persino codice comuni tra le piattaforme, hanno bisogno dell'aspetto della piattaforma e possono trarre vantaggio dalle funzionalità specifiche della piattaforma. Nessuno vuole un'app su BlackBerry 10 che appaia esattamente come su iOS e non include il supporto per i gesti di BlackBerry 10.
Alla fine, se prendi i proprietari di piattaforme, i produttori e persino gli sviluppatori fuori dall'equazione, le persone vogliono solo le app che amano sui dispositivi che amano. Ciò significa che tutte le principali app devono supportare tutte le principali piattaforme. Adesso.
Tteoricamente, avere le stesse app su tutte le piattaforme dovrebbe essere un gioco da ragazzi, giusto? Più app in più posti. Ma la verità deludente è che ancora oggi non tutte le app sono create uguali.
Diverse piattaforme fanno le cose in modo diverso. A volte è una questione di hardware. BlackBerry 10 e Windows Phone non hanno la pura potenza di elaborazione di Android. L'iOS di Apple è probabilmente più facile da sviluppare e può fare di più con meno. Pertanto, un'app disponibile per iPhone e iPad potrebbe avere funzionalità diverse da quelle su Android, BlackBerry 10 o Windows Phone. In effetti, abbiamo visto istanze di app popolari che perdono una parte significativa della loro funzionalità quando vengono trasferite da una piattaforma all'altra.
La verità deludente è che ancora oggi non tutte le app sono create uguali.
Tuttavia, non è sempre così profondo. A volte è solo una questione di apparenza. Forse un'app non ha un bell'aspetto su una piattaforma come su un'altra. Superficiale? Forse. Le app dovrebbero offrire un'esperienza coerente su tutte le piattaforme. O almeno tentare di avere la stessa esperienza. Ma devono comunque avere anche un'esperienza di piattaforma. È un capello difficile da dividere.
La buona notizia è che le app sono bestie fluide. Cambiano e migliorano costantemente. Probabilmente non così rapidamente come vorremmo tutti, ma rara è l'applicazione popolare che non viene mai aggiornata, non migliora mai e non si riprogetta mai.
HLe app TML5 sono realizzate utilizzando tecnologie standard web come HTML, CSS e JavaScript. Queste app vengono eseguite nei browser, come Google Maps o iCloud.com, o su dispositivi locali come Chrome OS o il compianto webOS. Poiché così tanti sviluppatori sanno già come creare ricche esperienze web, si presume generalmente che le app HTML5 saranno il percorso più semplice per portare quegli sviluppatori su dispositivi mobili. Da qui tutto, dall'originale soluzione "dolce" di app di Apple nel browser dell'iPhone al Mojo di Palm e successivamente ai framework Enyo al WebWorks di BlackBerry.
È indotto a presumere, generalmente dai non sviluppatori, che HTML5 sia l'ultima e migliore speranza per un futuro utopico in cui le app vengono scritti una sola volta e distribuiti ovunque, multipiattaforma, dal desktop al tablet, al telefono e a qualsiasi cosa in fra.
Ed è un mucchio di BS.
La soluzione originale "dolce" di Apple ha funzionato così male che si sono affrettati a rilasciare l'App Store nativo un anno dopo, l'app di calendario su webOS 1.0 ha impiegato venti secondi per avviarsi e Google sta producendo esperienze di gran lunga migliori con le app codificate in modo nativo su Android e iOS rispetto a ragnatela. Anche le migliori app web per dispositivi mobili, come Gmail.com e forecast.io, impallidiscono rispetto ai loro cugini nativi più ricchi e con prestazioni migliori.
Le app native trarranno vantaggio dal nuovo hardware e dai nuovi framework. Il loro vantaggio rimarrà, se non crescerà.
Alcuni dicono che man mano che l'hardware diventa più potente e JavaScript viene migliorato, le prestazioni e le funzionalità delle app Web aumenteranno. È assolutamente vero. Ma le app native trarranno vantaggio dal nuovo hardware e anche dai nuovi framework. Il loro vantaggio rimarrà, se non crescerà.
Ecco perché le app HTML5 sono chiamate il futuro: arriva sempre ma non arriva mai del tutto.
Cercare di creare un'intera app in HTML5 è come provare a creare un'intera app che esiste totalmente offline, in modalità aereo. Non è impossibile, ma non è l'ideale e limita notevolmente l'ambito e l'esperienza che possono essere forniti.
Se HTML5 diventa mai più predominante delle app native, è un mondo in cui non voglio vivere.
- Matt Bischoff e Brian Capps,Ingegneri iOS, Lickability
Si tratta di questo: Internet è il migliore nel fornire dati dinamici e le app native sono le migliori per l'interfaccia e l'interattività. Le migliori app useranno il meglio di entrambi. Come iTunes. Come Google Maps per Android e iOS. Come la nuova versione nativa di Facebook per dispositivi mobili (anche Facebook ha imparato quella lezione nel modo più duro).
HTML5 non è in alcun modo il futuro delle app. Ma è una parte incredibilmente importante di quel futuro.
CLe applicazioni della piattaforma ross sono uno sforzo complicato. Gli sviluppatori devono esplorare gli SDK e le API e le guide dell'interfaccia utente e dell'esperienza utente, cercando di mantenere l'aspetto, le caratteristiche e l'esperienza unici della propria app. È un atto di bilanciamento di requisiti e desideri, aspettative e vincoli.
Idealmente le app che hanno senso essere multipiattaforma sarebbero, e sarebbe facile farlo. Ma è un mercato spietato e c'è poco interesse da parte dei proprietari di piattaforme più grandi nel rendere più facile la creazione di app che funzionerà sui dispositivi della concorrenza, mentre i giocatori più piccoli vogliono rendere il più semplice possibile il porting di quelli stessi app.
Esistono framework e strumenti multipiattaforma, ma hanno portata e potenza limitate. Semplificano la creazione di un'esperienza coerente su ogni piattaforma, ma sacrificano ciò che rende ogni piattaforma unica e compromettono qualità e prestazioni. Ma la creazione di app personalizzate per piattaforma richiede tempo e denaro che non tutti gli sviluppatori hanno.
Non c'è una buona risposta, ma qual è la migliore?