Cross-platform natif : illusion technologique ou futur du développement mobile ?

Kotlin Multiplatform, Skip, Swift-on-Android… Entre le développement des technologies cross-platform classiques comme Flutter ou React Native depuis quelques années et la résistance des solutions natives pures, une troisième voie semble s’ouvrir, le “cross-platform natif”. Avec une promesse ambitieuse : être véritablement multiplateforme tout en adoptant une vision résolument native-first. Mais est-ce seulement possible ?

Du cross-platform au cross-platform… natif ?

Ces dernières années, le développement mobile cross-platform a radicalement transformé le paysage du développement mobile. Après une longue période de maturation, et des briques techniques plus ou moins efficaces ou adoptées, le marché semble avoir couronné Flutter et React Native comme leaders incontestés de la catégorie (comme le montrent les chiffres issus de nos différents App Observers). Productivité réelle grâce à une exécution rapide, performances proches du natif (à quelques exceptions près), écosystèmes riches de milliers de packages, possibilité pour les développeurs web de contribuer aux enjeux mobiles et surtout cohérence naturelle entre plateformes avec une seule base de code à maintenir… Il y a en effet de nombreuses raisons qui expliquent que ces deux technologies se soient aussi solidement implantées dans le paysage. Aujourd’hui, des millions d'utilisateurs utilisent quotidiennement des applications construites avec des solutions cross-platform, sans même s’en rendre compte, preuve de leur efficacité.

En 2021-2022, la technologie de développement Kotlin Multiplatform (KMP) commence à se faire un nom sur le marché et pose les bases d’une philosophie très différente : mutualiser le code métier tout en gardant l'UI 100% native sur chaque plateforme : SwiftUI sur iOS, Jetpack Compose sur Android. Un compromis intelligent qui maximise la qualité de l'expérience utilisateur tout en évitant la duplication du code complexe et qu’aujourd’hui, de grosses entreprises comme Netflix ont adopté en production, démontrant que l'écosystème est arrivé à maturité.

KMP porte donc une vision “native-first” du cross-platform, que l’on aime à qualifier chez USERADGENTS de “cross-platform natif”, mais il semble toutefois plus se plier aux exigences et aux enjeux des développeurs Android que des développeurs iOS, complexifiant la tâche pour ces derniers sur certains usages. Il aura fallu attendre 2025 pour que le "cross-platform natif" s'enrichisse et rétablisse l’équilibre grâce aux déploiements de solutions plutôt iOS-first, à l’image du SDK Swift-on-Android.

Mais peut-on réellement accorder du crédit à cet oxymore de “cross-platform natif” ? Peut-on vraiment être à la fois cross-platform et natif ? Les solutions cross-platform natives peuvent-elles constituer une alternative intéressante pour les organisations qui n’arrivent pas à se positionner entre natif pur et mutualisation complète ? Quels sont les enjeux et les difficultés de cette nouvelle approche ? Voici les questions que Cyrille Legrand, Lead Développeur iOS chez USERADGENTS s’est posé pour vous, avec le recul et l’expérience de ses (presque) 20 ans de développement natif sur les technologies d’Apple, en décortiquant de bout en bout ce nouveau panel de solutions.

Les bénéfices d’une logique native-first

Avant de plonger dans les technologies, rappelons pourquoi il est intéressant de penser "native-first" dans le développement d'apps mobiles, même quand on fait du Flutter ou React Native.

Respect des conventions UX

iOS et Android ne sont pas les mêmes systèmes. iOS privilégie la cohérence, la prédictibilité, le contrôle centralisé. Android privilégie la flexibilité, la personnalisation, la diversité. Ces différences reflètent des philosophies variées et des publics avec des attentes différentes. Respecter ces conventions (tab bar vs bottom navigation, modal sheets vs activities, swipe-back vs bouton retour système…) n'est pas un détail, c'est ce qui fait qu'une app se sent "chez elle" sur chaque plateforme. Les utilisateurs iOS et Android ont internalisé ces patterns. Les ignorer crée une réelle friction cognitive.

Performance

Une app native tire parti des optimisations du compilateur de chaque plateforme. Le code Swift sur iOS bénéficie de l'ARC (Automatic Reference Counting), des value types optimisés, de la compilation anticipée. Le code Kotlin sur Android s'intègre parfaitement à l'environnement Java/JVM et possède ses propres optimisations. Les frameworks cross-platform classiques (React Native et Flutter) ajoutent une couche d'abstraction (un moteur de rendu custom, une VM intermédiaire) qui induisent inévitablement une consommation accrue de ressources. Ce n'est pas toujours notable, mais pour des apps exigeantes (jeux, traitement d'image, animations complexes…), cela peut faire une grande différence.

Intégration aux écosystèmes

Accès immédiat aux nouvelles API, support natif des widgets système, intégration avec Siri et Google Assistant, utilisation des retours haptiques sur iOS, des Material Components sur Android… Toutes ces fonctionnalités font qu'une app ne se contente pas d'exister sur une plateforme, mais y appartient. Le cross-platform traditionnel va suivre ces évolutions avec un temps de latence quand le cross-platform natif, lui, y a accès par construction.

