App mobile, i prossimi anni tra passaparola e HTML5

App mobile, i prossimi anni tra passaparola e HTML5

Sempre di più le app mobile, ma sempre meno saranno quelle realmente remunerative. Inoltre nei prossimi anni i browser mobile saranno sempre più utilizzati come piattaforme di distribuzione digitale

di pubblicata il , alle 13:21 nel canale Programmi
 

La società di analisi di mercato Gartner sostiene che entro il 2018 meno dello 0,01% di tutte le app mobile consumer saranno considerate un successo economico dai loro sviluppatori, questo perché il pubblico sta sempre più affidandosi ad un meccanismo di "passaparola" (tramite i pareri degli amici, con i motori di raccomandazione, sui social networking) per scoprire le applicazioni mobile invece che tramite la tradizionale consultazione del catalogo delle app disponibili sui vari marketplace digitali.

Ken Dulaney, vicepresidente e distinguished analyst per Gartner, ha commentato: "Il grande numero delle app mobile è un nuovo flusso di fatturato che porterà ricchezza a molti. Comunque sia le nostre analisi mostrano che le applicazioni mobile non stanno generando profitto e che molte applicazioni mobile non sono destinate a generare fatturato, ma sono piuttosto impiegate per costruire la percezione di un marchio e la consapevolezza di un prodotto, o semplicemente sono dei passatempi. I progettisti di app che non riconoscono tutto ciò potrebbero considerare questi profitti come inafferrabili".

La competizione è agguerrita: il mercato delle app mobile vede oltre 200 vendor che realizzano piattaforme per lo sviluppo di applicazioni e milioni di sviluppatori che fanno uso di queste piattaforme e di strumenti open source per costruire applicazioni mobile. Come se non bastasse, l'elevata qualità di molte applicazioni gratuite ha ovviamente innalzato le aspettative per quelle applicazioni per cui viene richiesto un esborso, piccolo o grande che sia.

"Vi sono così tante applicazioni gratuite e che non genereranno mai direttamente fatturato. Gartner prevede che entro il 2017 il 94,5% dei download sarà di applicazioni gratuite. Inoltre, delle applicazioni a pagamento, il 90% dei download sono meno di 500 al giorno e fruttano meno di 1250 dollari al giorno. Questo andrà solamente peggiorando in futuro quando vi sarà una maggior competizione specialmente nei mercati di successo" ha dichiarato Dulaney.

Gartner elabora altre due considerazioni aggiuntive legate al mondo mobile. Anzitutto entro il 2016 il 20% dei programmi BYOD (Bring Your Own Device) delle aziende andrà incontro ad un fallimento per via di misure MDM (mobile device management) che si riveleranno troppo restrittive.

A tal proposito osserva Dulaney: "Se tramite programmi formali BYOD o semplicemente tramite dispositivi che entrano dalla porta di servizio e vengono configurati per accedere ai sistemi dell'azienda, l'uso di tecnologie consumer nell'ambiente di lavoro presenta una minaccia al controllo dell'IT sulle risorse di computing. Molte organizzazioni implementeranno un forte controllo dei dispositivi mobile, seguendo l'iter già applicato per la gestione ed il controllo dei PC aziendali".

Molte organizzazioni IT stanno già spingendo l'adozione di soluzioni MDM per rispondere al BYOD per via della rapida crescita dell'uso dei dispositivi personali sul posto di lavoro. Con la proliferazione dei programmi BYOD, gli impiegati sono sempre più consapevoli della capacità delle organizzazioni IT di accedere alle loro informazioni personali. Di conseguenza gli impiegati mostrano un certo scrupolo nel fornire alle organizzazioni IT l'accesso ai dispositivi personali e quindi stanno richiedendo soluzioni in grado di isolare i contenuti personali da quelli di lavoro, limitando la capacità delle organizzazioni IT di accedere o cambiare i contenuti o le applicazioni personali.

L'altra considerazione di Gartner è che entro il 2017 i browser sui dispositivi mobile saranno impiegati come piattaforma di application delivery, con il 50% delle nuove web-app che useranno complessi JavaScript lato client.

Il browser mobile sta evolvendosi da un semplice motore di rendering ad una piattaforma di distribuzione delle applicazioni. La tecnologia HTML5 sarà la miglior opzione disponibile per un sistema di application delivery che sia neutrale alla piattaforma e capace di offrire applicazioni di alto livello, di elevata qualità e di convincente esperienza d'uso. Vi saranno comunque dei piccoli problemi, principalmente sul lato delle prestazioni, della frammentazione e della non completa maturità dei sistemi, con cui gli sviluppatori si troveranno ad avere a che fare per qualche anno. Gli sviluppatori dovrebbero inoltre riconoscere e prestare attenzione a quei vendor che cercano di vincolarli a caratteristiche browser-specific.

