Refus App Store
Votre app web encaisse via Stripe, et c'est parfait sur le web. Dans l'app iOS, Apple exige l'achat intégré (In-App Purchase) pour tout ce qui est numérique et utilisé dans l'app. La solution n'est pas d'arracher Stripe : il suffit de laisser le build iOS utiliser StoreKit via RevenueCat pendant que le web garde Stripe.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Si votre app débloque des fonctionnalités, du contenu ou des services consommés dans l'app (abonnements, formules premium, crédits IA, modèles, cours), cet achat doit passer par l'achat intégré. La guideline interdit aussi, dans l'app, les boutons, liens et formulations qui orientent les utilisateurs vers un autre moyen de payer ces éléments numériques. Apple l'applique storefront par storefront, et des exceptions régionales existent (voir plus bas), mais pour une petite app la règle pratique est simple : dans l'app iOS, les biens numériques passent par l'achat intégré.
Les modèles Lovable, Bolt et v0 branchent Stripe Checkout par défaut, et l'IA place volontiers un bouton « Passer à Pro pour 9 €/mois » sur la page des tarifs. L'examinateur le touche, voit un formulaire Stripe et rédige le refus 3.1.1. Votre modèle économique n'a rien de faux ; c'est le canal de paiement dans l'app qui pose problème.
| Ce que vous vendez | Dans l'app iOS | Guideline |
|---|---|---|
| Abonnement aux fonctionnalités de l'app, formule premium | Achat intégré obligatoire | 3.1.1 |
| Crédits IA, tokens, générations | Achat intégré obligatoire (consommable) | 3.1.1 |
| Modèles, e-books, cours utilisés dans l'app | Achat intégré obligatoire | 3.1.1 |
| Biens physiques et services utilisés hors de l'app (produits expédiés, livraison de repas, une intervention de ménage) | Stripe ou tout autre prestataire autorisé ; l'achat intégré ne doit pas être utilisé | 3.1.3(e) |
| Services individuels en temps réel entre deux personnes (cours particuliers, consultations) | Autres moyens de paiement autorisés ; les services d'une personne vers plusieurs doivent passer par l'achat intégré | 3.1.3(d) |
| Contenu acheté sur le web et seulement consulté dans l'app (apps de type « lecteur » : livres, audio, vidéo, presse) | Peut être débloqué sans achat intégré ; aucun bouton d'achat dans l'app ni lien pour acheter ailleurs | 3.1.3(a) |
Stripe reste sur le web ; l'app appelle un seul schéma d'URL.
Signez l'accord Paid Apps (en tant que titulaire du compte), puis ajoutez l'abonnement ou le consommable avec un identifiant comme pro_monthly. Ajoutez un testeur sandbox dans Users and Access pour vos tests.
Créez un projet RevenueCat, importez les produits, puis collez la clé et l'ID du projet dans revenueCatAPIKey et revenueCatProjectID dans Config.swift. Le Bundle ID doit être identique dans Xcode, App Store Connect et RevenueCat. Guide complet : configurer RevenueCat pour les apps web encapsulées et la documentation sur les achats intégrés.
Réglez useragent_iphone dans Config.swift sur le user agent par défaut suivi d'un marqueur comme MyAppiOS, puis testez navigator.userAgent dans votre app web. Dans l'app, remplacez le bouton Stripe par un lien vers revenuecat://purchase?external_id=USER_ID&product=pro_monthly, ou ouvrez un paywall natif avec revenuecat://launchPaywall?external_id=USER_ID&offering=default (iOS 15 ou ultérieur).
Utilisez les webhooks RevenueCat (ou les variables injectées planID et transactionIdentifier) pour enregistrer la formule sur la fiche utilisateur dans Supabase ou Firebase : le même compte est ainsi premium sur le web comme dans l'app.
Un lien « Restaurer les achats » bien visible vers restoreinapppurchases:// et un lien « Gérer l'abonnement » vers cancelinapppurchase://, qui ouvre la gestion des abonnements d'Apple. Les examinateurs s'attendent aux deux.
Pas de « moins cher sur notre site », pas de portail de facturation Stripe, pas d'e-mail « passez à Pro sur votredomaine.com » déclenché depuis l'app, pas de page de tarifs qui compare les deux. Envoyez ensuite un nouveau build et répondez dans le Resolution Center en indiquant les identifiants des produits.
Mon WebView iOS est enfin approuvé. Merci !!
Le web garde Stripe ; le build iOS passe par RevenueCat. L'app est détectée grâce au marqueur ajouté au user agent.
// Config.swift : useragent_iphone = UA par défaut + " MyAppiOS"
var isIosApp = navigator.userAgent.indexOf("MyAppiOS") !== -1;
function buy(productId, userId) {
if (isIosApp) {
// StoreKit via RevenueCat dans l'app WebViewGold
window.location.href = "revenuecat://purchase?external_id=" + encodeURIComponent(userId) + "&product=" + productId;
} else {
// Stripe Checkout sur le web
window.location.href = "/checkout?plan=" + productId;
}
}Les règles varient selon la région. Aux États-Unis, à la suite d'une décision de justice de 2025, les apps du storefront américain peuvent renvoyer vers des options d'achat externes ; l'Union européenne prévoit des conditions alternatives dans le cadre du Digital Markets Act ; ailleurs, la règle classique s'applique. Ces règles évoluent et s'accompagnent de leurs propres obligations d'information : vérifiez le texte actuel d'Apple avant de vous y fier. Pour une app gérée par une seule personne, l'achat intégré via RevenueCat passe l'examen sur tous les storefronts avec le moins de paperasse ; consultez le guide de décision Stripe ou achat intégré pour l'aspect business.
Oui, c'est la configuration normale. Le même compte reçoit le droit d'accès par l'un ou l'autre canal ; votre backend traite un webhook RevenueCat exactement comme un webhook Stripe.
Masquer l'achat est autorisé pour les contenus de type « lecteur », mais inviter les utilisateurs, dans l'app, à aller sur le site ne l'est pas. Si l'app elle-même n'a rien à vendre et ne renvoie jamais ailleurs, les examinateurs l'acceptent généralement ; la plupart des apps s'en sortent toutefois mieux en ajoutant l'achat intégré.
Oui. Des crédits dépensés dans l'app sont du contenu numérique. Créez-les comme achats intégrés consommables et créditez le solde sur votre backend à l'arrivée du webhook RevenueCat.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.