SwiftUI, Flutter ou React Native en 2026 : que choisir pour une app iPhone ?

Pour créer une application iPhone en 2026, SwiftUI est le meilleur choix par défaut dès lors que l’iPhone est votre priorité : accès dès le premier jour aux frameworks d’Apple (HealthKit, WidgetKit, Live Activities, App Intents), compatibilité Apple Watch et Vision Pro, et adoption automatique de chaque nouveau design d’iOS. Flutter et React Native l’emportent quand vous devez sortir sur iOS et Android en même temps avec une seule équipe, pour une app faite surtout d’écrans, de formulaires et de contenus ; côté performances, aucun benchmark universel ne tranche, d’où le protocole de mesure proposé plus bas avec les outils d’Apple. Develak développe en Swift natif : ce comparatif est donc informé mais assumé comme partial, et reprend les arbitrages que nous exposons à nos clients avant qu’ils choisissent.

Points clés

• Produit réservé à l’iPhone ou pensé d’abord pour lui : choisissez SwiftUI.
• iOS et Android dès le lancement avec un seul budget : React Native si votre équipe maîtrise React et TypeScript, Flutter si vous voulez une interface sur mesure identique sur les deux plateformes.
• Widgets, Live Activities, App Intents et apps Apple Watch s’écrivent en Swift quel que soit votre choix : une app multiplateforme qui en a besoin exige quand même des compétences iOS.
• Les performances brutes départagent rarement une app classique ; l’intégration à la plateforme, votre équipe et la maintenance, si. Quand elles comptent, mesurez lancement, saccades, mémoire, poids et énergie sur un build Release avec Instruments plutôt que de vous fier à des graphiques génériques.
• L’option la moins chère au lancement ne l’est pas toujours sur trois ans : comptez les mises à niveau, les plugins et les ponts natifs.

SwiftUI, Flutter et React Native en bref

SwiftUI est le framework d’interface déclaratif d’Apple, lancé en 2019 et écrit en Swift. Un même code cible iPhone, iPad, Mac, Apple Watch, Apple TV et Vision Pro, se compile en code natif et utilise les composants du système : quand Apple a introduit le design Liquid Glass avec iOS 26, les composants SwiftUI standard l’ont adopté dès la recompilation avec Xcode 26. UIKit reste disponible pour les rares écrans que SwiftUI ne couvre pas.

Flutter est la boîte à outils d’interface de Google. Vous écrivez en Dart, et Flutter dessine lui-même chaque pixel avec son moteur de rendu Impeller, le seul utilisé sur iOS : c’est pourquoi une app Flutter a la même apparence sur iOS et sur Android. Le même code peut aussi viser le web et le desktop. Les API iOS passent par des plugins ou des platform channels écrits en Swift.

React Native, maintenu par Meta, permet d’écrire l’app en JavaScript ou TypeScript avec React et affiche de vraies vues natives. Sa New Architecture (Fabric, TurboModules, JSI), activée par défaut depuis la version 0.76, est devenue la seule possible avec la 0.82 (octobre 2025), Hermes V1 est le moteur JavaScript par défaut depuis la 0.84 (février 2026), et Expo est la façon recommandée de démarrer un projet. Faute de bibliothèque existante, les modules natifs s’écrivent en Swift.

Une quatrième voie mérite d’être citée : Kotlin Multiplatform partage entre Android et iOS une logique métier écrite en Kotlin, tout en conservant des écrans SwiftUI natifs sur iPhone.

Tableau comparatif

Les performances comptent-elles encore ?

Pour une app classique (listes, formulaires, graphiques, API réseau), les trois défilent sans accroc à 60 ou 120 Hz quand elles sont bien construites. Les écarts apparaissent aux limites :

• Poids et démarrage : Flutter embarque son moteur dans l’app, ce qui ajoute quelques mégaoctets et du travail au lancement ; React Native charge un bundle JavaScript compilé en bytecode par Hermes.
• Temps réel : analyse audio, capteurs à haute fréquence, traitement caméra et graphismes Metal sont plus simples et plus prévisibles en Swift, sans pont entre votre logique et le système.
• Longues sessions : un runtime supplémentaire consomme un peu de mémoire et de batterie, ce qui compte pour une app ouverte pendant des heures.