"Almeno tre piattaforme (Android, iOS e Windows) guadagneranno quote di mercato significative nel mondo smartphone, tablet e PC, costringendo molte organizzazioni al supporto di molteplici piattaforme per le applicazioni rivolte ai consumatori e agli impiegati. Sebbene esista oltre un centinaio di strumenti di sviluppo platform independent, molti di questi implicano compromessi tecnici o commerciali, come un vincolo a tecnologie relativamente di nicchia o a piccoli vendor. Questo porterà a crescere l'interesse in HTML5 come una soluzione di distribuzione in qualche modo standardizzata, ampiamente disponibile e neutrale alla piattaforma" ha concluso Dulaney.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

13 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
birmarco14 Gennaio 2014, 15:16 #1
Al momento le app HTML5 sono le peggiori e scegliere l'accoppiata HTML5+JS per realizzare una propria app è tirarsi la zappa sui piedi dato che lo sviluppo è più lento e ricco di problematiche.

Invece credo diventerà molto più importante il C#, attualmente utilizzabile su iOS, Android e ovviamente Windows e che permette la realizzazione di applicazioni native multipiattaforma scrivendo gran parte del codice una volta sola.

Senza considerare lo spostamento delle app verso sistemi più potenti come i PC e allo stesso tempo l'aumento delle capacità dei dispositivi ultramobile.

Il tempo dei browser è finito, era l'epoca fino a 2 anni fa circa quando realtà come Zynga facevano soldi a palate con browser game. Ora invece sono quasi fallite e tutti preferiscono l'app, sia per le prestazioni sia per la comodità di fruizione. E non credo che trasferire le app in un browser nascosto possa migliorare la situazione.

Riguardo al fatturato generato dalle app, è ovvio sia un mercato destinato alla saturazione e alla sopravvivenza di pochi big. Il mondo dei telefoni è oggi simile al mondo dei PC all'epoca della silicon valley di Jobs e Gates, anche un ragazzetto in un garage può diventare milionario anche un dev singolo può guadagnare dei soldi facendo app. Ma in futuro sarà come i programmi per PC, sono talmente tanti e complessi che solo quelli delle grosse SW riescono ad andare avanti
recoil14 Gennaio 2014, 15:27 #2
nella mia società usiamo un approccio ibrido con parti native (objective c, java...) e HTML+JS per la presentazione dei dati
riusciamo a riciclare gran parte del codice tra le varie versioni e manteniamo alcuni dei vantaggi (specialmente le prestazioni) derivate dall'utilizzo di funzionalità native
ci sono progetti interessanti come xamarin per essere multipiattaforma con il minimo sforzo ma preferiamo il nostro approccio con tanto HTML, perché realizzare una WebApp che emuli le nostre app native diventa quasi immediato

per quanto riguarda il fatturato noto che già ora il mercato si sta saturando ed è difficile entrarci con una nuova idea
rendono di più le app B2B o quelle enterprise per le quali sei pagato dal cliente per una soluzione custom, ovviamente non è un mondo alla portata del piccolo sviluppatore
Ventresca14 Gennaio 2014, 15:30 #3
Originariamente inviato da: birmarco
Al momento le app HTML5 sono le peggiori e scegliere l'accoppiata HTML5+JS per realizzare una propria app è tirarsi la zappa sui piedi dato che lo sviluppo è più lento e ricco di problematiche.

Invece credo diventerà molto più importante il C#, attualmente utilizzabile su iOS, Android e ovviamente Windows e che permette la realizzazione di applicazioni native multipiattaforma scrivendo gran parte del codice una volta sola.

Senza considerare lo spostamento delle app verso sistemi più potenti come i PC e allo stesso tempo l'aumento delle capacità dei dispositivi ultramobile.

Il tempo dei browser è finito, era l'epoca fino a 2 anni fa circa quando realtà come Zynga facevano soldi a palate con browser game. Ora invece sono quasi fallite e tutti preferiscono l'app, sia per le prestazioni sia per la comodità di fruizione. E non credo che trasferire le app in un browser nascosto possa migliorare la situazione.

Riguardo al fatturato generato dalle app, è ovvio sia un mercato destinato alla saturazione e alla sopravvivenza di pochi big. Il mondo dei telefoni è oggi simile al mondo dei PC all'epoca della silicon valley di Jobs e Gates, anche un ragazzetto in un garage può diventare milionario anche un dev singolo può guadagnare dei soldi facendo app. Ma in futuro sarà come i programmi per PC, sono talmente tanti e complessi che solo quelli delle grosse SW riescono ad andare avanti


scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?
recoil14 Gennaio 2014, 15:31 #4
Originariamente inviato da: Ventresca
scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?


http://xamarin.com/

