Facebook a allégé Messenger sur iOS en repartant de zéro 🆕

Nicolas Furno |

Facebook a présenté hier une nouvelle version iOS de Messenger, l’une de ses messageries instantanées. La principale caractéristique de cette mise à jour est de simplifier l’app devenue très complexe au fil des années. Elle est aussi nettement plus légère et plus rapide, ce qui est la conséquence d’une réécriture complète de son code, comme le détaille le réseau social dans cet article technique.

Le « projet Lightspeed » a été lancé l’an dernier avec l’objectif de repartir de zéro et de créer une messagerie instantanée plus moderne. Messenger est née en 2011 et l’app n’a cessé de grossir depuis, à tel point qu’une réécriture complète a été lancée il y a un an. Réécrire totalement le code d’une app est toujours un projet dangereux, surtout si vous n’avez pas les ressources de Facebook.

Ce projet a mobilisé plus de cent ingénieurs à son plus fort sur l’année passée. Le résultat en valait sans doute la chandelle toutefois : la nouvelle app est constituée de 360 000 lignes seulement. Seulement ? Oui, car l’ancienne version nécessitait 1,7 millions de lignes de code… Résultat, la nouvelle app Messenger ne pèse qu’un quart du poids de la précédente et elle démarre deux fois plus rapidement.

Schéma de Facebook pour expliquer la relation entre l’app et sa base de données locale d’un côté et le serveur de l’autre.

L’article publié par Facebook détaille en des termes simples et faciles à comprendre certains choix effectués pour obtenir la nouvelle app, même si l’entreprise reste floue sur la technologie utilisée. On sait en revanche que l’app n’utilise plus de framework d’interface tiers et repose directement sur iOS et les fonctions proposées par Apple.

Sous le capot, Messenger reste une app complexe qui a nécessité la création d’une brique multiplateforme en C pour gérer l’interface à partir des informations fournies par une base de données SQLite en local, et à partir des serveurs de Facebook.

MàJ le 03/03/2020 11:53 : Messenger reposait déjà sur du code natif, ce n’est pas un changement de choix technologique (depuis React Native vers du natif) qui a justifié les gains liés à la réécriture. L’article a été modifié en conséquences et je vous présente mes excuses pour cette erreur d’interprétation (merci @sebastienlorber).

avatar Ririii | 

Le natif c’est la vie 😁 ! Mais perso j’me rends compte que plusieurs apps qui ont été développées avec des technos multiplateformes finissent par revenir sur du développement natif. J’ai jamais été fan de l’hybride. Pour avoir testé, le but final c’est de gagner de l’argent, cependant il y a toujours des problèmes dans le développement et toujours pas mal de spécifique à produire pour chaque plateforme. Au final, avec le natif il y a plus de contrôle que ce soit au niveau du code, de la communauté et des différents outils mis à notre disposition.

avatar mimolette51 | 

Natif en JS LOL!!!!!!!!!!!!!!!!!

avatar Glop0606 | 

Personnellement, ce qui me fait rire doucement, c'est quand des boîtes comme Facebook "économise" sur le développement d'une App en faisant de l'hybride. Avec les XX milliards de bénéfices chaque trimestre y'a de quoi largement payer deux équipes de développement. Ca me rappelle la news avec Instagram sur Ipad: "On a pas assez de ressources", cte blague. Après Messenger c'est facebook donc de toute façon ne sera jamais installé sur mon iphone. J'attends juste que Facebook décide de fusionner messenger et what's app, histoire que mes collègues passent en masse sur Signal :)

avatar RedMak | 

@Glop0606

Le n’est pas forcément de gagner de l’argent mais d’aller vite et livrer des mise à jour plus rapidement (ce qui est pas forcément une mauvaise idée quand tu commence à développer ton startup)
Mais bon, ils ont vu les limites de cette approche.

avatar Paquito06 | 

@Glop0606

“Personnellement, ce qui me fait rire doucement, c'est quand des boîtes comme Facebook "économise" sur le développement d'une App en faisant de l'hybride. Avec les XX milliards de bénéfices chaque trimestre y'a de quoi largement payer deux équipes de développement. Ca me rappelle la news avec Instagram sur Ipad: "On a pas assez de ressources", cte blague.”

Question de priorité. Ils allouent leurs ressources sur du hardware. L’application Messenger existe et tourne bien. L’alleger pour faire plaisir a 2 pékins qui n’ont pas une bonne connection ou un vieux portable, c’est pas leur priorité. Oculus ou Portal le sont. Bien sur, sur le papier ils ont les moyens, ils peuvent meme aller sur la lune ou racheter 50 startups, mais c’est pas leur priorité, encore une fois.

avatar Maitre muqueux | 

« Extrêmement complexe »
Ola la la c’est dur l’informatique
Allez voir du côté de Snapchat plutôt
Même
Ma mère sait faire marcher messenger

avatar romainB84 | 

@Maitre muqueux

C’est clair !!
Envois vite ton CV!
A toi tout seul, tu vas leur refaire leur appli, et eux ils vont économiser le coût de 100 développeurs 😁

avatar Florent Morin | 

Ça fait penser à AirBnb qui avait mis en avant React Native. Et est revenu au natif 2 ans plus tard.

Ou Betclic, qui avait choisi Xamarin (le Flutter de Microsoft) avant de revenir au natif en urgence.

avatar reborn | 

Ça permet à l’app de fonctionner de manière fluide sur de vieux iPhone.

Ils ont mis 100 devs sur le coup, pour une boite de la taille de facebook c’est énorme ?

Je me souviens du temps de msn messenger, l’app pesait 8 mo et était écrite en c++