Kotlin Multiplatform et Compose Multiplatform : les prémices du cross-platform natif

KMP repose sur une idée simple : le code Kotlin peut cibler plusieurs plateformes (JVM, iOS via Kotlin/Native, JavaScript, etc.). Vous écrivez votre logique métier une fois en Kotlin, et elle compile nativement pour chaque cible. Pour l'UI, deux approches coexistent :

• Une UI séparée : SwiftUI sur iOS, Compose sur Android (l'approche recommandée).
• Une UI gérée par Compose Multiplatform : un sous-ensemble de Jetpack Compose qui tourne aussi sur iOS.

KMP/CMP bénéficient du support officiel de Google, L'interopérabilité avec les API natives est réelle et leur adoption prouvée en production. Mais pour un développeur iOS comme Cyrille, KMP pose un problème fondamental : tout est une class en Kotlin, il n'y a pas de véritable équivalent aux struct de Swift. Si on parle un peu technique : le moindre objet nécessite une mécanique d'allocation de la mémoire "à la Java" : allocation sur le tas (heap) et nettoyage au ramasse-miettes (garbage-collector). C'est plus lourd que ce qui est possible en Swift, où les struct sont allouées directement sur la pile (stack) quand c'est possible, avec copy-on-write (la mémoire n'est jamais dupliquée sauf en cas de modification). C'est plus performant et conceptuellement plus propre. Pour du code qui manipule beaucoup de données (notamment le parsing de JSON volumineux), cette surconsommation mémoire et CPU n'est pas négligeable.

Surtout, utiliser KMP, c'est devoir coder "Android-first". Les idiomes Kotlin, les patterns Android, la structure du code, tout reflète la culture Android. En tant que développeur iOS, vous êtes en territoire étranger et vous devez donc vous plier aux conventions d'un autre écosystème et vous forcer à ne pas utiliser les fonctionnalités si agréablement surpuissantes de votre langage favori… Même avec une UI SwiftUI séparée, les apps KMP sous iOS ont souvent un léger "goût Android" car la logique métier partagée influence subtilement l'architecture de l'UI. Les patterns de state management, la façon dont les données circulent, la structure des ViewModels… Tout ça porte la marque de Kotlin et d'Android. Ce n'est pas rédhibitoire, mais ça demande une vigilance constante des développeurs iOS pour ne pas se laisser influencer par ces patterns étrangers.

Skip et Swift-on-Android, pour remettre la balle au centre)

Heureusement pour les développeurs iOS, des outils comme Skip, et plus récemment, le SDK Android officiel pour Swift, tentent de renverser la tendance.

Qui sont-ils ?

Skip est un framework créé par une équipe indépendante qui permet d'écrire des apps en Swift et SwiftUI, et de les faire tourner nativement sur iOS et Android. Historiquement, Skip fonctionnait par “transpilation” : votre code Swift était automatiquement converti en Kotlin, et votre SwiftUI en Jetpack Compose. Cette approche utilisait SwiftSyntax (la même librairie qu'exploitent les macros Swift) pour parser le code source Swift en un arbre syntaxique détaillé, puis le traduire en Kotlin équivalent. C'était, et c'est toujours, impressionnant. Le code généré est lisible, humain, et préserve même vos commentaires et votre formatage. Pour l'UI, SkipUI transpile vos vues SwiftUI en composants Jetpack Compose équivalents, donnant aux utilisateurs Android une vraie interface native.

Fin 2025, l’équipe de swift.org a annoncé officiellement un SDK Android pour Swift, fruit d'années de travail communautaire auquel Skip a contribué. Concrètement, cela signifie que vous pouvez maintenant compiler du code Swift nativement pour Android, sans transpilation. Votre code Swift s'exécute directement sur Android avec toutes ses caractéristiques : value types (structs, enums), ARC, optimisations du compilateur Swift. Skip a immédiatement intégré ce support. Aujourd'hui, avec Skip 1.5, vous avez le choix entre deux modes : Skip Lite : mode transpilation (Swift ? Kotlin) / Skip Fuse : mode natif (Swift compilé + bridging Kotlin/Swift). 

Dans Skip Fuse, votre logique métier est en Swift natif compilé, et l'UI est transpilée en Compose. Le bridging entre les deux est géré automatiquement par Skip. C'est le meilleur des deux mondes : vous gardez vos value types Swift pour la performance et la sécurité, tout en générant une UI Compose native pour Android. 

Les différences fondamentales avec KMP

Avec Swift-on-Android via Skip, vous pensez cette fois Swift-first. Vous gardez :

• Vos struct et enum avec la performance des allocations sur la stack ;
• L'ARC déterministe (en comparaison du Garbage Collector de la JVM sur laquelle tourne Kotlin) ;
• Vos protocols, extensions, property wrappers ;
• Votre façon de structurer le code.

Vous n'avez pas à apprendre un nouveau modèle mental. Vous écrivez du Swift idiomatique, et ça tourne sur Android. C'est l'inverse exact de KMP. Au lieu de penser Android-first et adapter à iOS, vous pensez Swift-first et adaptez à Android. Un vrai argument pour séduire les vétérans d’iOS.

