Etat de l’art des technologies mobiles

Il existe actuellement trois types d’applications mobiles : hybrides, multi-plateformes et natives. Dans cet article, je vais les définir car il est important de comprendre la différence entre les trois ainsi que leurs avantages et inconvénients pour choisir celui qui sera le plus adapté à l’application que l’on veut développer. Avant ma conclusion, je ferai un aparté sur les progressive web apps qui sont une sorte d’application mobile un petit peu différente.

Applications hybrides

Il est difficile de trouver une définition universelle des applications hybrides, notamment en comparaison avec les applications cross-platform. Je vais donc donner ici ma définition.

Les applications hybrides sont des applications codées à partir d’une seule base de code. En revanche, elles sont disponibles pour différents types d’appareils : téléphones Android, téléphones iOS et depuis n’importe quel navigateur internet. Elles utilisent, grâce à des plugins, certaines fonctionnalités natives telles que l’appareil photo, la localisation ou l’accès aux fichiers. Ensuite, le code unique est converti en code natif pour chaque plateforme. Les applications sont rendues grâce à un composant unique appelé Webview, un navigateur internet simplifié intégré à l’application.

Le framework hybride le plus connu est Ionic, même si d’autres sont en usage, comme Apache Cordova qui peut être utilisé pour n’importe quelle application JavaScript.

Applications multi-plateformes

Les applications multi-plateformes (cross-platform en anglais) ont, comme les applications hybrides, la possibilité de partager le code entre les différentes plateformes sur lesquelles les applications seront déployées.

On retrouve des applications en React Native développé par Facebook sur une base de JavaScript, Xamarin développé par Microsoft et utilise C# ou Flutter développé par Google avec son propre langage Dart. Flutter expérimente une bêta pour fonctionner également sur les navigateurs web.

Par exemple, pour les applications React Native, on peut voir sur le schéma ci-dessous que l’accès aux fonctionnalités natives passe par des ponts JavaScript qui convertissent le code source en code interprétable par l’une ou l’autre des plateformes. Le code JavaScript tourne dans une machine virtuelle qui est capable de communiquer avec les API natives.

Fonctionnement application React Native [1]

Cette technologie permet en particulier de proposer une expérience utilisateur enrichie car l’application réalisée aura un aspect et un ressenti “natif”. Le code source est unique, mais le code converti utilise les composants natifs pour créer les applications. C’est pour cela que les applications sont disponibles pour Android et iOS uniquement.

Applications natives

Ce sont, comme leur appellation le laisse imaginer, les applications uniquement écrites pour fonctionner sous Android et iOS séparément. Elles sont développées en Java ou Kotlin pour Android et Objective-C ou Swift pour iOS.

Zoom sur Android

Java est un des langages de programmation utilisés pour créer des applications Android. Depuis 2016, Kotlin a amélioré le langage Java en apportant des fonctionnalités et des facilités pour le développeur. L’objectif premier de Kotlin était d’améliorer la qualité du code par rapport au langage Java, en permettant une sécurité contre le nullité des variables, ainsi qu’un kit de développement plus complet.

Voici les principales différences entre Java et Kotlin :

  • Kotlin ajoute une sécurité en empêchant que les variables soient “null”, sauf si le développeur l’indique explicitement. Ceci supprime le problème d’exceptions du type “Null Pointer Exception” récurrent en Java.
  • Les classes ne contenant que les modèles de données peuvent être fastidieuses à développer en Java et une source d’erreur de programmation car il faut, en plus des champs de données, renseigner les getters, les setters et les constructeurs. Alors qu’en Kotlin, il suffit de lister les champs qui constituent la data class.
  • Kotlin est compatible avec la programmation fonctionnelle. Ce paradigme de programmation vise à construire les programmes en appliquant et en composant les fonctions plutôt que de changer l’état global. Java a intégré cette capacité à partir de sa 8è version, soit la version maximale compatible pour le développement d’applications Android. Ceci permet à Kotlin de bénéficier de fonctionnalités telles que les fonctions lambdas, les fonctions d’ordres supérieurs (Higher Order Functions) ou encore l’évaluation des variables en lazy.

Comparaison

Bien que l’objectif des trois types d’applications citées ci-dessus soit le même, elles diffèrent principalement sur cinq critères :

  • La performance,
  • Le budget,
  • Le Time-to-market (le temps nécessaire avant que l’application ne soit disponible sur le marché),
  • L’Interface Utilisateur et l’Expérience Utilisateur (UI / UX),
  • Les fonctionnalités.

[2]

Native

Hybride

Cross-platform

Performance

Très bonne

Mauvaise  lorsqu’il y a beaucoup d’animations ou d’images

Moyenne

Budget

Important car il faut développer pour chaque plateforme