Il s’est passé quoi en temps pour qu’on s’émerveille du développement d’une app de chat ?

avatar Chris K | 

@reborn

Je dirai que c’est pas tellement la taille de la société qui compte mais sa capacité à gérer et coordonner les développeurs et donc l’avancement du projet.
100 ça parait beaucoup (surtout pour 360 000 lignes de code :-) mais on ne sait pas (dans cet article du moins) comment ces ressources ont été réparties (vraisemblablement pas uniquement à l’écriture de l’app en elle même). Visiblement ça a fonctionné.

avatar vince29 | 

99 ingés et un tech développeur.
99 c'est bien, c'est impair. Il suffit de poser une question qui implique une réponse binaire pour que les 99 ingés puissent se mettre d'accord.

avatar BeePotato | 

@ reborn : « Je me souviens du temps de msn messenger, l’app pesait 8 mo et était écrite en c++ »

Là, elle est écrite en C et en on-ne-sait-pas-quoi-d’autre, et elle pèse un peu plus que 8 Mo — mais l’augmentation de la résolution des écrans depuis cette époque reculée justifie une certaine prise de poids du fait de ressources graphiques d’une définition bien plus élevée qu’autrefois.

« Il s’est passé quoi en temps pour qu’on s’émerveille du développement d’une app de chat ? »

Je ne crois pas qu’ici (dans l’article de MacG, pas dans celui de Facebook) on soit en train de s’en émerveiller. J’ai plus l’impression qu’on ricane gentiment face à un Facebook semblant découvrir les vertus du développement natif et de la programmation propre (il y a tout de même un passage de l’article d’origine qui explique qu’ils sont passés d’une quarantaine d’implémentations distinctes d’une liste de contact (dans l’appli précédente) à une seule vue modulaire capable d’être utilisée à la place de tout ça (dans la nouvelle appli)).

avatar alitaliano | 

Trop tard, j’avais désinstallé cette merde il y a un an suite aux mises à jour tous les trois jours de plus de 200 Mo…

avatar Rez2a | 

Si même Facebook abandonne React Native, c’est un sacré signal que ça envoie aux développeurs qui l’utilisent... j’ai du mal à voir pourquoi ils feraient la pub de revenir au natif.

avatar oomu | 

"Facebook redécouvre les avantages du développement natif"

comme tout le monde, comme tout le monde, chaque décennie, en boucle, sans cesse

HA ! Y a un nouveau atelier-outil moultiplateforme agile tout-en-un réactif-interactif avec nouvelle syntaxe top-cool-moumoute (mais vAAaguement-totalement reprise de C/Java) orienté IOT/Serveur/VR/Tablette/Souris ! Vite à vos séminaires (payants) et vos rachats de logiciels et certifications (payantes)

youhouhouohuuuuu

avatar oomu | 

"Sous le capot, Messenger reste une app complexe qui a nécessité la création d’une brique multiplateforme en C pour gérer l’interface à partir des informations fournies par une base de données SQLite en local"

vachement complexe dit. Y a même du sqlite en LAUKALEUH ?!

avatar TheG | 

Y a un bug chez moi
J avais désactivé le “activity status” qui permet de voir avec une pastille verte quand on est en ligne et l heure de la dernière connexion (commets il y a xxx minutes / heures).
Souvent quand il y a une nouvelle version ça remet certains settings à 0
Donc je refais la manip mais ça change rien....
Du coup je suis allé vérifier depuis l app Facebook si il y avait une mauvais synchronisation entre les deux des settings. Ce qui était le cas j ai désactivé depuis l app aussi mais rien n y fait ....

avatar geooooooooffrey | 

Pas sûr que ce soit un bug...

avatar Kaarlito | 

Est.ce qu'en terme consommation énergétique, cela économise-t-il la batterie des portables, et moins de lignes de code permettent-elles aussi une demande moins accrue en énergie d'un réseau?

avatar dodomu | 

@Kaarlito

A priori, oui, et non.
Le code natif sera généralement plus rapide et économe qu’un code générique, car il y a moins de couches d’abstraction entre la machine et le code de l’application elle même. De plus ce genre de code est plus facilement optimisable (ce qui ne veut pas forcement dire qu’il l’est!). On peut aussi penser que les briques logicielles d’interfaces natives sont elles même plus optimisées pour l’affichage de boutons (et autres composants d’interface graphique) que le moteur de rendu web natif a la plateforme, qui même si natif, doit gérer toutes la variété des possibilités web, ce que n’a pas a faire la « simple » briques de gestion dés interfaces.
Concernant le nombre de ligne de code, ça dépend vraiment ce qu’elles font, en général moins de ligne de code apporte une facilité de développement et de maintenance du code. Dans le cas présent, si les lignes retirées était des duplicatas de fonctions natives, on peut penser que le résultat sera plus économe. Dans le cas contraire, difficile d’émettre un avis sans plus de détails...

avatar Krysten2001 | 

Il y avait aussi la nouvelle compression sur l’app store aussi non ? Présentez avec iOS 13

avatar BeePotato | 

Extrait de l’article de Facebook : « What had changed since we first began developing Messenger nearly a decade earlier? Quite a lot, it turns out. In fact, the way mobile apps are written has fundamentally changed. »

Ah.
Je n’étais pas au courant qu’il y avait eu un changement « fondamental » dans le principe de développement des applications ces dix dernières années.

avatar Aimable | 

J’ai la version 241.1 installé sur cet iPhone. Elle pèse 136 Mo d’après le menu stockage. La mise à jour 254.0 dispo sur App Store ce jour pèse 142,6 Mo.
Je ne vois pas comment l’app a maigri 🤔

CONNEXION UTILISATEUR