Pas encore exploitable à 100%, mais prometteur

Soyons honnêtes : Skip Fuse est actuellement une technology preview. L'équipe Skip travaille sur le compilateur, la documentation, les bugs, l'optimisation des temps de build, la réduction de la taille des binaires Android. Tous les composants SwiftUI ne sont pas supportés. Il faut parfois écrire du code spécifique Android dans des blocs #if SKIP. L'interopérabilité Swift-Java n'est pas toujours naturelle. Mais les fondations sont là. Près de 2000 packages Swift du Swift Package Index compilent déjà pour Android. On ne doute pas que très vite, des apps complètes puissent tourner en production avec cette stack.

L'attention à l'UX Android reste cruciale

Une mise en garde essentielle toutefois : Swift-on-Android ne vous dispense pas de comprendre Android. Vous pouvez écrire votre logique en Swift, mais vous devez toujours maîtriser le lifecycle des Activities, les permissions Android, le système de navigation, Material Design. Et surtout, attention à ne pas reproduire les écueils UX des autres solutions. Ce n'est pas parce que vous écrivez en Swift que votre app doit ressembler à une app iOS transplantée sur Android. Il faut respecter les conventions Android, utiliser les patterns Material, adapter la navigation. Skip et Swift-on-Android facilitent le partage de code, pas la conception paresseuse.

En conclusion

Le cross-platform natif va-t-il s'imposer face à Flutter et React Native ?

Le pronostic est prudent pour l'instant. Tout va dépendre des 2-3 prochaines années. Pour que le cross-platform natif (KMP/CMP ou Skip/Swift-on-Android) s'impose, il faudra :

• Un tooling mature et stable (intégration IDE, debugging efficace).
• Des success stories visibles et convaincantes.
• Une documentation riche et des exemples abondants.
• Une large communauté d’adoption favorisant les initiatives et avancées technologiques.

Ils resteront probablement minoritaires dans un premier temps, car ils ne simplifient pas vraiment le problème, ils l'abordent juste différemment. Ils nécessitent toujours de l'expertise sur les deux plateformes, et on ne devrait donc pas observer pas de réduction drastique des coûts à court terme. Surtout, Flutter et React Native ont déjà une avance et une inertie gigantesques grâce à la force de leurs écosystèmes, le nombre de développeurs formés et leur base déjà bien installée.

Le scénario probable est celui d’une coexistence intelligente où chaque solution trouvera son segment :

• Flutter/React Native pour des projets avec de fortes contraintes de temps et de budget, des équipes web-first, des prototypes rapides.
• KMP/CMP, Skip et Swift-on-Android pour des apps premium avec des équipes native-first, des grandes organisations.
• Natif pur pour des apps flagship, des expériences différenciantes, quand le budget le permet et que la qualité maximale est l’objectif.

L'expertise native reste toujours cruciale

Mais en définitive, quelle que soit la solution retenue pour une app cross-platform, une vérité demeure et fait partie de notre ADN chez USERADGENTS : l'expertise native est indispensable. En termes d’intégration UX. En termes de performance. En termes d'utilisation avancée des capacités des systèmes. 

Comme il est souvent (voire toujours) nécessaire de dépasser les limites du cross-platform en injectant une quantité plus ou moins importante de code natif pour créer un pont (bridge) entre les différentes plateformes, d’expérience, nous pouvons vous dire qu’il est capital que des développeurs natifs experts accompagnent les développeurs cross-platform. Car cette connaissance ne vient pas des frameworks directement, elle vit dans la tête des développeurs natifs qui pratiquent ces plateformes quotidiennement.

Pour KMP/CMP et Skip/Swift-on-Android, c’est logique. Leur nature même exige cette expertise. Impossible de tricher. Vous devez avoir de vrais experts iOS et Android qui travaillent ensemble, se challengent mutuellement et s'alignent sur l'architecture. C'est à la fois leur force (ils forcent l'organisation à valoriser les développeurs natifs) et leur faiblesse (ils ne réduisent pas la complexité organisationnelle, ils l'assument). 

Le cross-platform natif n'est en effet pas une révolution qui va tout balayer. C'est une évolution qui enrichit l'écosystème, offrant une nouvelle option pour ceux qui refusent de choisir entre vitesse et qualité irréprochable. Pour les équipes iOS-first, Swift-on-Android est une promesse excitante : garder leur langage, leurs patterns, leur culture technique, tout en touchant Android. Mais cette promesse ne se réalisera qu’en restant vigilants sur l'UX Android, en cultivant l'expertise des deux plateformes et en acceptant la complexité inhérente à faire du vrai cross-platform de qualité. C'est pour cela qu'une équipe iOS-first (ou Android-first) ne peut pas, seule, réaliser une application cross-platform de qualité, quelle que soit la solution choisie. 

Le mobile reste, et restera, un monde où l'excellence demande de l'expertise, de la rigueur, et du respect pour les spécificités de chaque plateforme. Les outils évoluent, mais cette vérité fondamentale, elle, ne change pas.

Vous avez besoin d’éclairage dans le choix de votre technologie de développement ? Contactez Cyrille ou un autre de nos experts.