Natif, hybride, PWA, wrapper : ce que produit vraiment chaque outil

Une app créée avec un outil IA ou no-code n’est pas forcément native. Derrière le mot « app », les outils IA et no-code produisent quatre choses différentes : du code natif écrit en Swift ou en Kotlin, une app multiplateforme compilée depuis React Native ou Flutter, un site emballé dans une coquille d’app, ou une version web installée depuis le navigateur. La plupart des générateurs IA produisent du React Native ; seuls quelques-uns écrivent du Swift.

Les quatre familles, simplement

Famille	Ce que c’est	Technologie habituelle	Comment la reconnaître
Natif	Une app par plateforme, écrite dans la langue de chaque plateforme avec les outils d’Apple et de Google	Swift ou SwiftUI sur iOS, Kotlin sur Android	Deux projets distincts : un projet Xcode avec des fichiers .swift, un projet Android avec des fichiers .kt
Multiplateforme compilé	Un seul code transformé en une vraie app iOS et une vraie app Android	React Native (souvent avec Expo), Flutter	Un package.json qui mentionne react-native ou expo, ou un pubspec.yaml avec des fichiers Dart pour Flutter
Wrapper (souvent appelé hybride)	Un site affiché dans une coquille d’app, via une web view	Capacitor, Cordova, une coquille maison de l’éditeur	L’app charge une adresse web, et le contenu change sans nouvelle version sur le store
PWA (version web installable)	Une app web que l’on installe depuis le navigateur	HTML, JavaScript, un service worker	Pas de fiche sur les stores : on ouvre une adresse web, puis « Sur l’écran d’accueil »

Deux nuances comptent. React Native n’est pas un site : à l’exécution, il crée les vues Android et iOS correspondantes, selon sa documentation. Flutter compile lui aussi en code machine, mais il a sa propre version de chaque contrôle au lieu d’utiliser ceux du système. Les deux donnent de vraies apps installées ; aucun des deux n’est du Swift ou du Kotlin.

Un wrapper, lui, ne s’en cache pas. La documentation de Base44 décrit son app mobile comme une coquille native légère autour de votre app web, qui n’ouvre que l’adresse de votre app.

Ce que chaque famille sait faire, ou pas

Fonction	Natif	Multiplateforme compilé	Wrapper	PWA
Notifications push	Oui	Oui	Si la coquille les ajoute (Base44 le fait)	Sur iPhone, seulement une fois ajoutée à l’écran d’accueil, depuis iOS 16.4
Hors connexion	Oui	Oui	Selon la coquille (pas de mode hors ligne complet chez Base44)	En partie, grâce à un service worker
Siri et App Intents, widgets	Oui, directement	Oui, en ajoutant du code natif au projet	Seulement si la coquille ajoute du code natif	Non
Achats intégrés Apple et Google	Oui	Oui	Selon la coquille (non pris en charge chez Base44)	Non, le paiement se fait sur le web
Acceptation sur les stores	Oui	Oui	Risquée si l’app ne fait rien de plus que le site (règle 4.2)	Pas sur l’App Store

Notifications. iOS et iPadOS 16.4, sortis en mars 2023, ont ouvert les notifications web aux apps web ajoutées à l’écran d’accueil, selon WebKit. Une version web ouverte dans Safari sans être installée ne reçoit rien.

Siri, widgets et fonctions du système. Le framework App Intents d’Apple permet à une app de rendre ses actions et ses données accessibles à Siri, Spotlight, Raccourcis et aux widgets. Les widgets eux-mêmes se construisent avec WidgetKit. Ce sont des frameworks natifs, compilés dans l’app. La documentation de Flutter montre le chemin pour une app multiplateforme : on ajoute une extension dans Xcode et on la gère avec les mêmes techniques qu’une app UIKit ou SwiftUI. Sur Android, l’équivalent pour les assistants s’appelle AppFunctions, disponible à partir d’Android 16 et encore expérimental. Une page web ne peut s’inscrire ni à l’un ni à l’autre.

Achats intégrés. La règle 3.1.1 d’Apple impose l’achat intégré pour débloquer des fonctions ou du contenu numérique dans une app. Base44 indique que ses apps ne prennent pas encore en charge l’achat intégré d’Apple ni Google Play Billing. Une version web n’est pas sur le store : elle encaisse sur le web, comme n’importe quel site.

Acceptation sur les stores. La règle 4.2 demande des fonctions, du contenu et une interface qui vont au-delà d’un site reconditionné. Les wrappers sont les plus exposés. Notre article sur les apps créées par IA refusées par Apple détaille ce point.

Pourquoi le natif revient dans le débat en 2026