Dans notre catalogue, Ratewell mesure la marche et l’amplitude d’une montre mécanique en analysant son tic-tac via le micro, dB Meter Pro calcule des niveaux sonores pondérés en temps réel, et ApexLap chronomètre les tours au GPS, y compris avec des récepteurs externes à 10 Hz. Ces apps sont natives pour une bonne raison. Une app de réservation ou un outil interne n’en aurait pas besoin. Si les performances pèsent dans votre choix, mesurez-les plutôt que de les supposer : la section suivante explique comment.

Benchmarks de performances : comment comparer SwiftUI, Flutter et React Native

Il n’existe pas de chiffre unique, à jour et fiable qui dirait de combien SwiftUI est plus rapide que React Native ou Flutter. Les résultats dépendent de l’app, de l’appareil, des réglages de compilation et de la version du framework, et bien des graphiques qui circulent encore ont été produits avec des builds Debug, sur le simulateur, ou avec des versions antérieures à la New Architecture obligatoire de React Native et au passage de Flutter à Impeller. Plutôt que de reprendre des chiffres invérifiables, cette section explique pourquoi les trois technologies se comportent différemment, quels cinq indicateurs mesurer, avec quels outils Apple, et selon quel protocole reproductible.

Pourquoi les trois technologies ne se comportent pas pareil

SwiftUI. Swift est compilé à l’avance en code machine, et les vues SwiftUI deviennent des vues du système dessinées par Core Animation, la même chaîne que les apps d’Apple. Rien de plus n’est embarqué dans votre app pour dessiner l’interface. Les coûts habituels viennent de votre code : des corps de vue recalculés trop souvent, ou un travail lourd sur le thread principal. L’instrument SwiftUI apparu avec Instruments 26 montre les mises à jour de vue trop longues et ce qui les a déclenchées (WWDC25 : Optimize SwiftUI performance with Instruments).

Flutter. Dart est lui aussi compilé à l’avance, mais le moteur Flutter, embarqué dans votre app, dessine chaque pixel via Impeller sur Metal : un thread UI construit un arbre de calques qu’un thread de rastérisation affiche (documentation Flutter sur le profilage). Impeller est le seul moteur de rendu sur iOS et compile ses shaders au moment du build, ce qui a supprimé les saccades de compilation de shaders au premier lancement associées à l’ancien moteur Skia (documentation Impeller). Les coûts structurels sont le poids du moteur dans le binaire et le travail qu’il accomplit avant la première image.

React Native. Votre JavaScript tourne sur Hermes et il est compilé en bytecode au build, ce qui, selon l’équipe React Native, améliore le démarrage, la mémoire et le poids de l’app par rapport à JavaScriptCore (Using Hermes). Depuis la 0.82, la New Architecture est la seule : JSI remplace l’ancien pont asynchrone, Fabric affiche de vraies vues UIKit et la mise en page peut être lue de façon synchrone (About the New Architecture, React Native 0.82). Hermes V1 est devenu le moteur par défaut avec la 0.84. Une scroll view native continue de défiler sur le thread principal, mais toute mise à jour qui dépend du JavaScript perd des images quand le thread JavaScript est occupé (Performance overview).

Une conséquence compte pour la mesure : quel que soit le framework, le résultat est un seul processus iOS. Instruments, XCTest et l’Organizer de Xcode l’observent de l’extérieur, ce qui en fait des arbitres équitables. Flutter DevTools et le Perf Monitor de React Native sont excellents pour diagnostiquer chaque technologie, mais leurs chiffres ne se comparent pas d’une technologie à l’autre.

Les cinq indicateurs à mesurer, et l’outil Apple pour chacun

