Pendant des années, Xamarin a permis à de nombreuses entreprises de développer leurs applications iOS et Android en C#, en capitalisant sur leurs compétences .NET. Mais Microsoft a mis fin au support de Xamarin le 1er mai 2024, au profit de .NET MAUI. Depuis, les applications Xamarin ne reçoivent plus de correctifs, et s’éloignent chaque mois un peu plus des exigences d’Apple et de Google. Beaucoup d’entreprises se retrouvent avec une application métier ou grand public qui fonctionne encore, mais qu’il devient de plus en plus difficile, voire impossible, de mettre à jour. Chez Aventique, nous connaissons bien ce type de transition : nous avons nous-mêmes développé des applications avec des frameworks multiplateformes de génération précédente, comme Appcelerator Titanium pour BYMOV, Push2Bank ou Le Moniteur des Pharmacies, et nous maîtrisons à la fois l’écosystème .NET et Flutter. Voici comment aborder la migration de votre application Xamarin.

Pourquoi migrer maintenant ?

Une application Xamarin ne s’arrête pas de fonctionner du jour au lendemain. C’est précisément ce qui rend la situation trompeuse. Les risques s’accumulent pourtant.

• Plus de correctifs de sécurité : les vulnérabilités découvertes dans le framework ou ses dépendances ne sont plus corrigées.
• Des exigences des stores impossibles à satisfaire : Apple impose de compiler avec des versions récentes de Xcode et du SDK iOS, Google relève chaque année le niveau d’API Android cible exigé pour publier une mise à jour. Xamarin ne suit plus ces évolutions. À terme, vous ne pourrez plus publier la moindre correction, même urgente.
• Des bibliothèques tierces abandonnées : les éditeurs de SDK (paiement, cartographie, analytics) cessent progressivement de maintenir leurs versions Xamarin.
• Des compétences de plus en plus rares : recruter ou mobiliser des développeurs Xamarin devient difficile, et peu souhaitent investir dans une technologie en fin de vie.
• Un coût qui croît avec l’attente : plus la migration est repoussée, plus l’écart à combler est important, et plus elle risque d’être menée dans l’urgence, après un blocage de publication.

Les options de migration

Il n’existe pas de cible universelle. Le bon choix dépend de votre application, de vos équipes et de votre feuille de route.

.NET MAUI : la continuité .NET

.NET MAUI est le successeur officiel de Xamarin.Forms. Il permet de conserver le langage C#, une grande partie de la logique métier, les compétences de vos équipes et votre écosystème .NET. Microsoft fournit des outils d’aide à la migration, et les projets Xamarin.Android et Xamarin.iOS peuvent évoluer vers .NET pour Android et .NET pour iOS.

Attention toutefois : la migration vers MAUI n’est pas une simple montée de version. La structure des projets change, les renderers personnalisés doivent être réécrits en handlers, et de nombreuses bibliothèques tierces doivent être remplacées. C’est l’option la plus naturelle si vos équipes sont .NET, que votre application s’intègre fortement à un système d’information Microsoft et que son interface reste relativement classique. Notre agence .NET intervient sur ces migrations et sur les backends associés ; nous avons par exemple conçu l’application PBMS de Novo Nordisk sur le framework .NET.

Flutter : la modernisation de l’interface

Flutter, développé par Google, est aujourd’hui l’un des frameworks multiplateformes les plus utilisés. Il impose de réécrire l’application en Dart, mais apporte en contrepartie un rendu identique et très fluide sur iOS et Android, un écosystème de bibliothèques très actif, un excellent outillage et un vivier de développeurs en forte croissance. C’est souvent notre recommandation lorsque l’interface doit être modernisée en profondeur, que l’application est orientée grand public ou que les équipes ne sont pas attachées à .NET.

React Native : l’option JavaScript

React Native est pertinent lorsque l’entreprise dispose déjà de compétences React et TypeScript côté web, ce qui permet de mutualiser les équipes et une partie du code. Nous l’utilisons sur de nombreux projets, notamment chez Clariane où nos développeurs interviennent sur React, React Native et NestJS.

Le natif ou Kotlin Multiplatform

Pour une application qui exploite intensivement les capacités du terminal, le passage au natif Swift et Kotlin reste une option. Kotlin Multiplatform permet de mutualiser la logique métier tout en gardant des interfaces natives, une approche que nous analysons dans notre article sur Kotlin Multiplatform.

Comment choisir : les critères qui comptent

Pour arbitrer, nous évaluons avec nos clients cinq critères.

• Les compétences internes : une équipe .NET qui maintiendra l’application penchera vers MAUI ; une équipe web vers React Native ; une équipe à constituer peut choisir librement.
• La part de logique métier réutilisable : si l’essentiel de la valeur réside dans du code C# partagé, MAUI permet de le conserver ; si la logique est surtout côté serveur, le choix du framework mobile est plus ouvert.
• Les ambitions d’expérience utilisateur : une refonte de l’interface est souvent prévue de toute façon ; dans ce cas, réécrire en Flutter ne coûte pas beaucoup plus cher et offre un meilleur résultat.
• L’écosystème de bibliothèques : paiement, cartographie, scan, authentification. Il faut vérifier la disponibilité et la maturité des équivalents dans chaque framework.
• La pérennité : cycles de support, dynamique de la communauté, disponibilité des profils sur le marché.

Notre méthode de migration

1. Audit de l’application existante

