Le coût du partage de code entre iOS et Android

À ses débuts en 2013, Dropbox utilisait le C++ pour partager du code entre les deux plateformes.

À l’époque, l’équipe était petite, et cela visait à soutenir une feuille de route mobile en croissance rapide.

Aujourd’hui, l’entreprise est passée à Swift et Kotlin, à cause des coûts cachés suivants liés au partage de code (en réalité, ils ne sont pas vraiment cachés)

• surcharge liée aux frameworks et bibliothèques personnalisés

• surcharge liée à un environnement de développement personnalisé

• surcharge liée à la gestion des différences entre plateformes

• surcharge liée à la formation, au recrutement et à la fidélisation des développeurs

En conclusion, écrire une seule base de code paraît séduisant, mais la surcharge est importante.

Il est important de noter que le dernier paragraphe de cet article revient en fait à dire : « Nous recrutons des développeurs Android / iOS ! »

[godrm]

N’est-ce pas une question de savoir si l’organisation peut absorber cette surcharge ?

Si on peut assumer n’importe quel choix, je pense qu’il vaut mieux se concentrer sur ce qu’on fait le mieux.

De toute façon, les différences entre plateformes semblent inévitables. Même en faisant du hybride, les écarts ne disparaissent pas.

[iolothebard]

Le cross-platform n'est qu'une plateforme de plus.

En plus d'être plus complexe et plus bancal..

[ohjongin]

Ces derniers temps, React Native semble avoir atteint un niveau de maturité assez élevé..

Bien sûr, dès qu’on va vers une application dépendante de l’appareil comme Dropbox, on continuera sans doute à souffrir comme avec les applications hybrides classiques..

[xguru]

Le texte est long, mais en réalité, Dropbox est un cas particulier parce qu’ils utilisent du C++.

Dans une petite organisation, l’idée de prendre en charge plusieurs plateformes avec une seule base de code est franchement séduisante au début.

Il y a 10 ans, c’était le développement hybride avec HTML5 et Phonegap,

et aujourd’hui, des solutions comme React Native et Flutter séduisent tout le monde avec la promesse de pouvoir prendre en charge plusieurs plateformes d’un seul coup.

À mon avis, pour une petite organisation, partager le code de cette façon présente clairement des avantages.

Mais à mesure que le produit grandit, cela finit par redevenir de la dette technique.

Quand le nombre d’utilisateurs augmente, que l’organisation grossit et que le nombre de développeurs augmente lui aussi, je pense que l’issue finale est que le Web, iOS et Android évoluent chacun avec des technologies adaptées à leurs besoins.

Comme dans le bon article sur la dette technique mentionné ici :

https://fr.news.hada.io/topic?id=309, il est important de créer de la dette technique avec une intention claire. Remboursons la dette avant que les intérêts n’enflent.