Deux faits datés. Le 10 septembre 2026, Shopify a annoncé migrer toutes ses apps mobiles de React Native vers Swift et Kotlin, parce que les agents de code absorbent désormais une bonne part du coût de développer deux fois. Et la refonte d’Apple, Liquid Glass, s’applique aux apps qui utilisent les composants standard de SwiftUI ou UIKit dès qu’elles sont compilées avec le dernier SDK, selon Apple. Flutter dessine ses propres contrôles : il doit donc reconstruire ce style lui-même. Le 10 juin 2025, l’équipe Flutter écrivait ne pas développer ce nouveau design dans sa bibliothèque Cupertino « pour l’instant », et le ticket GitHub était toujours ouvert le 12 novembre 2026.

Mathieu Poli, responsable de l’ingénierie frontend chez GoodBarber, défend le natif dans trois textes signés, en anglais. Dans « Everyone is going back to native. We never left » (dev.to, 11 septembre 2026), il rappelle que les couches intermédiaires passent : Adobe a arrêté PhoneGap en 2020 et Microsoft a mis fin au support de Xamarin le 1er mai 2024. Dans « The assistant is making the native app mandatory again » (dev.to, 1er octobre 2026), il explique qu’App Intents et AppFunctions sont des kits natifs auxquels une page web ne peut pas s’inscrire. Dans « Native is a floor, not a ceiling » (UX Collective, 6 novembre 2026), il prend Liquid Glass pour montrer ce que les apps natives recompilées obtiennent sans effort. Lisez-les comme une position argumentée, celle de GoodBarber, qui publie ce site. Les faits sur lesquels ils s’appuient sont dans nos sources.

Ce que produit chaque outil

Vérifié le 12 novembre 2026 sur la documentation de chaque éditeur, en cohérence avec notre comparatif des meilleurs outils IA pour créer une app mobile.

Outil	Ce qu’il produit	Famille	En pratique
Lovable	App web	Web, pas une app mobile	S’ouvre dans un navigateur, ne va pas sur les stores
Bolt	App web, ou React Native avec Expo	Web, ou multiplateforme compilé	En mobile, une vraie app que vous compilez et publiez vous-même avec Expo
Base44	App web dans une web view	Wrapper	Notifications possibles ; ni achats intégrés ni hors ligne complet pour l’instant
Replit	React Native avec Expo	Multiplateforme compilé	Publication sur iOS seulement
Rork	SwiftUI, Kotlin	Natif	Va jusqu’à la soumission sur l’App Store ; pour Google Play, fournit un fichier .aab que vous envoyez vous-même
Vibecode	Swift, ou React Native	Natif ou multiplateforme	La voie Swift va jusqu’à la soumission sur l’App Store
Anything	React Native avec Expo	Multiplateforme compilé	iOS ; Google Play en bêta
Newly (ex-Natively)	React Native avec Expo	Multiplateforme compilé	iOS (TestFlight) et Google Play
a0.dev	React Native	Multiplateforme compilé	iOS
Draftbit	React Native avec Expo	Multiplateforme compilé	Compile et envoie sur les deux stores
FlutterFlow	Flutter	Multiplateforme compilé	Code Flutter exportable ; contrôles dessinés par Flutter
Adalo	App présentée comme native	App compilée, technologie non publiée	Code complet exportable sur l’offre Business
Thunkable	App présentée comme native	App compilée, technologie non publiée	Pas d’export du code
Glide	PWA	PWA	Ne va pas sur les stores
GoodBarber	Apps iOS et Android compilées avec ses moteurs natifs (Swift pour iOS, Kotlin pour Android), plus une PWA	Natif et PWA	Publication accompagnée, ou prise en charge par le service GoodBarber Takes Care ; code source non exportable

Adalo et Thunkable ne publient pas la technologie de leurs apps. Chez Adalo, l’export complet du code, sur l’offre Business, permet de la vérifier ; Thunkable n’exporte pas le code. GoodBarber non plus, mais son équipe d’ingénierie indique publiquement que ses moteurs sont écrits en Swift et en Kotlin.

Notre avis, selon votre projet

• Tester une idée, ou un outil interne utilisé autant sur ordinateur que sur téléphone : une app web ou une version web installable suffit. Lovable, Glide ou la version web de GoodBarber vous y mènent sans validation des stores ni frais de compte développeur.
• Mettre un site existant sur les stores : un wrapper fonctionne techniquement, mais ajoutez ce qu’un site ne sait pas faire (notifications, hors ligne, fonctions du téléphone), sinon attendez-vous à la règle 4.2.
• Une vraie app dont vous, ou un développeur, garderez le code : React Native avec Expo (Bolt, Newly, Draftbit) ou Flutter (FlutterFlow). C’est suffisant pour la plupart des apps ; les actions Siri et les widgets demanderont un peu de code natif en plus.
• Une app qui doit se comporter comme une app iOS et Android, et parler à Siri et aux widgets : le natif. Rork ou Vibecode si vous voulez du Swift généré par IA et êtes prêt à le maintenir, un développeur pour un projet spécifique, ou un outil no-code natif comme GoodBarber si vous préférez ne pas toucher au code.

Quelle que soit la famille, la publication passe par les mêmes étapes : voyez notre guide pour publier une app créée avec l’IA.