Vous avez un projet d’application mobile et vous devez être présent à la fois sur iPhone et sur Android. Très vite, une question technique se pose : faut-il développer deux applications natives, une application multiplateforme avec un code partagé, ou une application web progressive (PWA) ? Chaque approche a ses forces. Aucune n’est universellement meilleure : tout dépend de vos fonctionnalités, de votre budget et de vos ambitions à moyen terme.
Le développement natif : performance et intégration maximales
Une application native est développée avec les langages et outils officiels de chaque plateforme :
- iOS : Swift et SwiftUI, avec Xcode, l’environnement d’Apple ;
- Android : Kotlin et Jetpack Compose, avec Android Studio, l’environnement de Google.
Ses atouts sont connus : une fluidité optimale, un accès immédiat et complet aux fonctionnalités du système, une interface parfaitement conforme aux conventions de chaque plateforme, et la possibilité d’adopter les nouveautés d’iOS et d’Android dès leur sortie.
La contrepartie est tout aussi claire : il faut maintenir deux bases de code distinctes, souvent avec des compétences différentes. Le coût de développement et de maintenance est donc plus élevé, et chaque évolution doit être réalisée deux fois.
Le multiplateforme : un code partagé pour iOS et Android
Les frameworks multiplateformes permettent d’écrire une grande partie de l’application une seule fois, puis de la déployer sur les deux systèmes. Trois solutions dominent aujourd’hui.
Flutter
Soutenu par Google et basé sur le langage Dart, Flutter dessine lui-même son interface. Le rendu est identique sur iOS et Android, ce qui facilite les designs très personnalisés. Les performances sont généralement excellentes pour la grande majorité des applications.
React Native
Soutenu par Meta, React Native s’appuie sur JavaScript ou TypeScript et sur des composants d’interface natifs. Il est particulièrement pertinent si votre équipe ou votre prestataire maîtrise déjà l’écosystème React utilisé pour le web.
Kotlin Multiplatform
Porté par JetBrains, Kotlin Multiplatform adopte une approche plus progressive : partager la logique métier (accès aux données, règles de gestion, synchronisation) tout en conservant, si on le souhaite, des interfaces natives. Il est aussi possible de partager l’interface avec Compose Multiplatform. C’est une option intéressante pour qui veut un compromis entre mutualisation et rendu natif.
Dans tous les cas, le multiplateforme permet généralement de réduire le coût et le délai par rapport à deux développements natifs, sans pour autant les diviser par deux : une partie du travail reste spécifique à chaque plateforme (tests, publication sur les stores, adaptations d’interface, modules natifs).
La PWA : une application web installable
Une application web progressive est un site web conçu pour se comporter comme une application : installable sur l’écran d’accueil, utilisable en partie hors ligne, capable dans certains cas d’envoyer des notifications. Elle ne passe pas par l’App Store ni par Google Play, ce qui simplifie la diffusion et les mises à jour.
Ses limites sont réelles, en particulier sur iPhone : accès restreint à certaines fonctionnalités du téléphone, notifications soumises à l’ajout préalable de l’application à l’écran d’accueil, absence de visibilité dans les stores. La PWA convient bien aux outils internes, aux services ponctuels ou à une première version destinée à valider un concept. Elle peut aussi compléter un site web existant.
Tableau comparatif
| Critère | Natif | Multiplateforme | PWA |
|---|---|---|---|
| Performances | Optimales | Très bonnes dans la plupart des cas | Correctes, dépendantes du navigateur |
| Coût initial | Le plus élevé (deux applications) | Intermédiaire | Le plus faible |
| Maintenance | Deux bases de code | Une base principale, plus des parties natives | Une seule base web |
| Accès aux fonctions du système | Complet et immédiat | Large, via des modules natifs si nécessaire | Limité, surtout sur iOS |
| Présence dans les stores | Oui | Oui | Non (sauf cas particuliers) |
| Adoption des nouveautés iOS et Android | Dès leur sortie | Parfois avec un délai | Selon le support des navigateurs |
Les fonctionnalités qui font pencher vers le natif
Certaines fonctionnalités reposent sur des technologies propres à chaque système. Elles restent souvent réalisables dans un projet multiplateforme, mais elles imposent alors d’écrire du code natif en complément, ce qui réduit l’intérêt du code partagé. Si votre projet en comporte plusieurs, le natif devient un candidat sérieux :
- Widgets sur l’écran d’accueil ou l’écran verrouillé : sur iOS, ils sont développés en SwiftUI avec WidgetKit, quel que soit le framework de l’application principale.
- Apple Watch et montres connectées : une application watchOS est développée nativement, tout comme l’essentiel des expériences sur Wear OS.
- Siri, Raccourcis et assistants vocaux : l’intégration passe par des API système spécifiques, comme App Intents sur iOS.
- Fonctionnement hors ligne avancé : synchronisation complexe, gestion fine des conflits, stockage local volumineux.
- Usage intensif du matériel : caméra avec traitement en temps réel, réalité augmentée, Bluetooth, capteurs, géolocalisation en arrière-plan.
- Activités en direct et notifications riches, très ancrées dans l’expérience de chaque système.
Astuce : listez dès le départ les fonctionnalités envisagées pour les deux ou trois prochaines années, pas seulement celles de la première version. Un widget ou une application Apple Watch ajoutés plus tard peuvent remettre en cause un choix technique fait trop rapidement.
Les critères pour faire le bon choix
Pour trancher, posez-vous les questions suivantes :
- Quelles fonctionnalités sont indispensables ? Plus elles sont liées au système (widgets, montre, capteurs), plus le natif se justifie.
- Quel est votre budget global, maintenance comprise ? Raisonnez sur plusieurs années, pas uniquement sur le développement initial.
- Quel délai de mise sur le marché ? Pour valider rapidement un concept, une PWA ou une application multiplateforme est souvent plus adaptée.
- Quelle exigence d’expérience utilisateur ? Une application grand public utilisée quotidiennement n’a pas les mêmes contraintes qu’un outil interne.
- Qui assurera la maintenance ? Le choix doit tenir compte des compétences disponibles, en interne comme chez votre prestataire.
- Quelle part de votre public est sur iOS et sur Android ? Si l’une des plateformes domine nettement, un développement natif ciblé peut être pertinent dans un premier temps.
Et pourquoi pas une approche progressive ?
Le choix n’est pas toujours définitif ni exclusif. Plusieurs trajectoires sont possibles : lancer une PWA pour valider l’intérêt des utilisateurs, puis développer une application publiée sur les stores ; construire une application multiplateforme enrichie de modules natifs pour les fonctionnalités les plus exigeantes ; ou encore partager uniquement la logique métier avec Kotlin Multiplatform en conservant des interfaces natives. L’essentiel est d’anticiper ces évolutions dès la conception, notamment en séparant clairement l’application mobile de l’API et du back-office, afin de pouvoir faire évoluer l’une sans tout reconstruire.
Le bon choix technique n’est pas celui qui coûte le moins au lancement, mais celui qui servira encore votre projet dans trois ans.
Les erreurs à éviter
- Choisir une technologie par effet de mode plutôt qu’en fonction de vos besoins réels.
- Sous-estimer la maintenance : chaque nouvelle version d’iOS et d’Android peut nécessiter des ajustements, quelle que soit l’approche.
- Oublier le back-office : la plupart des applications reposent sur une API, une base de données et une interface d’administration, qui représentent une part importante du projet.
- Négliger les règles des stores : les exigences de publication d’Apple et de Google doivent être anticipées dès la conception.
- Démarrer sans cahier des charges : formaliser vos besoins reste la meilleure façon de comparer des devis. Notre guide pour rédiger un cahier des charges digital peut vous y aider.
En résumé
Le natif (Swift et SwiftUI, Kotlin et Jetpack Compose) offre les meilleures performances et un accès complet au système, au prix d’un budget plus élevé. Le multiplateforme (Flutter, React Native, Kotlin Multiplatform) constitue un excellent compromis pour la majorité des projets. La PWA convient aux besoins plus simples ou aux premières versions. Le bon choix découle de vos fonctionnalités, de votre budget sur la durée et de vos ambitions.
Concepteur d’applications iOS et Android, comme l’application Plouf Check ou la plateforme et l’application Weclap, Web Solutis vous aide à arbitrer entre ces approches avant d’engager le moindre développement. Découvrez notre offre de développement d’applications web et mobiles ou contactez-nous pour en parler.