• Lancement. Apple distingue un lancement d’une reprise et considère lancements à chaud et à froid comme un continuum : un lancement juste après un redémarrage, ou après qu’un jeu gourmand a chassé votre app de la mémoire, est plus lent. L’Organizer indique les millisecondes entre le toucher et la première image après l’écran de lancement, au 50e et au 90e centile (Reducing your app’s launch time).
• Saccades. Une saccade (hitch) est une image qui arrive en retard. À 120 Hz, une nouvelle image est attendue toutes les 8,3 ms, à 60 Hz toutes les 16,7 ms. Apple exprime le taux de saccades en millisecondes de pause par seconde : jusqu’à 10 ms/s c’est bon, jusqu’à 25 c’est un avertissement, jusqu’à 50 c’est critique, et au-delà il faut agir immédiatement (Understanding hitches in your app).
• Mémoire. L’Organizer et MetricKit indiquent le pic de mémoire et la mémoire à la suspension. Seule la mémoire « sale » compte, par pages de 16 Ko en général, et une app trop gourmande a plus de chances d’être fermée en arrière-plan (Reducing your app’s memory use).
• Poids. Ne mesurez jamais le .app, le .xcarchive ou l’.ipa envoyé : ils contiennent des fichiers que l’utilisateur ne télécharge pas, comme les symboles de débogage. Utilisez le rapport de taille de Xcode pendant le développement, puis le tableau App File Sizes d’un build dans App Store Connect, qui donne la taille de téléchargement et d’installation de chaque variante d’appareil (Reducing your app’s size, View builds and metadata). Pour Flutter, flutter build ios --analyze-size détaille ce qu’ajoutent le moteur et votre code Dart (Measuring your app’s size). Notre guide TestFlight montre où se trouvent les builds envoyés dans App Store Connect.
• Énergie. Power Profiler enregistre la consommation du système et l’impact de votre app sur le processeur, le GPU, l’écran et le réseau, appareil branché ou en autonomie via les réglages Développeur ; il exige iOS 26 ou iPadOS 26 (Measuring your app’s power use with Power Profiler). En production, la vue Battery Usage de l’Organizer détaille la consommation au premier plan et en arrière-plan, version par version (Analyzing your app’s battery use).

Un protocole de benchmark reproductible

1. Un seul cahier des charges. Mêmes écrans, mêmes données, même scénario dans chaque technologie : par exemple une longue liste avec vignettes, un écran de détail aller-retour et un graphique animé. Sans travail identique, vous comparez deux apps, pas deux frameworks.
2. Compiler en Release. Configuration Release dans Xcode, flutter build ipa pour Flutter, build de release avec bytecode Hermes pour React Native. Les builds Debug de Flutter et de React Native sont lents par construction, et le simulateur ne dit rien des performances sur un appareil.
3. Figer les conditions. Même iPhone physique et même version d’iOS, idéalement complétés par le plus ancien appareil pris en charge ; mode Économie d’énergie désactivé, appareil hors charge, même luminosité, réponses réseau simulées, et appareil refroidi entre deux séries.
4. Automatiser le scénario. Pilotez chaque build avec le même test d’interface pour que chaque technologie reçoive les mêmes gestes, et enregistrez les traces Instruments avec les mêmes modèles.
5. Répéter. Au moins dix mesures par indicateur et par technologie. Étiquetez séparément les lancements à froid (premier lancement après un redémarrage) et à chaud ; ne les moyennez jamais ensemble.
6. Publier honnêtement. Médiane et dispersion (90e centile ou minimum et maximum), unité, nombre de mesures, appareil, versions d’iOS, de Xcode, de Flutter et de React Native, date, et le projet de test pour que d’autres puissent le relancer.

La partie XCTest tient dans un seul fichier. Comme le test pilote l’app de l’extérieur et balaie toute la fenêtre, le même test peut tourner sur les builds SwiftUI, Flutter et React Native :

import XCTest

final class BenchmarkTests: XCTestCase {
    func testLaunch() {
        let options = XCTMeasureOptions()
        options.iterationCount = 10
        measure(metrics: [XCTApplicationLaunchMetric()], options: options) {
            XCUIApplication().launch()
        }
    }

    func testScrollHitchesAndMemory() {
        let app = XCUIApplication()
        app.launch()
        let options = XCTMeasureOptions()
        options.iterationCount = 10
        measure(metrics: [XCTHitchMetric(application: app),
                          XCTMemoryMetric(application: app)],
                options: options) {
            app.swipeUp(velocity: .fast)
            app.swipeDown(velocity: .fast)
        }
    }
}