Faible car une seule base de code

Time-to-market

Important car il faut développer 2 applications

Très rapide

Rapide

UI/UX

Conforme aux directives donc correspond à ce qu’attend l’utilisateur

Même rendu sur iOS et Android par défaut, donc peut ne pas tenir compte des directives

Les animations peuvent être moins fluide que sur du natif, mais le reste est proche du natif 

Fonctionnalités

Très proche de l’OS donc faciles d’accès

Certains plugins permettent d’utiliser les fonctionnalités natives, mais cela rajoute de la complexité et est parfois impossible

Les ponts permettent un accès plus facile aux fonctionnalités proches de l’OS, mais il reste parfois quelques fonctionnalités qui sont impossibles à implémenter sans rajouter du code natif (ex : lecteur vidéo)

Dépendances aux librairies open-source

Faible

Forte

Moteur de rendu

Natif

Navigateur (WebView)

Natif

Courbe d’apprentissage

Peut être assez longue

Rapide si on a déjà fait des applications web

Acceptable

Un critère essentiel lors du choix du type d’application est la performance. C’est pour quantifier les écarts réels entre les trois types d’applications que des développeurs de la société inVerita ont réalisé un benchmark test [3] entre des applications similaires, développées en React Native, en Flutter et native sur iOS et Android.

Leur conclusion est que les applications natives sont largement plus rapides et moins consommatrices de batterie et de mémoire lors d’opérations gourmandes telles que l’animation ou le chargement de très nombreuses images. Cependant, il est intéressant de noter que Flutter, par exemple, n’est pas si loin derrière. Le choix de la technologie dépendant évidemment du cas d’utilisation, on peut considérer que pour des applications ne nécessitant pas beaucoup de calcul, les applications multi-plateformes satisferont tout à fait les contraintes de performance. Même React Native qui est très consommateur de ressources à cause du pont JS, pourra constituer une base raisonnable. De plus, développer pour deux plateformes entraîne forcément un coût plus conséquent à la création, puis en termes de maintenance. Les développements d’applications hybrides ou cross-platform (React Native, Flutter ou même Ionic) permettent une optimisation sensible, ce qui justifie probablement leur popularité.

Quid des PWA ?

Les Progressive Web Apps ne sont pas à proprement parler des applications mobiles, c’est pour cela que je ne les ai pas incluses dans le corps de l’article. Cependant, il me semblait important de les mentionner pour lever le voile sur la confusion.

Les PWA sont des applications web, comme leur nom l’indique, qui vont être optimisées pour mieux fonctionner sur des appareils mobiles. Elles vont également présenter quelques fonctionnalités supplémentaires par rapport à un site web classique [4] :

  • Mode hors-ligne
  • Meilleures performances
  • Tâches en arrière-plan dans un thread séparé
  • Accès aux capteurs du téléphone
  • Notifications (mais pas sur iOS)
  • Raccourci sur la page d’accueil du téléphone

Elles ne vont cependant pas nécessiter une installation comme une application mobile par exemple. Apple est donc assez opposé au principe des PWA pour deux raisons principales :

  • Les PWA  n’apportent rien de plus qu’un site web, donc cela va à l’encontre de leurs principes (Minimum Functionality, App Store Review Guidelines).
  • Comme elles ne nécessitent pas d’être déployées sur les stores pour être accessibles à l’utilisateur, Apple ne pourrait pas effectuer de tests avant que l’application ne soit déployée sur l’App Store. Ils ne pourraient ainsi plus garantir la qualité des applications pour iOS.

Quel type d’application pour quel cas d’usage ?

Diagramme décisionnel des cas d’usage des applications mobiles [5]

Conclusion

On entend parfois parler de générations d’applications mobiles. La première génération serait les applications natives. Ensuite viendraient les applications hybrides. Ce concept a été optimisé pour ne plus être dans une Webview et la 3è génération serait née avec les applications cross-platform. Et enfin, la 4è génération d’applications mobiles serait les PWA. Pourtant, d’une part, les PWA ne sont pas réellement des applications mobiles. Et d’autre part, comme nous l’avons vu au cours de cet article, les “générations”  d’applications mobiles ne sont pas mutuellement exclusives. Au contraire, elles présentent des avantages et inconvénients différents, leur permettant d’être adaptées à différents besoins.

Références

[1] Source : Behind the Scenes,React Native - DEV

[2] Source : Native vs. Hybrid vs. Cross-Platform: How and What to Choose?

[3] Source : Flutter vs React Native vs Native: Deep Performance Comparison | by inVerita | The Startup | Jun, 2020

[4] Source : Progressive web application

[5] Source : Native vs. Hybrid vs. Cross-Platform - What Your Product Needs


Vous avez trouvé cette publication utile? Cliquer sur