in ogni caso per lavorare con iOS ti serve un Mac perché il pacchetto da rilasciare o da testare sui dispositivi lo generi solo in OS X, però puoi fare gran parte del lavoro in C# e riciclare le varie classi
Armage14 Gennaio 2014, 23:34 #5
La società di analisi di mercato Gartner sostiene che entro il 2018 meno dello 0,01% di tutte le app mobile consumer saranno considerate un successo economico dai loro sviluppatori, questo perché il pubblico sta sempre più affidandosi ad un meccanismo di "passaparola" (tramite i pareri degli amici, con i motori di raccomandazione, sui social networking) per scoprire le applicazioni mobile invece che tramite la tradizionale consultazione del catalogo delle app disponibili sui vari marketplace digitali.


non ho proprio capito come questi due eventi siano il primo la conseguenza del secondo.
cioè: solo lo 0.01% delle app sarà considerato un successo economico da chi le ha fatte perché la gente si affiderà di più al passaparola ???
birmarco15 Gennaio 2014, 00:01 #6
Originariamente inviato da: Ventresca
scusa ma in teoria le app per iOs non sono in objective-c, quelle per android in java e quelle per win mobile in c#?


Come dice recoil

Fondamentalmente puoi far tutto con Visual Studio + Xamarin + C# e fare del codice che gira su tutto Su iOS C# è anche supportato "ufficialmente", indipendentemente da Xamarin e Visual Studio, che sono comunque la soluzione migliore. Poi una volta che hai la tua PCL con il cuore dell'app lasci alle parti platform dependent la gestione dello storage, della gestione API e dell'interazione con l'UI e l'IO. Anche se fondamentalmente sono più lavoro di dependency injection che gestione vera e propria. Ovviamente solo se fai un buon lavoro nella PCL Solo l'ultimo tassello della UI ti tocca gestirlo diversamente e non puoi riciclare nulla, ma è forse una buona cosa, così si evita di usare la stessa UI su piattaforme che necessitano di UI differenti. Troppo spesso vedo app fatte per iOS girare su Android e WP o fatte per Android e girare su WP e iOS. Sono slegate dal sistema di destinazione e sono proprio un bruto vedere oltre che spesso inadatte (ad es WP ha il tasto back, iOS ha il pusante back lato UI che si trova in alto)


Originariamente inviato da: Armage
non ho proprio capito come questi due eventi siano il primo la conseguenza del secondo.
cioè: solo lo 0.01% delle app sarà considerato un successo economico da chi le ha fatte perché la gente si affiderà di più al passaparola ???


Si, ho notato anche io, è un passaggio che non ha senso, forse perché la gente si affiderà di più al passaparola
Ventresca15 Gennaio 2014, 10:38 #7
visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?
recoil15 Gennaio 2014, 12:05 #8
Originariamente inviato da: Ventresca
visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?


per esperienza quando lavori in questo ambito il problema non è tanto la differenza di linguaggio ma la piattaforma su cui lavori
C# non è difficile da imparare, non lo uso da anni ma a suo tempo l'ho trovato abbastanza intuitivo
birmarco15 Gennaio 2014, 12:36 #9
Originariamente inviato da: Ventresca
visto che sto studiando objective-c vi faccio questa domanda: c'è molta differenza tra c# e objective-c?


Moltissima

Giusto qualche confronto sulla sintassi:

http://www.texnomic.com/blog/?p=692

Fondamentalmente, per fare le stesse cose, con O-C ci metti almeno il doppio del tempo che con C#, a questo tempo in più devi aggiungerci lo svantaggio nel non poter usare Visual Studio, il miglior IDE in circolazione. E credimi, quando il lavoro diventa tanto e i progetti complessi, Visual Studio ti aiuta più di un collega che programmi al posto tuo

Con VS + C# posso tirarti su un'app in pochissimo tempo, con O-C considera di doverci mettere dalle 2 alle 3 volte tanto.

Questo perché O-C non è affatto un linguaggio moderno e quindi manca di molti strumenti che ti permettono di lavorare con un più alto livello di astrazione rispetto a C#.

LINQ su tutti, strumento che permette di effettuare query su collezioni di oggetti, come fosse un database. Non solo, accoppiato alla ObservableCollection (un tipo di lista ""avanzato"" ti permette di fare cose pazzesche.

Ad esempio, hai una lista di libri caricata da un database (di tipo LINQ to SQL), vuoi derivare da quella lista una lista di libri che siano della categoria gialli, per visualizzarli all'utente.

[CODE]ObservableCollection<Libro> TuttiILibri() = DataBase.LoadLibri();
ObservableCollection LibriGialli<Libro> = new ObservableCollection(from libro in TuttiILibri where libro.Categoria == "giallo" select libro);[/CODE]

Fatto in 2 righe! Ora in LibriGialli ho solo i libri della categoria "gialli". Ma qui viene la parte bella, ipotizziamo che LibriGialli sia collegato (data binding) ad un controllo UI che li visualizza a schermo, e che all'utente sia fornito un comando per cancellare o modificare un qualsiasi parametro dell'oggetto libro (che sia titolo autore categoria o altro non importa).

Quando l'utente preme il comando, il libro che si trova in LibriGialli viene modificato. Questo fa si che AUTOMATICAMENTE, senza che tu debba programmare una sola riga di codice, la modifica va a cascata su LibriGialli, poi su TuttiILibri (dato che LibriGialli deriva da TuttiILibri) fino ad arrivare a modificare il database! Allo stesso tempo una modifica fatta al database si riflette in senso inverso a tutti i livelli superiori, visualizzando all'utente la modifica, sempre senza scrivere una sola riga.

In circa 5-10 righe di codice tu puoi scrivere l'esempio che ti ho descritto qui sopra, compreso il comando di modifica e la visualizzazione dei dati all'utente (considerando di avere il DB già scritto), con O-C non basterebbe lo spazio in questo post.

Per lo sviluppo di app o di software non di basso livello, C# è (quasi) sempre la scelta migliore.

Questo non vuol dire, ovviamente, che O-C non serva a nulla. Infatti ti permette di gestire la memoria o di effettuare operazioni a basso livello che C# non ti permette di fare. Dipende tutto da quello che devi fare tu
Ventresca15 Gennaio 2014, 20:58 #10
Originariamente inviato da: birmarco
Moltissima

Giusto qualche confronto sulla sintassi:

http://www.texnomic.com/blog/?p=692

Fondamentalmente, per fare le stesse cose, con O-C ci metti almeno il doppio del tempo che con C#, a questo tempo in più devi aggiungerci lo svantaggio nel non poter usare Visual Studio, il miglior IDE in circolazione. E credimi, quando il lavoro diventa tanto e i progetti complessi, Visual Studio ti aiuta più di un collega che programmi al posto tuo

Con VS + C# posso tirarti su un'app in pochissimo tempo, con O-C considera di doverci mettere dalle 2 alle 3 volte tanto.

Questo perché O-C non è affatto un linguaggio moderno e quindi manca di molti strumenti che ti permettono di lavorare con un più alto livello di astrazione rispetto a C#.

LINQ su tutti, strumento che permette di effettuare query su collezioni di oggetti, come fosse un database. Non solo, accoppiato alla ObservableCollection (un tipo di lista ""avanzato"" ti permette di fare cose pazzesche.

Ad esempio, hai una lista di libri caricata da un database (di tipo LINQ to SQL), vuoi derivare da quella lista una lista di libri che siano della categoria gialli, per visualizzarli all'utente.

[CODE]ObservableCollection<Libro> TuttiILibri() = DataBase.LoadLibri();
ObservableCollection LibriGialli<Libro> = new ObservableCollection(from libro in TuttiILibri where libro.Categoria == "giallo" select libro);[/CODE]

Fatto in 2 righe! Ora in LibriGialli ho solo i libri della categoria "gialli". Ma qui viene la parte bella, ipotizziamo che LibriGialli sia collegato (data binding) ad un controllo UI che li visualizza a schermo, e che all'utente sia fornito un comando per cancellare o modificare un qualsiasi parametro dell'oggetto libro (che sia titolo autore categoria o altro non importa).

Quando l'utente preme il comando, il libro che si trova in LibriGialli viene modificato. Questo fa si che AUTOMATICAMENTE, senza che tu debba programmare una sola riga di codice, la modifica va a cascata su LibriGialli, poi su TuttiILibri (dato che LibriGialli deriva da TuttiILibri) fino ad arrivare a modificare il database! Allo stesso tempo una modifica fatta al database si riflette in senso inverso a tutti i livelli superiori, visualizzando all'utente la modifica, sempre senza scrivere una sola riga.

In circa 5-10 righe di codice tu puoi scrivere l'esempio che ti ho descritto qui sopra, compreso il comando di modifica e la visualizzazione dei dati all'utente (considerando di avere il DB già scritto), con O-C non basterebbe lo spazio in questo post.

Per lo sviluppo di app o di software non di basso livello, C# è (quasi) sempre la scelta migliore.

Questo non vuol dire, ovviamente, che O-C non serva a nulla. Infatti ti permette di gestire la memoria o di effettuare operazioni a basso livello che C# non ti permette di fare. Dipende tutto da quello che devi fare tu


ma con xamarin che converte da c# a objective - c e java, per i limiti che elencavi te qui sopra di c#, non si possono fare app troppo avanzate che richiedono troppe risorse, oppure si?

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^