Lancez-le sur un appareil, pas sur le simulateur. XCTHitchMetric exige Xcode 26 et iOS 26 ou ultérieur ; sur un système plus ancien, enregistrez le même défilement avec le modèle Animation Hitches, et vérifiez que chaque trace contient bien des images avant de comparer.

Modèle de tableau de résultats

Utilisez cette grille pour présenter vos propres mesures. Elle est volontairement vide : nous ne publions que des chiffres mesurés selon ce protocole, et les tirets attendent les vôtres.

Appliquez le même filtre aux benchmarks des autres : une date, des versions de frameworks, des builds Release, un appareil physique identifié, un nombre de mesures et un code source publié. Un graphique sans tout cela reste une opinion. Si vous appliquez ce protocole à votre app et souhaitez un second regard sur les traces, nous serons ravis d’en discuter, et nous publierons peut-être ici nos propres mesures une fois réalisées selon ces règles.

Quoi mesurer en premier, selon le type d’app

Tous les indicateurs ne pèsent pas autant. Une app de contenus ou de réservation se joue sur le temps de lancement et, pour ceux qui l’installent en réseau mobile, sur son poids ; entre deux versions bien construites, les écarts de saccades se voient rarement. Une interface très animée et très marquée doit surveiller les saccades. Les apps d’audio, de capteurs ou de caméra en temps réel, et les longues sessions comme le sport ou la navigation, doivent regarder de près la mémoire et l’énergie : c’est là qu’un runtime supplémentaire coûte le plus au fil des heures.

Si vous hésitez encore, prototypez et mesurez une fine tranche verticale de votre produit avant de vous engager, puis construisez un MVP ciblé avec la technologie gagnante. Si votre app est déjà en ligne, la vue Insights de l’Organizer est le point de départ le moins coûteux, et garder une app existante rapide, stable et à jour à chaque version d’iOS est le rôle de notre service de maintenance d’application iOS.

L’accès aux frameworks Apple : la vraie différence

C’est ici que le choix se joue. Apple livre de nouvelles possibilités chaque mois de juin, et une app native peut les adopter le jour même de la sortie du SDK. Avec un framework multiplateforme, vous attendez un plugin ou vous écrivez le pont vous-même, en Swift. Plusieurs fonctions ne peuvent tout simplement pas s’écrire en Dart ou en JavaScript :

• Les widgets de l’écran d’accueil et de l’écran verrouillé (WidgetKit) sont des vues SwiftUI dans une extension d’app.
• Les Live Activities et leurs mises en page pour la Dynamic Island sont aussi en SwiftUI, dans la même extension.
• Les App Intents (Siri, Raccourcis, Spotlight, bouton Action) sont des types Swift que Xcode analyse à la compilation.
• Les apps Apple Watch sont des apps watchOS natives ; ni Flutter ni React Native ne ciblent watchOS.
• Les apps visionOS natives reposent sur SwiftUI et RealityKit.

Voici le Swift qu’une équipe multiplateforme doit tout de même écrire pour une simple action Siri et Raccourcis :

import AppIntents

struct LogDoseIntent: AppIntent {
    static let title: LocalizedStringResource = "Enregistrer une prise"

    func perform() async throws -> some IntentResult & ProvidesDialog {
        try await DoseStore.shared.logNextDose()
        return .result(dialog: "Prise enregistrée.")
    }
}

Rien n’empêche une app Flutter ou React Native d’offrir tout cela. Simplement, le projet a de toute façon besoin de quelqu’un qui maîtrise Swift, et les données doivent circuler entre la partie Dart ou JavaScript et les extensions, en général via un App Group.

Fidélité de l’interface et accessibilité

