État de l’art des solutions cross-platform mobile

Nos clients nous demandent parfois quel est notre avis sur les solutions qui permettent de mutualiser du code, afin d’éviter d’écrire tout deux fois. Nous allons voir dans cet article, les solutions qui existent et ce qu’elles proposent que ce soit en terme de budget, de temps de développement ou de staffing. Sans ces solutions il est nécessaire de re-développer les mêmes fonctionnalités sur chacune des plateformes. L’entreprise doit alors écrire et maintenir plusieurs implémentations de code qui en théorie fait la même chose et il peut être difficile pour elles de s’accorder afin de pouvoir délivrer les mêmes fonctionnalités au même moment pour chaque plateforme.

Comme à son époque pour le monde PC, les solutions cross-platform ont fait leur apparition pour le monde mobile et abordent souvent le problème de manières différentes.

Chez Octo on recherche une solution qui permette de partager proprement du code entre Android & iOS. On porte une attention toute particulière aux critères de performance, de testabilité, d’expérience utilisateur ainsi qu’à l’engouement et à l’activité de la communauté.

Une place au soleil

Il existe énormément de solutions et chacune cherche à s’imposer. Certaines choisissent de sacrifier les performances au profit d’une mutualisation et d’une portabilité complète tandis que d’autres cherchent à maximiser les performances et l’interaction avec l’environnement natif quitte à ne mutualiser que certaines parties de votre application.

Le tableau suivant liste les solutions disponibles actuellement sur le marché :

TABLE 1 – Résultats des recherches de solutions cross-platform

Qui se ressemble s’assemble

De manière générale, les solutions cross-platform mobile se ressemblent beaucoup dans leur mode de fonctionnement pour la plupart et peuvent être rangées parmi trois catégories que je définirais ainsi :

  1. Les solutions full cross-platform
  2. Les solutions semi cross-platform
  3. Les solutions featured cross-platform

Les solutions full cross-platform

Ces solutions doivent leur grande compatibilité aux technologies web. Elles produisent des webapps. Elles sont donc limitées en terme de performance, d’intégration et de fonctionnalités au sein de la plateforme dans laquelle elles évoluent. Elles n’ont pas d’accès aux API spécifiques de chaque plateforme, l’accès aux composants de l’appareil leurs sont également limitées. Ces solutions apportent également avec elles toutes les vulnérabilités liées aux technologies du web.

Leur plus grand atout est leur portabilité, elles permettent de rendre disponible une application sur un grand nombre de plateformes même au delà du monde mobile sur la base d’un seul et unique code. Il est indéniable que le temps de développement est largement réduit avec ce type de solution.

FIGURE 1 – Full cross-platform

On pourra citer des solutions comme Cordova, Titanium qui semblent s’être imposées sur cette catégorie de solution. Qt et Kivy sont des cas particuliers qui pour leur part ne produisent pas de webapps mais essaient d’imiter le comportement des éléments natifs (boutons, checkbox,…) de l’environnement afin d’obtenir de meilleures performances qu’une webapp. (1) 

Les solutions semi-cross-platform

Ce deuxième type de solution se propose de mutualiser le code métier en gardant native la gestion des vues. Toute la couche métier est alors développée indépendamment de la plateforme dans laquelle elle évolue sur la base d’un seul et même code tandis que la couche s’occupant de l’interface utilisateur appel les éléments natifs à chaque plateforme. Le but est ici de dégrader le moins possible les performances et de conserver une expérience utilisateur optimale qui sont les deux reproches faites aux solutions full cross-platform.

FIGURE 2 – Semi cross-platform

On pourra citer des solutions comme React Native ou Xamarin mais aussi Flutter ou Ionic qui semblent prometteurs.

Les solutions featured-cross-platform

Le but ici est de maximiser les performances en ne mutualisant que certaines fonctionnalités de l’application (ie : un algorithme de tri particulier, un traitement spécifique sur un jeu de donnée, etc).

Pour ce type de solutions les performances sont au rendez-vous et la gestion des vues reste également native. On intègre le code cross platform sous forme de librairies annexes permettant ainsi à notre projet de garder l’accès aux fonctionnalités spécifiques à chaque plateforme (via le SDK dédié).

FIGURE 3 – Featured cross-platform

On note qu’avec ce type de solutions la mutualisation n’est pas complète et que certaines parties de l’application seront toujours écrites en plusieurs exemplaires. Ces solutions utilisent généralement des langages comme Golang ou C++ que l’on devra encapsuler à notre projet en produisant du code JNI ou Objective-C++. (2)

Chez Octo les projets suivent le principe de Clean architecture[1]. La structure du projet est alors découpée en couches. Une couche Repository, qui s’occupe de récupérer les données. Une couche Core, qui s’occupera de traiter les données que lui aura précédemment transmise la couche Repository. Et enfin la View qui s’occupe uniquement de présenter les données qui lui sont transmises à l’aide de son Presenter.

