Que faudra-t-il pour obtenir chaque application sur chaque plate-forme?

Il existe trois façons de sélectionner l'expérience de votre smartphone: par opérateur, par appareil et par applications. Le choix par opérateur place la qualité de votre service cellulaire en premier, tandis que la prise de décision en fonction de l'appareil signifie que vous recherchez une expérience de plate-forme et des fonctionnalités matérielles spécifiques. Mais le choix par applications peut être plus délicat.

L'éventail actuel des écosystèmes mobiles est à la fois fragmenté et unifié sur toutes les plates-formes. Certaines applications majeures sont disponibles sur de nombreuses plates-formes, tout comme les applications de petits développeurs. D'autres applications sont exclusives à une plate-forme en raison des fonctionnalités propres au système d'exploitation ou des contraintes de ressources du développeur. Mais si vous avez vraiment besoin de cette application, l'opérateur ou l'appareil n'a pas tellement d'importance.

Mais que se passerait-il si toutes les applications pouvaient être disponibles sur toutes les plateformes? Les développeurs devraient-ils se préoccuper du développement multiplateforme et y a-t-il des pièges à surmonter? Est-il préférable de créer une application spécifiquement pour chaque plate-forme, ou l'application devrait-elle être créée avec un cadre Web multiplateforme?

Les utilisateurs et les développeurs peuvent convenir que la disponibilité d'une application quelle que soit la plate-forme est un excellent idéal. Mais à quel prix?

Commençons la conversation!

En réalité, la question est plus compliquée. Le plus souvent, "la prochaine grande chose" a été créée par un développeur vraiment talentueux ou une petite équipe qui n'a tout simplement pas les ressources, les compétences ou les capacités pour programmer multi-plateforme. Nous l'avons vu très tôt avec Instagram et Android - la société derrière l'application ne comptait que treize employés. De telles limitations ont retardé une application Instagram Android pendant un certain temps, et même maintenant après avoir été achetée par Facebook pour un milliard de dollars, ils n'ont toujours pas publié d'application compatible avec BlackBerry 10 ou Windows Téléphone.

La plate-forme doit souvent atteindre une métrique invisible et ambiguë par laquelle elle est considérée comme «acceptée» par les masses.