Les utilisateurs d’iPhone remarquent quand la navigation, la sélection de texte, l’inertie du défilement ou la feuille de partage sonnent légèrement faux. SwiftUI utilise les vrais composants du système : Dynamic Type, VoiceOver, le mode sombre et chaque nouveau langage visuel suivent d’eux-mêmes. React Native affiche aussi des vues natives, mais les composants sur mesure que votre équipe construit en JavaScript ne suivent pas seuls les évolutions du système. Flutter redessine tout : ses widgets Cupertino imitent iOS avec soin, mais restent une imitation que l’équipe Flutter doit mettre à jour à chaque changement de design d’Apple, comme avec Liquid Glass. L’accessibilité est atteignable avec les trois, au prix de davantage de travail manuel hors de SwiftUI.

Quand le multiplateforme est le bon choix

• Vous avez besoin d’iOS et d’Android dès le lancement, avec le budget d’une seule équipe.
• L’app sert surtout de façade à votre service : place de marché, réservation, e-commerce, contenus, outils internes.
• Votre équipe écrit déjà du React et du TypeScript (React Native), ou vous voulez une interface très marquée, identique sur les deux plateformes (Flutter).
• La feuille de route prévoit peu d’intégrations profondes au système : ni app Apple Watch, ni Live Activities, ni HealthKit.

D’excellentes apps sont construites ainsi. L’important est de choisir en connaissance de cause, en budgétant dès le départ les parties natives de la feuille de route.

Quand Swift et SwiftUI natifs l’emportent

• Vos utilisateurs sont surtout sur iPhone, ou vous voulez valider le produit sur iOS avant d’investir dans Android.
• Le produit s’appuie sur les frameworks Apple : HealthKit, widgets, Live Activities, App Intents, Apple Watch, synchronisation iCloud avec CloudKit, abonnements StoreKit 2, IA embarquée avec le framework Foundation Models.
• L’app exploite le matériel : micro, appareil photo, GPS, accessoires Bluetooth, capteurs de mouvement.
• Vous voulez aussi une app Mac : SwiftUI partage l’essentiel du code avec macOS, et c’est ainsi que sont conçus nos outils pour développeurs Xlocalize et Appviary.
• Le produit doit vivre des années et vous voulez le moins de dépendances possible entre vous et la plateforme.

Checklist de décision

Répondez à ces sept questions avant de vous engager :

1. Où seront vos premiers utilisateurs ? S’ils ont surtout un iPhone, commencez en natif.
2. Avez-vous besoin d’Android le jour du lancement, ou dans un an ?
3. Quelles fonctions Apple figurent dans la feuille de route ? Chaque widget, Live Activity, action Siri ou app Apple Watch représente du travail en Swift, quelle que soit la technologie.
4. Que maîtrise déjà votre équipe, et qui maintiendra l’app dans deux ans ?
5. L’interface est-elle standard (listes, formulaires, onglets) ou très personnalisée, dictée par la marque ?
6. L’app sollicite-t-elle fortement le matériel : audio, capteurs, caméra, graphismes en temps réel ?
7. Quel est votre vrai budget pour deux plateformes, y compris pour les maintenir alignées après le lancement ?

En règle générale : iPhone d’abord et au moins deux fonctions propres à Apple, c’est SwiftUI. Android au lancement, une app de contenus et une équipe React, c’est React Native. Android au lancement avec un design entièrement sur mesure, c’est Flutter. Entre les deux, un court échange de cadrage s’impose avant d’écrire la moindre ligne de code.

La position de Develak : natif, et transparent

Nous sommes un studio iOS natif. Les plus de 30 apps que nous avons publiées depuis mars 2025, pour iPhone, iPad et Mac, sont développées en Swift et SwiftUI, tout comme nos projets clients. Nous ne développons pas d’apps Flutter ou React Native, et préférons vous le dire plutôt que d’apprendre un framework à vos frais.

Quand un client a besoin d’Android, nous recommandons un partenariat : nous développons l’app iOS en natif, un spécialiste Android développe l’app Android en Kotlin et Jetpack Compose, et les deux partagent le même back-end, la même API et le même design system. Pour un nouveau produit, lancer d’abord sur iPhone avec un MVP ciblé, puis ajouter Android une fois le produit validé, est souvent la voie la plus économique. Notre page développement d’application iOS détaille notre méthode, et nous serons ravis d’étudier votre projet.

Questions fréquentes