Le développement mobile multiplateforme offre à minima un avantage évident à entrevoir : l’équipe monte une base de code une seule fois, ce, pour diverses cibles ou plateformes. L’approche peut s’avérer utile pour les petites équipes aux compétences peu variées, mais que la nécessité d’aller en production le plus vite possible s’impose. Depuis 2013, l’équipe Dropbox s’appuie sur cette stratégie. Elle cible les plateformes Android et iOS via un unique base de code mise sur pied en langage C++. Dans une publication parue il y a peu, un ingénieur explique pourquoi l’entreprise préfère désormais le développement natif en Swift et en Kotlin. « En montant notre base de code d'une manière non standard, nous avons hérité de coûts dont nous n'aurions pas eu à nous soucier si nous nous étions alignés sur les canons par défaut dont des tiers font usage à grande échelle. Au finish, cela est revenu plus cher que d'écrire du code deux fois », a-t-il indiqué. De façon brossée, le retour d’expérience de l’ingénieur de Dropbox laisse filtrer que le choix de l’approche de développement multiplateforme introduit des coûts de développement additionnels liés à la mise sur pied de frameworks et bibliothèques personnalisés. Ça, c’est sans compter ceux relatifs à la mise sur pied d’outils de travail custom ou la nécessité de former ou recruter des tiers capables de s’adapter à une pile logicielle très personnalisée.
En effet, Eyal Guthmann souligne que le choix de C++ pour le développement multiplateforme Android et iOS peut mener les développeurs à faire face à des difficultés qu’ils n’auraient pas eues en natif. Par exemple, indique-t-il, la mise sur pied d’un framework pour la gestion des tâches qui s’exécutent en arrière-plan peut s’imposer dans la filière développement multiplateforme en C++. À contrario, explique l’ingénieur de Dropbox, il ne s’agit pas d’un problème en natif. Eyal Guthmann relève même que l’équipe Dropbox a, dans le process, dû mettre sur pied une bibliothèque JSON pour C++11 ainsi qu’une autre pour la gestion des pointeurs NULL. L’ingénieur de la firme est même allé plus loin en mettant en exergue que c’est verser dans la théorie que de penser qu’on peut monter une unique base de code pour diverses plateformes. En effet, insiste-t-il, les spécificités de chaque plateforme constituent des facteurs auxquels on ne peut échapper. « La façon dont une application exécute une tâche en arrière-plan est spécifique à chaque plateforme et il faut en tenir compte dès le départ », précise-t-il.
En plus des considérations qui touchent au code, il y a celles qui concernent les outils de travail. À ce propos, l’ingénieur de la firme développe sur deux axes : le débogage et la mise sur pied d’outils personnalisés. « L’expérience de débogage en natif est de façon générale supérieure à celle en C++ via l’IDE par défaut de la plateforme cible », écrit-il avant d’ajouter qu’ « en plus de devoir se détourner des outils disponibles, nous avons dû mobiliser des efforts de développement pour la mise sur pied d’autres à même de supporter l’approche multiplateforme en C++. »
Enfin, pour ce qui est des aspects liés à la formation et au recrutement, Eyal Guthmann indique que l’aventure multiplateforme s’est construite autour d’un noyau d’ingénieurs avec une forte expérience en C++. Avec les départs de ces derniers vers d’autres équipes ou entreprises, l’entreprise a eu de plus en plus de mal à combler le gap technique pour maintenir la base de code C++. En interne comme en externe, la firme a eu du mal à former et à recruter sur cet axe, car il semble que très peu de développeurs mobiles portent un intérêt au C++.
Le passage de l’équipe Dropbox au natif via Kotlin et Swift pour Android et iOS vient avec des avantages. De façon classique, on attribue à cette approche de générer des applications capables de tirer un excellent parti des ressources du système d’exploitation et du matériel à disposition. Au-delà du besoin d’écrire du code une seule fois pour plusieurs plateformes, l’on peut arguer que le choix de C++ dès le départ permet de rester sur ledit axe. En effet, le langage C++ fait, à côté du C qu’on ne cite plus, office de dénominateur commun pour la gestion de telles problématiques. Il n’est pas difficile d’imaginer que le groupe initial d’ingénieurs l’avait intégré pour la gestion de certains aspects critiques du backend. Seulement, des questions sur la qualité de l’interfaçage du langage C++ avec les plateformes cibles peuvent être mises sur la table. À ce propos, il faut noter que l’équipe Dropbox s’est appuyée sur Djinni – un framework qui permet d’interfacer du code multiplateforme C++ à du code Java ou Objective-C. D’après les retours de développeurs tiers, ce dernier opacifie l’interface avec la plateforme cible, ce qui finit par transformer le flux d’exécution en un chaos d’appels incontrôlables.
Source : billet de blog
Et vous ?
Qu’en pensez-vous ? Est-il mieux d’écrire tout le code pour chaque plateforme comme l’a décidée l’équipe Dropbox ? Quand est-ce que le développement multiplateforme est-il plus bénéfique ? Quelles sont alors les solutions les plus rapides ? Ces approches ne présentent-t-elles pas trop d’avantages en commun de nos jours ? Surtout avec l’avènement de frameworks comme Flutter ?Voir aussi :
Google publie la Preview finale de Flutter, son SDK mobile Android et iOS, la dernière étape majeure avant la publication de la version stable 1.0 Quels sont vos environnements de développement intégrés (EDI) préférés en 2018 ? Et pourquoi ? Partagez vos avis Le mode sombre d'Android permet-il d'économiser l'énergie de la batterie des smartphones ? Oui, confirme Google Kotlin 1.3 est disponible : coroutines désormais stables, Kotlin/Native Beta, bibliothèques multiplateformes et bien plus encore 
Envoyé par onilink_