Nous commençons par un inventaire complet : fonctionnalités réellement utilisées, bibliothèques et SDK tiers, code natif spécifique, intégrations avec le backend, état des tests, conformité aux stores. Cet audit d’application mobile permet de chiffrer précisément chaque scénario.

2. Choix de la cible et plan de migration

Sur la base de l’audit, nous recommandons une cible et une stratégie : migration par écrans, réécriture complète avec gel fonctionnel partiel de l’ancienne version, ou approche hybride. C’est aussi le moment de supprimer les fonctionnalités inutilisées et de corriger les défauts d’ergonomie connus.

3. Préparation du backend

Une migration mobile réussie s’appuie sur des API stables et documentées. Si la logique métier est trop dispersée dans l’application Xamarin, nous recommandons parfois d’en déplacer une partie côté serveur, ce qui simplifie la nouvelle application et facilite les évolutions futures. Notre article sur la migration d’une application legacy détaille ces approches progressives.

4. Développement et tests

Développement en sprints avec démonstrations régulières, tests automatisés sur les parcours critiques, tests de non-régression par comparaison avec l’application existante, recette par vos utilisateurs clés.

5. Bascule sans perte

La nouvelle version est publiée comme une mise à jour de l’application existante, avec le même identifiant et la même clé de signature, afin de conserver les utilisateurs, les notes et les avis. Nous prévoyons la migration des données locales et des sessions, et un déploiement progressif sur les stores. Pour une application interne, la bascule se coordonne avec votre solution de gestion de flotte.

Les pièges à éviter pendant la migration

Les migrations de frameworks échouent rarement pour des raisons techniques pures. Elles dérapent surtout pour des raisons d’organisation. Voici les pièges que nous vous aidons à éviter.

• Migrer à l’identique sans réfléchir : reproduire fidèlement des écrans conçus il y a dix ans revient à payer une réécriture sans bénéficier de ses avantages. C’est le moment de simplifier les parcours et de supprimer ce qui ne sert plus.
• Ajouter trop de nouveautés en même temps : à l’inverse, profiter de la migration pour lancer une longue liste de nouvelles fonctionnalités allonge le projet et augmente le risque. Mieux vaut migrer, stabiliser, puis enrichir.
• Sous-estimer les dépendances natives : SDK de paiement, lecture de codes-barres, cartographie, notifications, authentification d’entreprise. Chaque brique doit avoir un équivalent validé dans la technologie cible avant de lancer le développement.
• Négliger les tests de non-régression : l’ancienne application sert de référence. Comparer systématiquement les comportements évite les mauvaises surprises lors de la bascule.
• Oublier les utilisateurs : données locales, sessions, préférences, formation des utilisateurs internes pour les applications métiers. Une bascule mal préparée génère des appels au support et une mauvaise image de la nouvelle version.
• Attendre le blocage des stores : migrer sous la contrainte d’une mise à jour urgente impossible à publier est la pire des situations. Anticiper permet de choisir son calendrier.

Combien coûte une migration Xamarin ?

Le coût dépend de la cible et de l’application. Une migration vers .NET MAUI d’une application aux interfaces standards, avec une forte réutilisation de la logique C#, représente généralement une fraction du coût initial. Une réécriture en Flutter ou React Native se rapproche du coût d’une nouvelle application, mais bénéficie d’un périmètre connu et rationalisé, et inclut souvent une modernisation de l’interface. Dans tous les cas, l’audit initial permet de comparer les scénarios sur une base chiffrée. Les délais vont généralement de deux à six mois selon la taille de l’application.

Si votre application repose encore sur Xamarin, le plus tôt est le mieux. Notre agence de développement d’applications mobiles peut auditer votre application et vous proposer le scénario de migration le plus adapté.

FAQ sur la migration d’une application Xamarin

Mon application Xamarin va-t-elle cesser de fonctionner ?

Pas immédiatement : elle continue de fonctionner sur les appareils des utilisateurs. Mais elle ne reçoit plus de correctifs, et vous ne pourrez bientôt plus publier de mise à jour conforme aux exigences d’Apple et de Google.

La migration vers .NET MAUI est-elle automatique ?

Non. Des outils facilitent la conversion des projets, mais les renderers personnalisés, de nombreuses bibliothèques et certaines parties de l’interface doivent être réécrits et testés.

Vaut-il mieux migrer vers MAUI ou vers Flutter ?

MAUI est pertinent si vos équipes sont .NET et que vous voulez conserver votre code C#. Flutter est souvent plus intéressant si vous souhaitez moderniser l’interface et disposer d’un écosystème très actif. L’audit initial permet de trancher.

Peut-on conserver le backend existant ?

Oui, dans la grande majorité des cas. La migration concerne l’application mobile ; le backend peut rester en place, éventuellement complété par de nouvelles API.

Va-t-on perdre nos utilisateurs et nos avis sur les stores ?

Non, si la nouvelle version est publiée comme une mise à jour de l’application existante, avec le même identifiant et la même clé de signature.

Aventique a-t-elle déjà migré des applications multiplateformes anciennes ?

Nous avons développé des applications avec des frameworks multiplateformes de génération précédente, comme Appcelerator Titanium, et nous en connaissons les limites. Nous reprenons régulièrement des applications existantes pour les auditer, les restructurer ou les refondre, et nos équipes maîtrisent les cibles actuelles : Flutter, React Native, natif et écosystème .NET.