Application mobile Malt, native ou cross-plateforme ?

Lionel D'Angelo
Oct 7 · 9 min read
Image for post
Image for post

Dans cet article, nous allons parler d’applications mobiles. Ce sera l’occasion de faire un retour sur le développement de l’application Malt tout en abordant l’importance que peut avoir une application mobile aujourd’hui. Ce sera aussi surtout l’occasion de parler choix de technologie, processus de décision et organisation autour de la solution choisie.

Genèse de l’application

Bien qu’une application mobile Malt dédiée aux freelances était envisagée depuis déjà quelques années, le développement de cette dernière ne s’est concrétisée qu’en 2019 pour une sortie début 2020. Je ne reviendrai pas ici sur les raisons qui font que ce développement ne soit que très récent, mais je pense qu’il est important de rappeler quelques chiffres qui soulignent l’importance que peut avoir une application mobile aujourd’hui.

Le rapport Digital 2020 de We are Social nous donne quelques statistiques intéressantes :

  • 73% des connexions internet se font à partir d’un smartphone

Une étude de Upland Localytics nous donne des chiffres intéressants concernant les push notifications :

  • Les push notifications augmentent l’engagement d‘une application d’environ 80%

Malt est une plateforme qui met en relation des freelances et des clients afin de réaliser différents projets. Pour les freelances, l’utilité d’une application mobile est évidente et l’idée est donc d’avoir une application à portée de main pour :

  • Répondre rapidement aux propositions et messages des clients

Quelles technologies mobiles ?

Image for post
Image for post

Avant de parler plus spécifiquement de l’application Malt, faisons rapidement un état des lieux des solutions possibles pour développer une application mobile. Nous pouvons les regrouper en plusieurs catégories :

  • Les technologies hybrides, qui consistent à développer un site web mobile à partir de HTML, CSS, JS et à le packager dans une “coquille” native. Parmi les frameworks les plus connus, on peut notamment citer Cordova et Ionic (s’appuyant lui-même sur Cordova). Le développement se base sur un socle commun (ou quasiment car il y a toujours des adaptations à faire selon l’OS). Cependant, bien que très satisfaisant dans beaucoup de cas, le résultat n’est pas toujours à la hauteur en terme de rendu ou performance selon la complexité de l’application.

On aurait pu également citer une autre technologie qui n’est pas une application mobile à proprement parler. Il s’agit des Progressive Web Apps ou PWA, qui permettent de proposer un site web responsive avec un peu plus de fonctionnalités qu’un site web normal (possibilité d’ouvrir le site en fullscreen sans la barre d’url, mode hors ligne, etc). En revanche, certaines fonctionnalités ne sont pas encore disponibles sur tous les navigateurs. On pense notamment aux push notifications qui ne sont pas fonctionnelles sous Safari sur iOS. Aussi, une PWA n’est pas disponible sur le Play Store ou l’App Store, ce qui peut poser un problème de visibilité.

Quelle technologie pour l’application Malt ?

Image for post
Image for post

Maintenant que nous avons listé les différents choix possibles, rentrons plus particulièrement dans le cas de Malt. Les applications Android et iOS de Malt sont… natives ! Avant de justifier ce choix, recontextualisons un peu les choses.

Les premiers développements de l’application Malt ont été effectués en 2019. Les choix de technologie et les réflexions autour des compétences à prévoir dans l’équipe ont été finalisés en 2018.

Les technologies hybrides type “site mobile” ont immédiatement été écartées. À cette époque, des frameworks comme Flutter n’étaient pas envisageables car bien trop récent (la première release stable de Flutter a été lancée en décembre 2018). Tandis que les solutions cross-plateformes type Xamarin ou React Native ont elles aussi été assez rapidement mise de côté. Le choix du natif a été justifié par plusieurs critères :

  • Le choix de l’application n’était pas drivé par les technologies maîtrisées en interne. En effet, parfois, certaines sociétés s’appuient sur des ressources existantes qui connaissent déjà certains langages pour amorcer le développement d’une application. On peut par exemple imaginer une équipe de développeurs .NET qui serait tentée de faire une application Xamarin ou une équipe React qui serait tentée par React Native. À noter que bien qu’il soit facilité, le passage d’une technologie de site web à une application mobile n’est pas automatique, et nécessite souvent de maîtriser certains concepts mobiles, voir parfois des spécificités natives. Dans le cas de Malt, on ne s’est pas forcément appuyé sur les ressources existantes car on a recruté une toute nouvelle équipe.

