Publier une app Lovable sur l'App Store : PWA, Capacitor ou refonte, et éviter la règle 4.2 (2026)

Si vous cherchez comment publier une app Lovable sur l'App Store, sachez d'abord que Lovable ne peut pas le faire à votre place. La documentation de publication de Lovable indique que « Lovable crée des applications web et la publication déploie toujours sur une URL web » et qu'il n'existe « aucun flux intégré qui package et soumet votre projet sur l'App Store ou Google Play ». Voici les trois options réelles, ce que chacune coûte, et les étapes qui permettent à une app Lovable encapsulée d'échapper à la règle 4.2.

Peut-on publier une app Lovable directement sur l'App Store ?

Non. En octobre 2026, Lovable publie sur un sous-domaine lovable.app ou sur un domaine personnalisé. Pour arriver sur un store, il faut packager l'app en dehors de Lovable et la soumettre depuis votre propre compte développeur.

La documentation de Lovable propose deux contournements : transformer le site publié en PWA installable, ou « encapsuler votre URL publiée dans un shell natif avec Capacitor en dehors de Lovable » et soumettre ce shell vous-même. La documentation précise aussi deux points. Lovable ne génère pas de projets React Native, et l'app mobile Lovable sert uniquement à créer des projets depuis votre téléphone. Elle « ne transforme pas votre projet en app native pour les utilisateurs finaux ».

PWA, wrapper Capacitor ou refonte : quelle option choisir ?

Choisissez une PWA si vous n'avez pas besoin de fiche sur les stores, Capacitor si vous en avez besoin et pouvez ajouter de vraies fonctionnalités natives, et une refonte native si votre app doit se comporter comme un produit pensé d'abord pour le mobile.

