Tout le monde revient au natif. Votre app n'a jamais eu à le faire

Quand nous avons construit nos premiers moteurs, la question n'était pas quelle technologie produisait la meilleure app cette année-là. C'était quelle couche serait encore là dans dix ans. Les plateformes le seraient : Apple et Google n'allaient pas abandonner leurs systèmes, leurs outils, leurs SDK. Tout ce qu'il y avait entre les deux, les frameworks qui promettaient d'épargner les plateformes aux développeurs, devait encore gagner sa décennie d'existence. Nous avons donc construit directement sur la couche dont nous étions sûrs qu'elle resterait, et traité tout ce qui s'empilait dessus comme temporaire.

Les années suivantes ont mis cette lecture à l'épreuve. Tous les deux ou trois ans, un nouveau framework était présenté comme l'avenir du mobile : PhoneGap, React Native, Xamarin, Flutter. Nous avons évalué les plus sérieux et passé notre tour à chaque fois, sur la même question de durée de vie. Puis les réponses sont arrivées : Adobe a arrêté PhoneGap en 2020, Microsoft a mis fin au support de Xamarin en 2024. La couche intermédiaire n'a pas arrêté de changer de nom. iOS et Android ont gardé le leur.

Ce pari a un prix. Trois moteurs, ce sont trois équipes, trois expertises et trois implémentations à garder au pas, et c'est précisément pour cela que la plupart des entreprises qui construisent une seule app ne pouvaient pas se le permettre. Une plateforme le peut : les moteurs sont construits une fois et amortis sur chaque app qu'elle produit. Quinze ans d'expertise en création d'apps natives reposent sur cette arithmétique, et c'est aussi pourquoi ce coût ne vous atteint jamais. Les moteurs, l'hébergement, l'infrastructure de notifications push et la publication sur les stores sont compris dans l'abonnement.

Votre app repose sur la fondation qu'Apple et Google entretiennent eux-mêmes, pas sur une couche dont l'avenir dépend de la feuille de route d'une troisième entreprise. Quand un framework est abandonné, il ne se passe rien pour votre app. Quand iOS ou Android évolue, nos moteurs adoptent le changement une fois, de façon centralisée, et votre app est régénérée dans la nouvelle version sans que vous ayez à y toucher. Une app configurée il y a des années est une app à jour aujourd'hui.

Ça se voit aussi dans ce que vos utilisateurs ressentent, en dessous de ce que la plupart des gens savent nommer : un défilement qui suit exactement la physique du système, des transitions qui appartiennent au système d'exploitation, le retour haptique, une barre d'onglets flottante, un lecteur média qui continue quand l'écran s'éteint, des notifications locales qui se déclenchent depuis l'app elle-même quand quelqu'un entre dans une zone géographique, sans aucun serveur. Rien de tout cela ne se configure. Ça vient avec la façon dont l'app est construite, et vos utilisateurs le résument en un mot : « professionnel ».

Quelque chose a changé cette année dans la façon dont les équipes techniques parlent du mobile. En septembre 2026, Shopify a annoncé le retour de toutes ses apps mobiles vers Swift et Kotlin, six ans après avoir adopté React Native, et sa raison n'est pas que le natif se soit soudain amélioré. C'est que l'IA a supprimé la principale raison de l'éviter : le coût de construire la même app deux fois. Quand des modèles et des agents prennent en charge l'essentiel de la traduction et des tests entre plateformes, le code partagé perd son argument économique, et le langage propre à chaque plateforme redevient le choix par défaut.

Nous n'avons jamais eu à faire ce voyage, et le pari a payé d'une façon que nous n'avions pas prévue : nous comptions sur le temps pour le prouver, et la preuve est venue de l'IA. Notre Head of Frontend Engineering, Mathieu Poli, raconte cette histoire de l'intérieur, y compris les frameworks que nous avons évalués en chemin : Tout le monde revient au natif. Nous, on n'est jamais partis.

Posez une seule question : que produit réellement la plateforme ? Un binaire Swift compilé et un binaire Kotlin compilé, soumis aux deux stores en votre nom, sont un objet différent d'une app web emballée pour le mobile. Demandez à voir une app tourner sur un vrai téléphone, et prêtez attention au défilement, aux transitions et à la barre d'onglets. Si la réponse est « natif », vous le sentirez avant qu'on vous l'explique.

Vous pouvez le tester vous-même : démarrez un essai gratuit, construisez une première version de votre app, et installez-la sur votre téléphone.

Les apps GoodBarber sont-elles vraiment natives ?

Oui. L'app iOS est compilée en Swift et l'app Android en Kotlin, et les deux sont soumises à l'App Store et à Google Play sous forme de vrais binaires, en votre nom. Le troisième moteur, la Progressive Web App, tourne dans le navigateur, et c'est voulu.

Application native ou PWA, que choisir ?

Les deux sortent du même projet GoodBarber, la question se pose donc rarement en ces termes ; choisir entre un site web, une app et une PWA a son propre article. Les apps natives sont celles que vos utilisateurs trouvent dans les stores et celles qui vous donnent le défilement, les transitions et les fonctions de l'appareil propres à chaque plateforme ; la PWA ajoute le navigateur et l'ordinateur.

Une application native coûte-t-elle plus cher ?

Pas avec un app builder. Les moteurs sont construits une fois et amortis sur toutes les apps de la plateforme, si bien que leur coût, avec l'hébergement, l'infrastructure push et la publication sur les stores, est compris dans l'abonnement. Le prix de construire deux fois ne concerne que le développement sur mesure, et c'est la raison pour laquelle le secteur a cherché des alternatives.