Développer une application pour iPhone et Android impose un choix technique structurant : écrire deux applications natives (Swift pour iOS, Kotlin pour Android) ou une seule base de code multiplateforme avec Flutter ou React Native. Il n’y a pas de bonne réponse universelle, mais il existe de bons critères. Voici comment choisir, sans dogme.
Les trois grandes approches
Le natif : Swift et Kotlin
Chaque plateforme a son langage et ses outils : Swift et SwiftUI pour iOS, Kotlin et Jetpack Compose pour Android. Le natif donne un accès immédiat et complet à toutes les fonctions du système, les meilleures performances possibles et une intégration parfaite aux conventions de chaque plateforme. En contrepartie, il faut développer et maintenir deux applications, donc deux fois plus de code pour les mêmes fonctions.
Flutter
Créé par Google, Flutter utilise le langage Dart et dessine lui-même l’interface grâce à son propre moteur de rendu. Une seule base de code produit les applications iOS et Android (et, si besoin, web et bureau). Atouts : une interface identique au pixel près sur toutes les plateformes, des animations fluides, une productivité élevée. Limites : un langage moins répandu que JavaScript, et une apparence qui ne reprend pas automatiquement les composants natifs de chaque système (ce qui est souvent un avantage pour une marque forte).
React Native
Porté par Meta, React Native utilise JavaScript ou TypeScript et la logique de React, la bibliothèque web la plus utilisée. L’interface s’appuie sur les composants natifs de chaque plateforme. Atouts : un immense écosystème, la possibilité de partager du code et des compétences avec une application web en React, une apparence native. Limites : des performances parfois plus délicates sur les interfaces très animées, et une dépendance plus forte aux bibliothèques tierces pour certaines fonctions.
Le comparatif
| Critère | Natif (Swift / Kotlin) | Flutter | React Native |
|---|---|---|---|
| Bases de code | Deux | Une | Une |
| Langage | Swift, Kotlin | Dart | JavaScript / TypeScript |
| Performances | Maximales | Très bonnes | Bonnes à très bonnes |
| Rendu de l’interface | Composants natifs | Moteur propre, identique partout | Composants natifs |
| Accès aux fonctions du téléphone | Complet, immédiat | Très large, via plugins | Très large, via modules |
| Partage avec le web | Faible | Possible (Flutter web) | Fort (avec React) |
| Coût de maintenance | Plus élevé | Contenu | Contenu |
Les critères qui doivent guider votre choix
1. La nature de l’application
Une application métier (saisie, consultation, formulaires, photos, signature, synchronisation) est le terrain idéal du multiplateforme : l’essentiel du travail est commun aux deux systèmes. Une application qui exploite intensivement le matériel (traitement vidéo en temps réel, réalité augmentée avancée, intégration poussée avec une montre ou un objet connecté) peut justifier le natif.
2. L’existant
Vous avez déjà une application web en React ? React Native permet de partager des compétences, voire une partie de la logique. Vous partez de zéro avec une identité visuelle forte ? Flutter garantit un rendu identique partout. Vous maintenez déjà deux applications natives de qualité ? Les réécrire n’a de sens que si leur maintenance devient un frein.
3. Le budget et le délai
Une base de code unique réduit nettement le temps de développement et de maintenance par rapport à deux applications natives. C’est souvent l’argument décisif pour une première version, puis pour la durée de vie de l’application.
4. Le fonctionnement hors connexion
Beaucoup d’applications métier doivent fonctionner sans réseau (sur un chantier, en déplacement, dans un bâtiment mal couvert) puis synchroniser les données au retour. Les trois approches le permettent, mais cela se conçoit dès l’architecture : base locale, gestion des conflits, reprise des envois.
5. La pérennité et les compétences
Flutter et React Native sont soutenus par de très grandes entreprises et utilisés par de nombreuses applications en production. Le critère le plus concret reste la disponibilité de compétences pour maintenir l’application dans la durée : privilégiez une technologie que votre prestataire maîtrise réellement et pour laquelle vous trouverez d’autres développeurs si besoin.
Et l’application web progressive (PWA) ?
Une PWA est un site web qui se comporte comme une application : installable sur l’écran d’accueil, utilisable hors connexion dans une certaine mesure, sans passer par les stores. Elle convient bien à un outil interne simple ou à un usage ponctuel. Ses limites : un accès plus restreint aux fonctions du téléphone, en particulier sur iPhone, et l’absence de présence dans les stores. Pour un outil de gestion utilisé au bureau et sur le terrain, une application web responsive peut aussi être la meilleure première étape.
Au-delà de la technologie : ce qui fait une bonne application
Le choix du framework ne représente qu’une partie de la réussite. Comptent tout autant :
- le parcours utilisateur, conçu et testé avec les vraies personnes qui utiliseront l’application ;
- le back-end : la base de données, l’authentification, les API et les droits d’accès, souvent plus complexes que l’application elle-même ;
- la sécurité : stockage chiffré des données sensibles sur le téléphone, échanges protégés, sessions maîtrisées ;
- la publication : comptes développeur Apple et Google, règles de validation des stores, fiches de présentation, politique de confidentialité ;
- la maintenance : chaque nouvelle version d’iOS et d’Android impose des mises à jour, à prévoir dès le départ.
Et Kotlin Multiplatform ?
Une quatrième voie gagne du terrain : Kotlin Multiplatform, qui partage la logique métier (calculs, règles, accès aux données) entre iOS et Android tout en conservant une interface native sur chaque plateforme, ou en la partageant elle aussi avec Compose Multiplatform. Elle intéresse surtout les équipes déjà expertes en Kotlin, ou les applications natives existantes qui veulent réduire la duplication sans tout réécrire. Pour un nouveau projet sans existant, Flutter et React Native restent généralement plus simples à mettre en œuvre.
Notre position
Pour la majorité des applications métier et des applications grand public, nous recommandons Flutter : une seule base de code, une interface soignée et identique partout, d’excellentes performances. Nous retenons React Native quand une forte synergie avec une application web React existe, et le natif quand l’usage du matériel l’exige. Le choix se fait toujours après avoir compris l’usage, jamais avant. C’est la démarche que nous suivons pour le développement d’applications mobiles.
Questions fréquentes
Une application Flutter est-elle moins performante qu’une application native ?
Pour la grande majorité des usages, la différence n’est pas perceptible. Elle ne devient sensible que pour des traitements très intensifs, où le natif garde l’avantage.
Peut-on passer de React Native à Flutter, ou l’inverse, plus tard ?
C’est possible mais cela revient à réécrire l’interface. Le back-end, lui, est réutilisé tel quel s’il a été conçu de manière indépendante, ce que nous recommandons toujours.
Faut-il publier l’application sur les deux stores ?
Pas obligatoirement : une application interne peut être distribuée par des canaux réservés aux entreprises. Mais pour une application destinée au public, la présence sur l’App Store et Google Play est la règle.
Combien de temps faut-il pour développer une application mobile ?
Cela dépend du périmètre. Une première version ciblée sur les fonctions essentielles se compte généralement en semaines plutôt qu’en mois, puis l’application s’enrichit par versions successives.
Le studio Step By Step, à Ajaccio, conçoit et développe des applications iPhone et Android. Présentez-nous votre projet.