Les tendances du développement mobile

Bonjour Sebastian. Quelles sont aujourd’hui les technologies de prédilection pour le mobile ?

Pour ce qui est du développement d’applications mobiles natives, ce sont les langages Swift sur iOS et Kotlin sur Android qui prédominent largement. Ce sont les plus populaires, les plus adaptés et ils offrent tout deux une grande flexibilité. Ils sont en tête de liste parce qu’ils sont très activement supportés par leurs initiateurs respectifs, c’est-à-dire Apple et Google. Si vous développez une application mobile, il y a de fortes chances que vous soyez exposé à ces langages d’une manière ou d’une autre.

Mais le problème, c’est que si voulez être présent sur les deux plateformes du marché, vous devez réaliser deux applications distinctes, l’une pour iOS et l’autre pour Android, dans leur langage respectif. C’est là qu’interviennent des outils de développement multiplateforme, comme React Native et Flutter, qui permettent de maintenir une base de code commune.

Comment React Native est-il devenu si populaire ?

React Native existe depuis plus longtemps, jouit d’une communauté solide et bénéficie du soutien technologique et financier de Facebook. Ou de Meta, devrais-je dire... Et grâce à ses formidables capacités d’ingénierie, Meta, appuyé par la communauté open-source, fait un très bon travail pour maintenir son élan.

Le succès de la plateforme est également lié au développement web, où elle tire parti du vaste réservoir de développeurs JavaScript en facilitant la migration de leurs compétences vers les plateformes mobiles. Aujourd’hui, si vous connaissez React sur le web, vous pouvez faire la transition assez facilement pour vous adapter à l’espace mobile et le marché iOS et Android s’ouvre à vous. L’afflux de développeurs issus du web ne fait que renforcer la popularité de l’outil.

Et qu’en est-il de Flutter ?

Le SDK Flutter est la réponse de Google à React Native, et bien plus encore. Il ne fait pas appel à JavaScript, car Google a développé son propre langage de programmation orientée objet moderne appelé Dart, avec lequel le SDK Flutter s’intègre. Il s’agit d’une option multiplateforme bien conçue, élégante et très performante. Contrairement à React Native qui s’appuie sur l’intégration des composants d’interface utilisateur natifs fournis par iOS et Android, Flutter a pris un chemin plus ambitieux en recréant les composants de chaque expérience grâce à un moteur graphique optimisé, appelé Skia. Cela permet aux développeurs Flutter de créer des interfaces utilisateur et des applications pour n’importe quel genre d’écran, mobile, desktop et même web. Le tiercé gagnant pour le multiplateforme.

Nous n’avons pas parlé de Xamarin et d’Ionic.

Microsoft est derrière Xamarin. Ils ont acheté l’outil en 2016 afin d’intégrer des outils de développement mobile à Visual Studio, leur environnement de développement intégré. Il faut dire que ça fonctionne bien, pourvu que vous soyez un développeur C#. Cependant, ils ont eu quelques problèmes impliquant Xamarin.Forms pour les éléments de l’interface utilisateur. Mais la principale raison d’utiliser Xamarin est de retenir les développeurs familiers avec C# et .NET.

Ionic est un framework open source qui permet d’utiliser toutes les technologies du web comme HTML, CSS et JavaScript. Cela permet d’encapsuler une application web dans une application mobile ou desktop, et son attrait est, comme pour React Native, d’être facile d’accès pour les développeurs web. Ce qui leur a permis de faire une vraie percée sur le marché. Slack, par exemple, est une application Ionic. Et ça marche bien. C’est un bon choix pour une grande variété d’applications, mais il faut bien connaître les limites de l’outil. Il faut retenir aussi que c’est gourmand en ressources et en mémoire. Et il est difficile avec Ionic d’offrir aux utilisateurs une expérience qui semble native.

React Native ou Flutter en valent-ils la peine ?

Sans aucun doute. Mais si vous voulez offrir une expérience utilisateur tout à fait fluide, élégante, efficace, qui utilise toute la gestuelle native que les applications mobiles et les écrans tactiles permettent, il vous faut passer par le développement natif. C’est-à-dire Swift et Kotlin. Si vous optez par exemple pour React Native, vous risquez de compromettre la fluidité de l’expérience. Il y a toujours un prix à payer quand ont prend des raccourcis pour être multiplateforme. Il faut toujours finement évaluer les avantages et les inconvénients lors du choix de la technologie. L’expérience utilisateur est capitale. Un mauvais design, une plateforme inadaptée, peut lui nuire et ruiner les chances d’adoption de l’application.