Les frais proviennent de la page d'inscription à l'Apple Developer Program (« 99 USD par année d'adhésion. Les prix peuvent varier selon la région ») et de l'aide de la Google Play Console (« des frais d'inscription uniques de US$25 »). Sur Google Play, les nouveaux comptes personnels doivent aussi mener un test fermé avec 12 testeurs pendant 14 jours avant d'obtenir l'accès à la production. Notre guide sur les tests fermés détaille cette étape.

Comment encapsuler une app Lovable avec Capacitor ?

Exportez le code Lovable vers GitHub, compilez-le en local, ajoutez Capacitor et pointez webDir vers le dossier de build. Ouvrez ensuite les projets natifs dans Xcode et Android Studio, puis archivez-les.

1. Dans Lovable, connectez GitHub. La synchronisation est bidirectionnelle et crée toujours un nouveau dépôt privé : vous pouvez donc continuer à modifier dans Lovable tout en travaillant sur le shell natif en local.
2. Clonez le dépôt, lancez npm install, puis npm run build. Vérifiez où Vite écrit le build, généralement dans dist. Capacitor a besoin d'un index.html avec une balise <head> à cette racine.
3. Installez Capacitor et les plateformes avec les commandes du bloc de code ci-dessous, tirées de la documentation de démarrage de Capacitor.
4. Dans capacitor.config, définissez webDir sur dist. Ne définissez pas server.url sur votre domaine Lovable en ligne : la référence de configuration de Capacitor précise qu'il « n'est pas destiné à être utilisé en production ».
5. Ajoutez des plugins natifs (push, retour haptique, partage, biométrie, notifications locales) ainsi que des icônes et écrans de lancement natifs.
6. Lancez npx cap sync après chaque build web, puis archivez dans Xcode et uploadez sur App Store Connect. Notre checklist de soumission App Store couvre la suite.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Soumettez depuis votre propre compte Apple. La règle 4.2.6 rejette les apps créées avec un service de génération d'apps, sauf si elles sont « soumises directement par le fournisseur du contenu de l'app ». Notre guide sur les règles 4.3 et 4.2.6 explique comment cela s'applique aux apps créées par IA.

Comment éviter un rejet 4.2 avec une app Lovable encapsulée ?

Faites en sorte que l'app fasse ce que le site web ne peut pas faire. La règle 4.2 exige « des fonctionnalités, du contenu et une UI qui l'élèvent au-delà d'un site web reconditionné », et la règle 4.2.2 exclut les apps qui sont principalement « des extraits de sites web, des agrégateurs de contenu ou une collection de liens ».

Utilisez cette checklist avant de soumettre :

• Le build web est intégré dans le binaire et s'ouvre sans connexion réseau, en affichant des données en cache ou un véritable écran hors ligne.
• La navigation utilise une barre d'onglets en bas plutôt qu'un menu hamburger, et il n'y a ni pied de page propre au web ni bannière de cookies.
• La connexion, l'inscription et la réinitialisation du mot de passe se font toutes dans l'app. Rien ne renvoie l'utilisateur vers Safari.
• Au moins un parcours essentiel repose sur l'appareil : capture photo, notifications locales liées aux propres données de l'utilisateur, widgets ou biométrie.
• Les liens externes vers des pages de dons, des boutiques ou des réseaux sociaux sont supprimés ou réduits au minimum.
• Les notes pour l'App Review expliquent pourquoi l'app est utile sur téléphone et incluent un identifiant de démo.

Que s'est-il passé quand d'autres apps web ont été rejetées au titre de la 4.2 ?

Les discussions publiques montrent le même schéma : les reviewers rejettent une UI qui ressemble à du web et les liens vers Safari, et l'ajout de petites fonctionnalités natives ne suffit pas à changer leur décision.

En décembre 2020, un développeur sur l'Ionic Forum a vu son app d'adhésion à un club rejetée avec le message « Votre app offre une expérience utilisateur limitée car elle n'est pas suffisamment différente d'une expérience de navigation mobile », suivi de « la plupart du contenu de l'app renvoie vers Safari ». Supprimer InAppBrowser et améliorer le support hors ligne n'a pas suffi, et la deuxième soumission a aussi été rejetée. La troisième tentative a été approuvée après que le développeur a refait l'écran d'accueil avec des listes et des cartes d'images au style natif, ajouté davantage d'actualités dans l'app et supprimé la plupart des liens externes.

En janvier 2026, un développeur sur les Apple Developer Forums a signalé qu'une app de planification avait été rejetée comme « pas suffisamment différente d'une expérience de navigation web », alors qu'elle utilisait déjà les notifications push, Core Location et l'accès aux contacts. Il prévoyait d'ajouter du retour haptique, des actions rapides et une intégration plus poussée du calendrier, et demandait ce qui compte comme « plus natif ». Au moment de la rédaction, la discussion n'a reçu aucune réponse et aucun résultat n'est confirmé.

La comparaison : le premier développeur est passé en changeant la nature de l'app (contenu dans l'app, mises en page natives, aucun lien externe). Le second n'a ajouté que des API de l'appareil et restait dans l'incertitude. Concentrez vos efforts sur l'expérience centrale, pas sur une liste de permissions plus longue.

Quand faut-il refaire l'app plutôt que l'encapsuler ?

Refaites l'app en natif quand sa valeur principale est du contenu web, ou quand vous avez déjà essuyé deux rejets 4.2 pour la même UI.

Exemple concret : un outil de réservation Lovable pour un studio de yoga affiche une liste de cours, un formulaire de réservation et un lien de paiement Stripe. Encapsulé tel quel, il cumule les trois signaux d'alerte de la 4.2 : UI web, lien externe et aucun usage hors ligne. En PWA, il peut être lancé dès aujourd'hui sans coût supplémentaire. Pour obtenir une fiche sur les stores, conservez le backend Lovable, refaites la liste de cours et le parcours de réservation avec des écrans natifs, ajoutez des rappels locaux avant chaque cours, et gérez le paiement dans le respect de la règle 3.1 de l'App Review. Votre backend et votre modèle de données sont conservés. Ce que vous réécrivez, c'est l'UI.

Si vous voulez un deuxième avis sur l'option adaptée à votre projet Lovable, les services de The App Guy couvrent l'encapsulation, la refonte et la soumission sur les stores, ou écrivez à yagyeshsrbobde@gmail.com.