Natif ou multiplateforme : comment nous choisissons vraiment

Les équipes arrivent souvent en ayant déjà choisi leur camp, généralement à cause d’un article ou d’un prestataire précédent. Nous préférons partir des contraintes, car la bonne réponse change d’un projet à l’autre — et parfois à l’intérieur d’un même projet.

Notre choix par défaut est Flutter

Lorsqu’une application sort sur iOS et Android et que l’interface est pour l’essentiel la même, une seule base de code Flutter est le choix pragmatique. Vous obtenez une interface identique au pixel près sur les deux plateformes, une seule logique métier à tester, et une équipe au lieu de deux. Pour la plupart des produits, c’est le chemin le moins cher vers le même résultat.

Quand nous passons au natif

—L’application a besoin d’une profondeur que nul pont ne peut atteindre : contrôle fin de la caméra, traitement en arrière-plan, ou une intégration système qui n’existe que dans le SDK natif.

—La performance est le produit. Si l’application vit ou meurt sur un rendu parfaitement fluide ou un calcul lourd sur l’appareil, le runtime natif supprime une couche de doute.

—Vous avez déjà une équipe native. La meilleure stack est souvent celle que vos équipes pourront maintenir après notre départ.

Ce qui ne tranche pas

Les différences de taille d’application, le langage dans lequel un framework est écrit et les graphiques comparant le défilement de listes n’ont presque jamais d’importance à l’échelle où opèrent la plupart des produits. Notre propre confort non plus. Si le multiplateforme nous faisait gagner du temps mais vous coûtait la fonctionnalité dont dépend votre produit, c’est le mauvais choix et nous vous le dirons.

Le cas hybride

Certains produits sont mieux servis par une base de code partagée avec un ou deux modules natifs derrière un canal de plateforme. C’est plus de travail qu’il n’y paraît et nous n’y recourons pas d’emblée, mais pour une application faite à quatre-vingt-dix pour cent d’écrans ordinaires et à dix pour cent d’accès au matériel, c’est souvent la réponse honnête.

Tranchez pendant le cadrage

Ce choix se fait dans les premiers jours d’un projet, pas après le design. Il façonne l’architecture, les recrutements que vous ferez plus tard et le coût de la deuxième plateforme. Nous consignons la décision et ses raisons, pour que dans un an personne n’ait à deviner pourquoi le projet a pris cette direction.