App Lovable refusée par Apple : les 5 raisons les plus fréquentes (et comment les corriger)

Une app Lovable emballée pour iOS est généralement refusée par Apple pour l'une de ces cinq raisons : elle ressemble à un site web dans une boîte (règle 4.2), elle est incomplète ou impossible à tester (2.1), on peut y créer un compte mais pas le supprimer (5.1.1(v)), elle propose la connexion Google sans option équivalente comme « Se connecter avec Apple » (4.8), ou elle vend du contenu numérique via Stripe au lieu de l'achat intégré Apple (3.1.1). Les cinq se corrigent. Le message de refus indique la règle concernée, et la correction en dépend.

Cet article suppose que votre app Lovable est déjà emballée pour iOS et soumise. Si ce n'est pas le cas, commencez par notre guide pour publier une app Lovable sur l'App Store et Google Play.

Pourquoi Apple refuse-t-il si souvent les apps Lovable ?

Apple refuse souvent les apps Lovable parce que ce sont des apps web, pensées pour un navigateur, qui passent par un examen conçu pour des apps iPhone natives. Selon la documentation de publication de Lovable, à la date d'octobre 2026, publier dans Lovable produit une app web accessible à une adresse, pas un build pour l'App Store. Il faut donc emballer l'app dans une coque native, le plus souvent avec Capacitor. Selon la FAQ de Lovable, les apps créées depuis le 13 mai 2026 utilisent TanStack Start, avec rendu côté serveur : leur emballage demande en plus d'adapter la partie serveur, comme l'explique notre guide de publication.

Des habitudes sans conséquence sur le web (menu de site, connexion Google, paiement Stripe) deviennent alors des motifs de refus. Aucune n'est propre aux outils d'IA : les App Review Guidelines, mises à jour le 16 octobre 2026, s'appliquent à toutes les apps.

Quelles sont les 5 raisons les plus fréquentes de refus d'une app Lovable ?

Les cinq raisons les plus fréquentes de refus d'une app Lovable par Apple sont les règles 4.2, 2.1, 5.1.1(v), 4.8 et 3.1.1. Ce classement reflète notre expérience des apps web emballées, pas une statistique officielle d'Apple, sauf pour la 2.1, qu'Apple présente lui-même comme la première source de problèmes non résolus.

Un même message peut citer plusieurs règles : corrigez-les toutes avant de resoumettre.

Raison 1 : pourquoi Apple dit-il que votre app Lovable n'est « qu'un site web » ?

Apple refuse une app Lovable au titre de la règle 4.2 quand elle n'apporte rien de plus que le site ouvert dans Safari. Selon cette règle, l'app doit inclure des fonctions, du contenu et une interface qui dépassent un site web reconditionné.

• Dans le message : « Guideline 4.2 » et Minimum Functionality, généralement avec la remarque que l'expérience est trop proche d'un site web.
• Pourquoi les apps Lovable sont concernées : emballée telle quelle, l'app garde son menu web, son pied de page et son bandeau cookies, et n'utilise rien de l'iPhone. Le cas le plus exposé est la coque qui se contente d'afficher l'adresse en ligne de l'app : la documentation de Capacitor précise d'ailleurs que ce réglage (server.url) n'est pas prévu pour la production.
• La correction : quelques fonctions natives vraiment utiles (notifications, partage natif, appareil photo, Face ID, comportement hors ligne), une navigation mobile, et aucun élément purement web. Apple ne fixe aucun nombre minimum de fonctions.

Nous détaillons ce refus dans notre article sur le refus Apple 4.2 Minimum Functionality.

Raison 2 : pourquoi Apple juge-t-il votre app Lovable incomplète ?

Apple refuse une app au titre de la règle 2.1 App Completeness quand l'examinateur rencontre un plantage, un bug, un contenu provisoire ou un lien cassé, ou ne peut pas tester l'app. Selon la page App Review d'Apple, plus de 40 % des problèmes non résolus concernent cette règle. Elle demande de retirer tout contenu provisoire et de fournir un compte de démonstration, avec un serveur en marche, si l'app demande une connexion.