Il y a donc une vraie prise de risques au moment des choix technologiques.

C’est certain. J’ai vu des cas où les stratégies multiplateformes ont échoué parce que les réactions des utilisateurs étaient si mauvaises que l’entreprise a décidé de reconstruire les deux applications à partir de zéro, en mode natif pur. Traiter avec des clients frustrés ou les perdre complètement s’est avéré plus coûteux que de refaire les applications.

En fin de compte, c’est vraiment tout un défi de construire une bonne application pour le mobile, n’est-ce pas ?

Absolument. Comme dans tout développement de produit logiciel, concevoir et bâtir les fonctionnalités correctement, c’est un défi. Mais ça l’est encore plus sur le mobile avec toutes les contraintes que vous avez. La façon dont les gens utilisent leurs appareils et les expériences sont très différentes du web ou du desktop.

Ensuite la stratégie de développement peut être orientée suivant le type d’application. S’agit-il seulement d’un produit minimum viable (MVP) ? Avec des fonctionnalités simples et peu nombreuses ? Auquel cas, il tout à fait possible d’essayer certaines approches hybrides. Celles-ci peuvent rendre votre application rapidement visible, permettre de la lancer pour un petit groupe d’utilisateurs, et vous pouvez être opérationnel beaucoup plus rapidement.

Donc, les outils multiplateformes répondent à de vrais besoins.

Tout à fait. Je vois la tendance croissante des clients pour les options multiplateformes. Ils font ce choix en connaissance de cause en raison des délais de mise sur le marché et des prix. Lorsque nous proposons un développement mobile à un client qui n’est pas sûr de la voie à suivre, nous présentons toutes les options : natif pur avec Swift et Kotlin, hybride avec React Native ou Flutter, avec les avantages et inconvénients de chaque solution, afin de les aider à choisir la stratégie idéale pour leur entreprise.

Outre la rapidité de mise en marché, le facteur coût n’est pas négligeable.

La réalité est que de nombreuses start-ups qui nous contactent ont un budget limité, et peu d’entre elles ont un financement sécurisé. Le prix est un élément clé qui dicte leurs choix technologiques.

Il y a pourtant certains cas où l’on ne peut pas faire l’économie du natif.

Effectivement. C’est là que la complexité du produit entre en jeu. Je me souviens que nous devions construire une application dotée d’une interface avancée pour remplacer les formulaires papier. Et on a opté pour le natif, parce qu’il y avait nombreuses complexités spécifiques à gérer et nous ne voulions pas risquer d’être retardés par les abstractions des outils multiplateformes. Dans ce cas, le développement natif permet de mieux contrôler le niveau de risque associé aux interfaces complexes. Aussi, si vous faites des appels intensifs à certaines ressources matérielles, comme le GPS, les caméras, le LIDAR, et même le CPU, le natif s’impose souvent.

Les applications natives ont un bel avenir, mais on ne peut nier les gains réalisés par les outils multiplateformes.

Parlons prix. Peux-tu nous donner une petite idée de l’investissement que représente un développement natif ?

Vous pouvez vous en sortir avec 50 000 dollars pour une application simple, mais dès que vous introduisez des couches de complexité avec des interfaces utilisateur, des API et une gestion de la montée en charge pour une adoption plus large, vous pouvez facilement passer à 100 ou 150 000 dollars. Et ce, par plateforme !

Je comprends que cela puisse effrayer les gens et que les outils multiplateformes puissent aider à atténuer certains de ces coûts de développement, mais il ne s’agit pas d’une économie de 50 %. Il n’y a généralement que 70 à 85 % du code qui est vraiment commun. Le reste se révèle spécifique à chaque système d’exploitation.

Pour finir, qu’est-ce qui est capital dans le succès d’une application mobile ?

L’utilité et l’expérience utilisateur. Les gens téléchargent des applications qui ont une vraie utilité dans leur vie. Et ils les conservent si celles-ci sont agréables à utiliser.

Tout le monde peut vous fournir une application mobile, mais tout le monde ne peut pas offrir une expérience mobile.