Flutter ou développement natif en Swift et Kotlin : quand une seule base de code suffit

Flutter ou natif : le tableau comparatif

Le développement natif consiste à écrire l'application iOS en Swift, avec SwiftUI ou UIKit, et l'application Android en Kotlin, avec les outils d'Apple et de Google. Flutter, framework open source géré par Google et publié sous licence BSD 3-Clause, produit les deux applications à partir d'une seule base de code écrite en Dart.

Comment Flutter accède-t-il aux fonctions natives du téléphone ?

Flutter accède aux fonctions du téléphone par trois mécanismes documentés : les plugins, les canaux de plateforme et l'interopérabilité directe.

1. Les plugins : des paquets publiés sur pub.dev qui enveloppent une API native. La documentation de Flutter associe par exemple StoreKit (achats intégrés) au plugin in_app_purchase, CoreLocation au plugin geolocator, HealthKit au plugin health et WidgetKit au plugin home_widget.
2. Les canaux de plateforme : quand aucun plugin ne convient, le code Dart envoie des messages asynchrones à du code écrit en Kotlin ou Java sur Android, en Swift ou Objective-C sur iOS. Le paquet Pigeon génère ce code de liaison de façon typée, sans correspondances de chaînes de caractères à maintenir à la main.
3. L'interopérabilité directe : Dart FFI appelle des bibliothèques en C, et les outils jnigen et ffigen génèrent les liaisons vers Java, Kotlin, Objective-C ou Swift. Selon la documentation de Flutter, FFI peut être nettement plus rapide que les canaux de plateforme, faute de sérialisation des données.

La documentation Android de Flutter l'affirme sans détour : une application Flutter sur Android peut utiliser les dernières API dès le jour de leur sortie. La vraie question n'est donc pas « est-ce possible ? » mais « combien de code natif faudra-t-il écrire et maintenir à côté ? ».

Dans quels cas le développement natif s'impose-t-il ?

Le natif s'impose quand le code propre à la plateforme devient le cœur de l'application au lieu d'une exception.

• Un SDK matériel propriétaire : un robot, un terminal de paiement ou un lecteur industriel livré avec un SDK Android ou iOS. Envelopper tout le SDK dans des canaux revient à écrire l'application deux fois.
• Une seule plateforme : une application qui tourne sur un appareil Android dédié, ou uniquement sur iPad, ne tire aucun profit du multiplateforme.
• Des extensions système au premier plan : si l'essentiel de l'usage se passe dans un widget d'écran d'accueil ou une extension de partage, l'application principale devient secondaire. Flutter sait afficher son interface dans certaines extensions iOS, mais sa documentation rappelle que leur mémoire est limitée et conseille de ne le faire que si l'extension dispose d'au moins 100 Mo.
• Beaucoup de vues natives imbriquées : Flutter peut afficher une vue native, comme une carte, au milieu de son interface, mais sa documentation signale un surcoût de synchronisation et réserve cette technique aux composants complexes comme Google Maps. Sur Android, le mode de composition hybride peut faire baisser la fluidité de l'interface Flutter.
• Suivre au plus près le design du système : Selon sa documentation, une application Flutter garde la même apparence sur toutes les versions du système, même quand celui-ci change ses propres composants. C'est un atout pour respecter une charte graphique, une contrainte si vous voulez adopter immédiatement chaque évolution visuelle d'iOS ou d'Android.

Coûts et maintenance : une base de code ou deux ?

À fonctionnalités égales, deux applications natives demandent d'écrire, de tester et de maintenir deux fois la logique d'interface, avec deux compétences distinctes. Flutter mutualise ce travail : une correction ou une nouvelle fonction se développe une fois et part sur les deux stores.

Le multiplateforme a aussi des coûts propres, à regarder en face :

• la dépendance à des plugins tiers, parfois maintenus par des contributeurs indépendants : chaque plugin critique mérite une vérification de son activité avant d'être retenu ;
• le code natif d'appoint (canaux, extensions), qui demande malgré tout des notions de Swift et de Kotlin ;
• les montées de version de Flutter, à suivre en plus de celles des outils d'Apple et de Google.

Les deux approches vieillissent. La version actuelle de Flutter ne prend plus en charge iOS 14 et les versions antérieures, ni Android en dessous du niveau d'API 24 : si votre parc compte des téléphones anciens, vérifiez ces seuils avant de choisir. Le budget dépend surtout du périmètre fonctionnel, et le baromètre des prix 2026 donne les ordres de grandeur du marché.

Le cas mixte : Flutter et code natif dans la même application

Flutter et le natif peuvent cohabiter dans la même application, dans les deux sens.

• Une application Flutter avec des modules natifs : l'essentiel des écrans en Flutter, et quelques modules en Swift ou en Kotlin derrière des canaux de plateforme, pour un SDK ou une fonction pointue.
• Une application native avec des écrans Flutter : la fonction add-to-app intègre un module Flutter dans une application Android ou iOS existante, pour un parcours ou un écran, le reste conservant sa technologie d'origine. La documentation précise qu'une application mobile ne peut embarquer qu'une seule bibliothèque Flutter, et recommande d'initialiser le moteur à l'avance, son démarrage prenant un court instant.

Ce second schéma intéresse une entreprise qui possède déjà une application native et veut développer les nouvelles fonctions une seule fois, sans tout réécrire. La page moderniser un logiciel ancien sans tout casser applique la même logique de remplacement progressif.

Notre verdict selon votre situation

Quand ni Flutter ni le natif ne conviennent

Si l'outil sert surtout au bureau, si ses utilisateurs sont des clients occasionnels ou si le besoin n'exige ni hors connexion ni matériel, une application mobile n'est peut-être pas nécessaire. Une application web, éventuellement installable sur l'écran d'accueil, se diffuse par un lien et se met à jour sans passer par les stores : le comparatif PWA ou application native détaille ce qu'elle permet sur iPhone. Et si une application du marché couvre déjà le besoin, la redévelopper, en Flutter comme en natif, n'a pas de sens.

Deux projets, deux choix chez YMHB Web

Pour la marketplace Cospo Line, YMHB Web a retenu Flutter : une application mobile Flutter (recherche, réservation, messagerie, abonnements, notifications push) et un site Next.js à parité de fonctions, sur une base Supabase commune.

Le robot de livraison de Sakura France Service a suivi le chemin inverse. Son application embarquée est une application Android construite sur le SDK RobotOS du constructeur OrionStar : elle est écrite en Kotlin avec Jetpack Compose, et le tableau de bord que le robot sert lui-même sur le réseau du cabinet est en React. Une base multiplateforme n'aurait rien apporté à un appareil unique. Comme sur tous ses projets, YMHB Web dépose le code chez le client, documenté et écrit en technologies standard ; il lui appartient au paiement intégral.