• Dans le message : « Guideline 2.1 », souvent avec la description de ce que l'examinateur a vu (écran blanc, erreur de connexion, bouton inactif), parfois une capture d'écran.
• Pourquoi les apps Lovable sont concernées :
  • des contenus d'exemple générés restés en place : faux témoignages, données fictives, pages « bientôt disponible » ;
  • une connexion qui bloque dans l'app : dans une coque native, le retour d'une connexion Google ou d'un lien magique doit rouvrir l'app grâce aux liens profonds (documentation Supabase), sinon l'examinateur reste bloqué ;
  • sur une app créée depuis le 13 mai 2026 (TanStack Start), des appels au serveur qui échouent dans l'app : une fonction serveur que l'app mobile ne sait pas joindre peut donner un écran vide ou une erreur ;
  • aucun compte de démonstration dans les notes pour l'examen.
• La correction : tester chaque écran sur un vrai iPhone, retirer tout contenu provisoire, vérifier chaque lien, et fournir un compte de démonstration fonctionnel, avec des données réalistes, dans la section App Review Information d'App Store Connect.

Raison 3 : pourquoi Apple exige-t-il la suppression de compte dans votre app Lovable ?

Apple exige la suppression de compte parce que la règle 5.1.1(v) l'impose : « If your app supports account creation, you must also offer account deletion within the app » (si votre app permet de créer un compte, elle doit aussi permettre de le supprimer depuis l'app). Presque toutes les apps Lovable avec inscription sont concernées.

• Dans le message : « Guideline 5.1.1(v) », indiquant que l'app permet de créer un compte sans permettre d'en lancer la suppression.
• Pourquoi les apps Lovable sont concernées : la version web fonctionne sans écran de suppression. Selon la documentation d'authentification de Lovable, le propriétaire de l'app peut supprimer un utilisateur depuis les réglages du projet, mais c'est une action pour vous, pas pour vos utilisateurs.
• La correction : selon la page d'Apple sur la suppression de compte, l'option doit être facile à trouver (en général dans les réglages du compte) et supprimer tout le compte avec les données personnelles associées, pas seulement le désactiver. Hors secteurs très réglementés, l'utilisateur ne doit pas avoir à appeler ni à écrire un email. Les apps avec « Se connecter avec Apple » doivent aussi révoquer les jetons de l'utilisateur.

Avec Supabase, c'est en général une fonction côté serveur qui supprime l'utilisateur et ses données, appelée depuis un bouton de l'app après confirmation. Sur une app TanStack Start, si cette fonction est une fonction serveur de l'app, vérifiez qu'elle reste joignable depuis l'app mobile.

Raison 4 : pourquoi Apple demande-t-il « Se connecter avec Apple » dans votre app Lovable ?

Apple demande « Se connecter avec Apple » quand votre app propose Google, ou une autre connexion tierce ou sociale, sans alternative équivalente. La règle 4.8 impose alors un autre service de connexion qui limite les données collectées au nom et à l'email, permet de garder son email privé et ne collecte pas les interactions à des fins publicitaires sans consentement. « Se connecter avec Apple » remplit ces critères.

• Dans le message : « Guideline 4.8 » et Login Services.
• Pourquoi les apps Lovable sont concernées : la connexion Google est l'une des fonctions les plus rapides à ajouter dans Lovable.
• La correction : ajouter « Se connecter avec Apple » à côté de Google. À la date d'octobre 2026, la documentation d'authentification de Lovable cite Apple parmi les modes de connexion pris en charge, et Supabase le gère sur le web et en natif sur iOS. Vérifiez ensuite que le parcours revient bien dans l'app.

La règle 4.8 ne s'applique pas, entre autres exceptions, si l'app n'utilise que son propre système de comptes (email et mot de passe). Retirer la connexion Google de la version iOS est aussi une option.

Raison 5 : pourquoi Apple refuse-t-il le paiement Stripe de votre app Lovable ?

Apple refuse un paiement Stripe quand il débloque des contenus ou des fonctions numériques dans l'app. La règle 3.1.1 impose l'achat intégré pour débloquer des fonctions : abonnements, monnaies virtuelles, contenus premium, version complète.