On remarque que chaque couche a une tâche spécifique. Par exemple la couche Core ne fait que traiter des données grâce aux règles métiers qu’elle contient. Cette couche doit pouvoir être agnostique de la technologie et donc être écrite en n’importe quel langage. Pourquoi ne pas essayer de mutualiser cette couche dans ce cas ? Les interactors représentent les règles métiers et sont rattachés au Core. Leur fonctionnement est identique que ce soit sur Android et iOS, ils traitent les données de la même manière, et il parait rébarbatif de réécrire ces interactors deux fois.

L’idéal serait de pouvoir mutualiser certains composants de cette architecture et la solution featured cross-platform semble à première vue la mieux adaptée. Elle a l’avantage d’être assez souple et n’implique pas, contrairement aux deux autres, de dépendances fortes jusqu’au niveau du controller. Cette plus grande souplesse pourrait permettre de conserver cette structure de Clean Architecture tout en mutualisant du code entre Android et iOS.

Vers une mise en production

Ok, dans les faits cela fonctionne mais quelqu’un a-t-il réellement entrepris d’utiliser ce type de solutions pour de vrais projets ? On sait que les projets client demandent une exigence toute particulière et intégrer une solution cross-platform ne doit pas se faire au détriment de la productivité de l’équipe. La réponse est oui.

Durant la CppCon 2014[2], Dropbox a annoncé avoir entrepris des travaux autour de la mutualisation de code entre iOS & Android. Ils ont commencé par faire l’expérience sur leur application de gestion de photos, Carousel, puis ont entrepris de mutualiser une partie de leur application iOS Mailbox en C++ au moment du portage de cette même application sur l’environnement Android. Ils sont d’ailleurs à l’origine de l’outil Djinni qui permet de générer des wrappers afin d’intégrer votre code C++ à vos projets iOS/Android.

Ensuite Facebook et LinkedIn ont tous deux commencé avec une application full-cross platform avant d’abandonner au vu des performances et de l’expérience utilisateur qui s’en trouvait dégradée. Cependant Facebook utilise React Native pour son application Ads Manager de même que Soundcloud.

Finalement beaucoup d’entreprises se tournent vers le full-cross-platform pour des questions de portabilité et de budget. Ces solutions possèdent aussi le plus haut chiffre d’abandon par ces sociétés..

Et maintenant …

Les avantages du cross platform semblent évident et ils permettraient de réduire le temps de développement d’un projet qui souhaiterait posséder une application sur les deux environnements, à savoir Android et iOS. Est-ce vraiment avantageux ? Chez Octo nous travaillons avec le concept de Clean Architecture mais pas seulement ! Tout le déploiement est entièrement automatisé et si une solution cross-platform venait à casser ce processus ce serait une perte de temps et de productivité importante même au vue des avantages que le cross-platform apporterait. Il est donc impératif que cette solution cross-platform s’intègre dans ce processus d’intégration continue.


FIGURE 4 – Solution cross-platform en C.I
  1. Pages web encapsulées dans des webviews
  2. Des outils existent afin de générer ces wrappers comme Djinni ou SWIG

Références

  1. Uncle Bob. The Clean Architecture | 8th Light.  Aug. 2012. (Accessed on 06/04/2017).
  2. Ole Begemann. How dropbox uses c++ for cross-platform ios and android development, May 2014. (Accessed on 07/02/2017).
  3.  T.Grue&S.Kabbes.Adeepdiveinto2cross-platformmobileappswritteninc++, 2014. (Accessed on 07/02/2017).
  4. Jan Monschke & Peter Minarik. React native at soundcloud, August 2016. (Accessed on 21/02/2017).
  5.  Alex Allain & Andrew Twyman. Practical cross-platform mobile c++ development, 2014. (Accessed on 07/02/2017).
  6.  Daniel Witte & Philipp von Weitershausen. How we built the first cross-platform react native app, May 2015. (Accessed on 22/02/2017).

4 commentaires sur “État de l’art des solutions cross-platform mobile”

  • On pourrait rajouter Framework7 http://framework7.io/ comme solution semi-cross-platform.
  • C'est effectivement le cas, si Framework7 utilise directement les vues natives aux plateformes Android/iOS. Sinon il se rangera dans la catégorie full-cross-platform.
  • Appcelerator Titanium est de type "semi-cross-platform" et non du web.
  • Je m'étonnes de ne pas trouver Unity3D et Xamarin dans la même colonne ... (peu importe vos dénominations) : mais il me semble que dans les deux cas : on produit une UI (Via Xamarin.Forms ou en tant que scene) et qu'ensuite on compile en natif pour chaque plateforme ...
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha