Avenir iOS face au multi plateforme
Freyskeyd
Membre
::
Salut à tous,
J'ai eu un gros débat au boulot avec plusieurs collègues sur l'avenir des applications mobiles.
On ne peut le nier, les applications mobiles se doivent d'être performante, graphiquement parfaite et avec un UX de dingue.
Lors d'appel d'offre on retrouve souvent la demande client sur du multi plateforme.
Deux idées se rencontrent, l'une où la technique met en avant la fiabilité et la solidité des applications natives, l'autre le coté multiplateforme des solutions HTML5/JS.
Dans la plus part des cas c'est le HTML5/JS qui gagne car plus rentable...
J'aimerai savoir ce que vous pensez de tout ceci, d'un point de vue développeur, de ce que vous voyez pour l'avenir du développement mobile et surtout si vous pensez que les applications html5/js peuvent remplacer du natif.
(je sais que cette question à été beaucoup abordé sur le web, mais la plus part des librairies évoluent et l'arrivé d'IOS7 me semble un bon moment pour relancer un peu la machine)
Merci de m'avoir lu.
See ya
Salut à tous,
J'ai eu un gros débat au boulot avec plusieurs collègues sur l'avenir des applications mobiles.
On ne peut le nier, les applications mobiles se doivent d'être performante, graphiquement parfaite et avec un UX de dingue.
Lors d'appel d'offre on retrouve souvent la demande client sur du multi plateforme.
Deux idées se rencontrent, l'une où la technique met en avant la fiabilité et la solidité des applications natives, l'autre le coté multiplateforme des solutions HTML5/JS.
Dans la plus part des cas c'est le HTML5/JS qui gagne car plus rentable...
J'aimerai savoir ce que vous pensez de tout ceci, d'un point de vue développeur, de ce que vous voyez pour l'avenir du développement mobile et surtout si vous pensez que les applications html5/js peuvent remplacer du natif.
(je sais que cette question à été beaucoup abordé sur le web, mais la plus part des librairies évoluent et l'arrivé d'IOS7 me semble un bon moment pour relancer un peu la machine)
Merci de m'avoir lu.
See ya
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Effectivement c'est plus rentable pour un studio de développement de vendre une application multi-plate forme à un client, que de développer 2 ou 3 applications spécifiques. Mais la qualité ne sera pas la même ! C'est la différence entre des habits industriels et du fait main par un couturier.
Moi j'ai une bête question: une application HTML5/JS peut elle faire du offline facilement et du stockage local facilement ? Car si il faut toujours avoir du réseau...
Après, il faut savoir si tu parles de coder en HTML/JS et créer des executables pour chaque plateforme (du faux natif) ou si tu parles d'exécuter du HTML/JS localement.
Ce n'est pas un problème de rentabilité par la société de service, c'est le client qui décide au final.
Pour certaines catégories d'apps le client décide principalement en fonction du prix.
La notion de "qualité" est assez subjective et tous les clients n'ont pas besoin d'une qualité extraordinaire. D'autant plus que beaucoup de clients sont habitués aux applications Windows sur desktop ou à des intranets vraiment pas terribles.
Certains veulent juste une présence sur mobile pour compléter leur gamme, ils veulent des apps fonctionnelles et n'ont pas forcément l'envie, ni la compétence, de s'investir avec la société de service pour produire des apps révolutionnaires sur les plateformes ciblées.
L'objectif c'est donc de trouver le bon compromis entre prix et qualité pour vendre une solution technique qui donnera confiance et envie au client.
Dans ce contexte, où le design n'est pas ce qui compte le plus, avoir un maximum de code commun entre plusieurs plateformes n'est pas idiot.
En revanche, se baser sur une plateforme totalement orientée HTML/JS est une erreur.
A mon avis, la bonne solution, si on a les compétences, c'est une app native avec un GUI reposant principalement sur HTML5/JS dans une webview et des couches basses natives utilisant le maximum de 'C/C++' portable.
Ainsi on peut avoir accès directement aux frameworks de l'OS (Contacts, photos, etc) sans passer par une couche intermédiaire difficile à debugger et souvent en retard d'une saison sur les frameworks natifs.
Je suis d'accord avec Draken. En faisant une appli multi-plateforme, on se restreint forcément en terme d'ergo/UI et les clients des plateformes ne retrouvent pas forcément leur habitude
::
Quand je parle d'application HTML5 je parle d'application style phoneGap (Cordova).
Pour ma part je trouve les applications HTML5 bancales et pas du tout fluide.
La plus part d'entre elles crachent X fois par utilisation, et comme dit précédemment, les concepts du web ne peuvent être utilisé directement sur mobile. Rien que pour l'UX c'est horrible...
Pourtant je ressens de plus en plus l'influence de ce système (HTML5 compilé dans une WebView native) sur le marché du mobile. Lorsqu'on estime un projet pour un client, on nous demande de faire une estimation native et Cordova.
Bien sur la native prend plus de temps au final, mais est plus sur, plus facile à maintenir et plus fiable.
Mais au final le client ne voit que le prix...
C'est dur de pouvoir lutter contre ça.
Avez-vous déjà été exposé à ce problème? Comment vous l'avez géré?
A++
Pour moi, je suis sensiblement contre les applications mutli-plateformes (dans le sens où développées " toutes en même temps en un tout " et pas " une par une ")...
Les entreprises voient le prix, mais si ce n'est pas pour une application interne, il va falloir leur intégrer un minimum de marketing en tête...
Dois-je être irréprochable sur mon application et profiter pleinement de toutes les ressources que me propose telle ou telle plate-forme (en ayant la possibilité d'en limiter, en fonction de ce que peuvent faire les autres afin de ne pas créer de plus-value sur un type de plateforme) ?
Ou dois-je juste pondre un truc, parce qu'il paraà®t qu'avoir son application mobile, ça fait cool ?
Pour un développeur, le challenge d'une application, c'est qu'elle soit fonctionnelle avant tout... Ensuite, on s'intéresse plus ou moins à l'UI/design (en fonction de ses affinités et de son degré de perfectionnisme), mais pour une boà®te, les DEUX doivent être pris en compte... Car si on demande une application mobile, c'est pour qu'elle soit utilisée... Même si Casto ou Bricomarché ont une application mobile spéciale pour leur boutique, qui permet de faire des mesures, des reminders, etc. si elle n'est pas user friendly, je ne l'utiliserais pas. Du coup, de mon point de vue, c'est un client potentiel de l'application qui est perdu, et du point de vue de l'entreprise, c'est un client qui permettrait de " rentabiliser " (dans le sens où elle est utilisée, et qu'il faut potentiellement la maintenir, qu'elle possède un sens) l'application...
J'étais à CocoaHeads Paris le mois dernier, et une des dernières conférences/talks parlaient justement de design. Et que designer pour le web ou pour du mobile, c'est très très différent. Ici, même chose. Une application multi-plateforme aura trop de chance d'être éloignée de son OS en voulant à tout prix être générale... Or, ce qui fait la qualité des différents OS (avec une préférence pour iOS quand même :P), ce sont leurs particularités...
Perso, j'ai un p'tit dégoût quand j'ouvre une application moche, comme NeoOffice, qui de mémoire était en Java, et perso, on reconnaà®t de suite que le design est différent, et ne va pas avec le reste de tes applications Mac OSX...
- Les solutions natives sont toujours mieux car on peut profiter pleinement de toutes les possibilités de chaque plateforme : ergonomie et design adapté, fonctionnalités propres à une PF qui n'existe pas sur une autre, réactivité... mais il faut faire autant d'applis que de PF donc c'est plus cher pour le client
- Les solutions à la PhoneGap/Appcelerator/... en HTML5 permettent de développer qu'une seule fois donc moins cher pour le client, mais n'adaptent pas l'ergo/design/fonctionnel à chaque PF, et utilisent le plus petit dénominateur commun de toutes les PF
Le hic (en tout cas vu nos clients dans ma boite, et d'après mon analyse) c'est que nos clients ne connaissent pas trop le monde du mobile. Ils ont leurs services (banque, assurance, énergie, opérateurs...) d'un côté et se disent que ça serait bien de porter ça sur mobile, mais limite ils n'ont pas conscience que Android et iOS c'est une interface et ergo différente, ou n'ont pas conscience des problématiques de fluidité/performance etc.Donc pour eux, tous les avantages qu'apportent le natif, en terme de fonctionnalités techniques qui peuvent être faites en natif et pas en HTML5, en terme de fluidité, en terme d'ergonomie différente et d'habitudes d'utilisateurs, ils s'en foutent et ça leur parle pas.
En tant que société de conseil, on leur remonte ces choses là , bien sûr, et donc que niveau qualité et User Experience ça serait mieux 2 applis natifs qu'une appli HTML... mais souvent ils voient ça comme "ouais tu parles vous voulez nous vendre un truc plus cher c'est tout".
C'est pour ça qu'en pratique le natif c'est mieux car plus adapté à chaque PF etc, mais les clients préfèrent du HTML ils ne sont pas assez matures ou immergés dans le monde mobile pour réaliser que les avantages (UX, ergo dédiée...) ont un poids conséquent, et ne voient que le prix en bas de la feuille...
Je dirais que c'est un peu le même combat que le offshore. Faire faire une appli par des petits chinois ou des petits indiens (désolé pour la caricature ^^) ça va coûter moins cher, mais bonjour la qualité et la maintenance / évolutivité après. Le client ne voit souvent pas plus loin que le prix, et c'est seulement quand il veut faire évoluer l'appli ou se rend compte qu'elle est buguée qu'il va dépenser tout le fric qu'il a gagné " à la faire faire moins cher " dans la correction d'anomalie et donc y perdre financièrement... mais finalement il sera déjà trop tard.
Toutes les applications web sont donc mauvaises. >:D
On ne peut pas leur en vouloir, vu qu'on vient de leur vendre pendant 10 ans des app web sur desktop sous prétexte que... je sais pas d'ailleurs...
Je me fais un peu l'avocat du diable mais quand 90% du marché était dominé par Windows, certains trouvaient le moyen de vendre du multi-plateforme (web, java) et maintenant qu'on est sur un marché mobile à 50/50, on vend du natif !
Je pense qu'il faut regarder les projets au cas par cas et ne pas rejeter d'emblée les solutions multi-plateformes sinon on ne tient pas notre rôle de conseil.
Je pense que le client peut comprendre l'attrait d'une bonne ergonomie (surtout s'il a un iPhone...) mais il faut reconnaà®tre que toutes les apps n'ont pas besoin d'avoir une bonne ergonomie.
Ou, en tous cas cas, même si c'est évidemment toujours bénéfique d'avoir une meilleure ergonomie, cela ne vaut pas toujours le surcoût.
Qu'est-ce qu'une application ?
La définition d'une application varie entre desktop et mobile.
Sur mon mobile, j'ai une app pour consulter mon compte en banque et faire des virements. Sur mon desktop, un site web me suffit pour ça...
Attention je ne défends pas PhoneGap.
Je pense que proposer une app faite avec PhoneGap à un client, c'est une escroquerie.
C'est utiliser l'argument du multi-plateforme pour pouvoir réutiliser des compétences internes HTML5/JS sur du développement mobile.
Et si on n'a pas de compétences HTML/JS, utiliser PhoneGap c'est juste stupide. C'est apprendre à utiliser une API tierce-partie pour faire une app pas terrible et difficile à débugger.
Je ne développe pas pour mobiles, mais il me parait évident que, si votre client veut tripler ou quadrupler le nombre de ses acheteurs potentiels, il va demander du multiplateforme. Dans ce domaine c'est l'étendue du marché potentiel qui va modifier sa demande, donc l'espérance de bénéfices de votre client à vous qui prime. Après, c'est de la technique, et la plus part de vos clients s'en foutent.
On peut toujours ergoter sur la qualité. Un défaut bien français c'est "la qualité maximum", alors que les Américains recherchent la qualité nécessaire et suffisante (et basta).
Sinon pour faire pencher la balance du côté du natif, on peut citer des exemples d'application qui sont passé du multiplateforme/HTML5 vers du natif.
On peut citer en tête Facebook. Mais y'a aussi d'autre exemple. Personnellement j'ai remarqué que l'application de ma banque (BNP Paribas) a suivi le même chemin : HTML5 vers Natifs
D'ailleurs, j'utilise beaucoup moins Linxo depuis que l'app officielle est native.
ça serait intéressant d'établir une liste d'applications qui sont passé du HTML5 au natif.
Je relance le débat ::)
Pensez-vous que depuis juin 2013 les fonctionnalités de Cordova ait évolué suffisamment pour devenir vraiment une solution pour les applications multi-plateformes ?
Que pensez-vous du nouveau sur le marché (ionic) ?
J'en pense toujours ça
Chaque portage doit respecter les "pratiques culturelles" de la machine cible.
les webapps ont encore leurs désavantages (et le gain de temps n'est pas si grand que ca si l'on veut respecter les spécificités de chaque plateforme)
mais dans certains cas c'est bien
après y'a aussi des trucs comme xamarin ou encore un article que j'ai recemment vu (qui sera dans la prochaine weekly) qui explique comment Google utilise du code Java dans ses app iOS.
ionic a l'air pas mal
Si on pense que les apps mobiles sont faites pour durer. Et on pouvait s'en douter dès 2008/2009.
Pourquoi ne pas investir dès le début des développements dans une app native sur chaque plateforme avec du code commun en 'C'/C++, .NET (xamarin) ou java, plutôt que d'utiliser des frameworks web dont la fiabilité, la pérennité et le rendu sont douteux.
Il vaut mieux faire plusieurs app natives (une sur chaque plateforme) plutôt que plusieurs apps multiplateformes.
Je comprends que des PME soient pragmatiques, mais des banques, des opérateurs de téléphonie, etc...
J'aime bien les arguements d'ionic :
-Performance obsessed
-AngularJS & Ionic
-Native focused
-Beautifully designed
-A powerful CLI
-Fun to learn
-Built by nerds (like you)
Il y a plus d'arguments pour faire plaisir aux développeurs que d'arguments à l'avantage direct des utilisateurs.
Dans le portfolio d'apps "made with ionic", y'a qqs (bonnes) surprises je trouve !