• Dans le message : « Guideline 3.1.1 » et In-App Purchase.
• Pourquoi les apps Lovable sont concernées : selon la documentation des paiements de Lovable, à la date d'octobre 2026, Stripe et Paddle sont les seuls prestataires de paiement intégrés. Une offre premium configurée ainsi et conservée dans l'app iOS tombe sous la règle 3.1.1.
• La correction dépend de ce que vous vendez :

Le storefront des États-Unis fait exception : à la date d'octobre 2026, la règle 3.1.1(a) y autorise les boutons ou liens vers d'autres moyens d'achat. La plupart des autres pays, dont la France, ne le permettent pas en dehors d'autorisations spécifiques d'Apple.

Quels problèmes de confidentialité font aussi refuser les apps Lovable ?

Les problèmes de confidentialité qui font aussi refuser les apps Lovable sont une politique de confidentialité absente, des informations App Privacy inexactes et des demandes d'autorisation peu claires. Ils s'ajoutent souvent à l'une des cinq raisons ci-dessus.

• Politique de confidentialité (5.1.1(i)) : un lien est obligatoire dans App Store Connect et dans l'app. La politique doit lister les données collectées et leurs usages, et expliquer la conservation et la suppression.
• Informations App Privacy : selon la page App Privacy d'Apple, vous devez déclarer les données collectées par l'app, y compris via du code tiers (outils d'analyse, SDK), et tenir ces réponses à jour.
• Demandes d'autorisation (5.1.1(ii)) : quand l'app demande l'appareil photo, les photos ou la position, le texte d'explication affiché à l'utilisateur doit décrire clairement et complètement l'usage des données. Un « Cette app a besoin de l'appareil photo » générique est un point faible fréquent quand on ajoute des fonctions natives à la hâte.

Comment répondre à Apple et resoumettre votre app Lovable ?

Pour répondre à Apple, ouvrez la soumission refusée dans App Store Connect, cliquez sur Reply to App Review, expliquez ce que vous avez modifié, puis resoumettez. Selon l'aide App Store Connect :

1. Dans Apps, sélectionnez l'app, puis cliquez sur le lien signalant des problèmes non résolus.
2. Dans la section In Progress, cliquez sur Resolve à côté de la soumission.
3. Cliquez sur Reply to App Review, rédigez votre réponse (4 000 caractères maximum) et joignez des captures d'écran si utile.

Une bonne réponse reprend chaque règle citée et indique où se trouve la correction : « Guideline 5.1.1(v) : la suppression du compte est disponible dans Profil > Réglages > Supprimer mon compte. »

Même build ou nouveau build ? Si le refus portait uniquement sur les métadonnées, vous pouvez resoumettre le même build. Pour la 4.2, les bugs 2.1, la 5.1.1(v), la 4.8 ou la 3.1.1, le problème est dans l'app : envoyez un nouveau build. Apple indique examiner en général 90 % des soumissions en moins de 48 heures.

Faire appel. Si Apple a mal compris votre app, vous pouvez saisir l'App Review Board, une seule fois par soumission refusée (page App Review). Si une fonction manque vraiment, corriger est plus rapide.

Si votre app Lovable devient aussi lente ou instable, voyez Mon app Lovable devient lente ou instable : quand faut-il en sortir ?

Se faire accompagner après un refus Apple

L'offre GUIGUI Tech App refusée par Apple : on la débloque commence par un diagnostic à 500€ HT, réalisé en 2 jours ouvrés : le refus expliqué, l'app testée sur iPhone comme le fait Apple, et un plan écrit avec le prix fixe des correctifs. Les correctifs sont ensuite chiffrés à l'unité, par exemple 500€ HT pour « Se connecter avec Apple » ; le diagnostic est déduit si vous confirmez les correctifs sous 30 jours.

Si votre app Lovable n'est pas encore sur mobile, l'offre Votre app Lovable sur iPhone et Android commence par un diagnostic de faisabilité mobile à 500€ HT (2 jours ouvrés), puis couvre l'emballage, les fonctions mobiles et la soumission aux deux stores, à partir de 8 500€ HT pour 3 à 6 semaines. Pour vérifier que les données de vos utilisateurs sont protégées avant de publier, voyez l'audit de sécurité Lovable (1 200€ HT, 3 jours ouvrés).