Les petites entreprises ne sont pas seules ici, car nous voyons souvent de grandes entreprises de médias hésiter à créer des applications multiplateformes. La plate-forme en question doit souvent atteindre une métrique invisible et ambiguë par laquelle elle est considérée comme `` acceptée '' par les masses et ce n'est qu'alors que les entreprises envisageront de créer une application pour elle. Parfois, les développeurs qui sont «fans» d'un système d'exploitation particulier construiront d'abord une application pour cette plate-forme, même si la part de marché géante n'est pas là. Cela s'est produit avec l'application officielle Disqus pour Windows Phone, qui était la première (et jusqu'à présent la seule) plate-forme mobile à obtenir une application officielle du service de commentaires.

Alors oui, les entreprises doivent toujours s'efforcer de passer à plusieurs plates-formes quand elles le peuvent, et si elles ne le peuvent pas, elles doivent contacter les développeurs de cette communauté pour travailler sur un partenariat. Foursquare l'a fait lorsque le développeur Zhephree a créé indépendamment une application Foursquare pour webOS en 2009 et que l'application est devenue de facto l'application Foursquare pour la plate-forme. Malheureusement, c'est un événement rare, et trop souvent, les consommateurs sont aux prises avec des sélections d'applications qui n'incluent pas la dernière ou la meilleure, simplement en raison de leur choix de plate-forme mobile.

Un langage de programmation multiplateforme comme HTML5 ou Unity pour les jeux aiderait-il? Les normes sont certainement meilleures que le chaos, bien que, comme nous l'avons vu avec HTML5 jusqu'à présent, cela a été surtout un battage médiatique plutôt qu'un succès.

WBien qu'il y ait des exceptions à chaque règle, je veux vraiment vivre dans un monde où la majorité des applications mobiles sont multiplateformes et fonctionnent juste quand et où je le veux. Prenons l'exemple du Web. Je peux accéder à presque tous les sites Web à partir de presque tous les appareils du marché. Le site Web de Facebook ne se soucie pas si je suis sur un Mac ou un PC Windows, sur un smartphone ou une tablette, sur Android ou BlackBerry 10.

Tant que la plate-forme dispose d'un navigateur Web moderne, je peux accéder à pratiquement tous les sites de mon choix. Je peux créer et déployer un site Web sur une gamme complète d'appareils et tout le monde peut le voir. Dans la plupart des cas, si le site respecte les normes, il "fonctionne simplement".

L'état des applications mobiles multiplateformes est assez différent.

Prenez Android Central, CrackBerry, iMore et Windows Phone Central. Les sites utilisent un code très similaire et fonctionnent sur la plupart des navigateurs de bureau ou mobiles. Quatre sites Web, tous les navigateurs. Bonne affaire.

Mais faire cela avec des applications signifierait utiliser des cadres distincts et substantiellement différents pour Android, BlackBerry 10, iOS et Windows Phone pour chacune des applications des sites. Quatre applications fois quatre plates-formes pour un total de seize applications. Pas une si bonne affaire.

Il en va de même pour les accessoires qui reposent sur des applications connectées. Le Nike + FuelBand a été lancé uniquement sur iOS, mais pour l'investissement que Nike a investi dans son matériel, il prendrait idéalement en charge toutes les plates-formes. De nombreux utilisateurs non-iOS auraient pu en acheter un pour les vacances de 2012, mais le fait que le FuelBand ne prenne pas et ne prend toujours pas en charge d'autres plates-formes limite son marché potentiel. Les utilisateurs ne se soucieraient pas de la multiplateforme - tout ce qui importerait, c'est que cela fonctionne avec leur appareil.

Personne ne veut une application sur BlackBerry 10 qui ressemble exactement à celle d'iOS et qui n'inclut pas la prise en charge des gestes de BlackBerry 10.

Les jeux sont souvent les plus avancés sur ce point grâce à des moteurs multiplateformes comme Unity et Titanium. Cependant, les jeux ont tendance à avoir leurs propres interfaces non conformes à la plate-forme. Les applications non liées au jeu sont différentes. Bien que les applications puissent partager des fonctionnalités, des services et même du code communs entre les plates-formes, elles ont besoin de l'apparence et de la convivialité de la plate-forme et peuvent bénéficier de fonctionnalités spécifiques à la plate-forme. Personne ne veut une application sur BlackBerry 10 qui ressemble exactement à celle d'iOS et qui n'inclut pas la prise en charge des gestes de BlackBerry 10.

En fin de compte, si vous retirez les propriétaires de plates-formes, les fabricants et même les développeurs de l'équation, les gens veulent juste les applications qu'ils aiment sur les appareils qu'ils aiment. Cela signifie que chaque application majeure doit prendre en charge toutes les plates-formes principales. Maintenant.

Theorétiquement, avoir les mêmes applications sur toutes les plates-formes devrait être une évidence, non? Plus d'applications dans plus d'endroits. Mais la vérité décevante est que même aujourd'hui, toutes les applications ne sont pas créées égales.

Différentes plateformes font les choses différemment. Parfois, c'est une question de matériel. BlackBerry 10 et Windows Phone n'ont pas la puissance de traitement pure d'Android. L'iOS d'Apple est sans doute plus facile à développer et peut faire plus avec moins. Et, par conséquent, une application disponible pour l'iPhone et l'iPad peut avoir des fonctionnalités différentes de celles sur Android, BlackBerry 10 ou Windows Phone. En fait, nous avons vu des instances d'applications populaires qui perdent une partie importante de leurs fonctionnalités lorsqu'elles sont portées d'une plate-forme à une autre.

La vérité décevante est que même aujourd'hui, toutes les applications ne sont pas créées égales.

Ce n'est pas toujours aussi profond, cependant. Parfois, c'est juste une question d'apparence. Peut-être qu'une application n'est tout simplement pas aussi belle sur une plate-forme qu'une autre. Superficiel? Peut-être. Les applications doivent avoir une expérience cohérente sur toutes les plates-formes. Ou du moins essayer de vivre la même expérience. Mais ils doivent également avoir une expérience de plate-forme. C'est un cheveu difficile à fendre.

La bonne nouvelle est que les applications sont des bêtes fluides. Ils changent et s'améliorent constamment. Probablement pas aussi vite que nous le souhaiterions tous, mais il est rare que l'application populaire ne soit jamais mise à jour, ne s'améliore jamais et ne se reconce jamais.

HLes applications TML5 sont créées à l'aide de technologies Web standard telles que HTML, CSS et JavaScript. Ces applications fonctionnent dans des navigateurs, comme Google Maps ou iCloud.com, ou sur des appareils locaux tels que Chrome OS ou le regretté webOS. Étant donné que de nombreux développeurs savent déjà comment créer des expériences Web riches, il est généralement admis que les applications HTML5 seront le moyen le plus simple de faire passer ces développeurs sur mobile. D'où tout, de la solution originale "douce" des applications dans le navigateur iPhone aux frameworks Mojo de Palm et plus tard Enyo aux WebWorks de BlackBerry.

Cela a conduit à la présomption, généralement de non-développeurs, que HTML5 est le dernier et le meilleur espoir d'un avenir utopique où les applications sont écrits une fois et déployés partout, sur plusieurs plates-formes, du bureau à la tablette en passant par le téléphone et à tout et n'importe quoi dans entre.

Et c'est un tas de BS.

La solution originale «douce» d'Apple a si mal fonctionné qu'ils se sont précipités pour sortir l'App Store natif un an plus tard, l'application de calendrier sur webOS 1.0 a pris vingt secondes pour se lancer, et Google produit des expériences bien meilleures avec les applications codées en natif sur Android et iOS qu'elles ne le sont sur le la toile. Même les meilleures applications Web mobiles, comme Gmail.com et Forecast.io, sont pâles par rapport à leurs cousins ​​natifs plus riches et plus performants.

Les applications natives bénéficieront d'un nouveau matériel et de nouveaux frameworks. Leur avance restera, sinon grandit.

Certains disent qu'à mesure que le matériel devient plus puissant et que JavaScript est amélioré, les performances et les fonctionnalités des applications Web augmenteront. C'est absolument vrai. Mais les applications natives bénéficieront également d'un nouveau matériel et de nouveaux frameworks. Leur avance restera, sinon grandit.

C'est pourquoi les applications HTML5 sont appelées l'avenir - elles arrivent toujours mais n'arrivent jamais tout à fait.

Essayer de créer une application entière en HTML5, c'est comme essayer de créer une application entière qui existe totalement hors ligne, en mode avion. Ce n'est pas impossible, mais ce n'est pas idéal, et cela limite considérablement la portée et l'expérience qui peuvent être fournies.

Cela se résume à ceci: Internet est le meilleur pour fournir des données dynamiques, et les applications natives sont les meilleures pour l'interface et l'interactivité. Les bonnes applications utiliseront le meilleur des deux. Comme iTunes. Comme Google Maps pour Android et iOS. Comme la nouvelle version native de Facebook pour mobile (même Facebook a appris cette leçon à la dure).

HTML5 n'est en aucun cas le futur ultime des applications. Mais c'est une partie incroyablement importante de cet avenir.

CLes applications ross-platform sont une tâche délicate. Les développeurs doivent naviguer dans les SDK, les API et les guides d'interface utilisateur et UX, tout en essayant de conserver l'aspect, les fonctionnalités et l'expérience uniques de leur propre application. C'est un équilibre entre les exigences et les désirs, les attentes et les contraintes.

Idéalement, les applications qui ont du sens pour être multiplateformes le seraient, et ce serait facile à faire. Mais c'est un marché féroce et les grands propriétaires de plates-formes ne s'intéressent guère à faciliter la création d'applications. qui fonctionnera sur les appareils des concurrents, tandis que les plus petits joueurs veulent faciliter au maximum le portage de ces mêmes applications.

Des cadres et des outils multiplateformes existent, mais leur portée et leur puissance sont limitées. Ils facilitent la création d'une expérience cohérente sur chaque plate-forme, mais sacrifient ce qui rend chaque plate-forme unique et compromettent la qualité et les performances. Mais la création d'applications personnalisées sur une plateforme prend du temps et de l'argent que tous les développeurs n'ont pas.

Il n'y a pas de bonne réponse - mais quelle est la meilleure?