À ce sujet, je vous conseille le retour d’expérience de Airbnb sur React Native et les raisons qui les ont poussés à revenir à une application native. https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838

Il y a donc des avantages et des inconvénients pour chacune de ces solutions, mais c’est pour les raisons citées ci-dessus qu’il a été décidé de partir sur un développement natif.

Et comment on s’organise ?

Image for post
Image for post

Au démarrage du projet, l’équipe technique était composée de 3 personnes : un dev back, un dev iOS, et un dev Android (coucou c’est moi 😁)

Compte tenu de la taille de l’équipe et de sa vélocité, l’une des premières question à se poser est : “qu’est-ce qu’on embarque dans notre v1 et quand est-ce qu’on sort cette première version ?”. Se pose alors la question :

  • de partir sur un long développement en tunnel pour sortir une application avec un maximum de fonctionnalités réécrites en natif.

C’est cette dernière stratégie que nous avons privilégiée. Encore aujourd’hui, il reste des redirections vers les pages web du site Malt, qui devraient être, à terme, remplacées par des pages natives. Cette stratégie nous a permis notamment :

  • D’assurer de livrer une première version de l’application rapidement avec les fonctionnalités de bases

D’un point de vue technique, concrètement, il y avait tout à faire, autant côté mobile que côté webservices. Nous avons donc une application iOS écrite en Swift et une application Android écrite en Kotlin qui communiquent avec une API REST écrite en Kotlin. Cette dernière fait la passerelle entre les applications mobiles et les des différents microservices (messagerie, profils, etc).

Qui dit développement natif dit développement de deux applications distinctes. Cependant, nous essayons de mutualiser certaines choses, à commencer par :

Les “models”

Toutes les entités à manipuler via l’API REST sont générées à la fois en Swift et en Kotlin par un outillage maison côté back. Il ne reste qu’à les importer dans les projets iOS et Android respectifs. Cela a été un gain de temps précieux, en particulier au tout début du développement de l’application, lorsqu’il a fallu intégrer une multitude d’éléments pour communiquer avec l’API. Les changements d’API sont ainsi répercutés sur les différents projets de la même manière.

Les outils/services

L’application Android et iOS utilisent la même plateforme d’intégration continue, Bitrise. Le suivi des crashs des 2 plateformes se fait sur Firebase Crashlytics et le déploiement de l’application en interne se fait par Firebase App Distribution.

L’ensemble des maquettes de l’application est commun et centralisé dans Figma et les stories Jira sont communes aux deux OS, puis découpées en tâches dédiées pour chaque plateformes (car elles n’ont pas toujours le même rythme de développement).

Les traductions sont communes aux deux plateformes et les clés sont centralisées sur l’outil Phrase.

La concertation

Nous ne nous sommes pas imposés de contraintes de développements visant à écrire le code le plus ressemblant possible entre Android et iOS. Bien que nous visions un rendu quasi-identique, nous ne nous imposons pas de recopier une façon de faire d’une plateforme à une autre. Cependant, nous sommes systématiquement dans la concertation, pour trouver la façon efficace de développer une fonctionnalité sur chaque plateforme. Force est de constater que souvent, une façon de faire pour une plateforme est déclinable de la même façon sur l’autre.

Aussi, nous ne parallélisons pas forcément tous les développements. En effet, il n’est pas rare que nous partions en “éclaireur” seulement sur une plateforme pour éprouver des éléments techniques (webservices, etc) et ainsi faire gagner du temps lors du développement sur l’autre plateforme.

Conclusion

Il n’est pas toujours simple de choisir la technologie pour son projet mobile tant les choix sont nombreux et les critères déterminants (compétences, budgets, taille de l’application, taille de l’équipe, personnalisation des composants, etc). L’important est de rester en veille sur tous ces sujets pour avoir conscience des points forts et des points faibles de chaque solution, et ainsi pouvoir se projeter sur la meilleur organisation possible de l’équipe. Je vous invite aussi à consulter le dernier rapport Malt Tech Trends qui vous donnera un aperçu de l’évolution des tendances de ces diverses technologies.

nerds-malt

Tout ce qui se passe sous le capot par l’équipe R&D de Malt…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store