Abonnements App Store en 2026 : réussir la validation App Review (règle 3.1.2, paywall, refus)

Pour faire accepter un abonnement à renouvellement automatique sur l’App Store en 2026, votre paywall doit afficher le nom de l’abonnement, sa durée, le prix réellement facturé, ce qu’il inclut et les conditions de l’essai gratuit ; l’app doit renvoyer vers vos conditions d’utilisation (CLUF, ou EULA) et votre politique de confidentialité, et proposer « Restaurer les achats » ; les métadonnées App Store doivent contenir ces deux mêmes liens ; enfin, le premier abonnement se soumet dans la même soumission qu’une version de l’app. Presque tous les refus d’abonnement relèvent de la règle 3.1.2 (informations manquantes) ou de la règle 2.1 (l’examinateur n’a pas trouvé ou pas pu charger vos achats intégrés).

Points clés

• Les fonctions numériques se vendent par achat intégré (3.1.1) ; un abonnement doit durer au moins sept jours, apporter une valeur continue et fonctionner sur tous les appareils de l’utilisateur (3.1.2(a)).
• Le paywall affiche nom, durée, prix facturé (le prix le plus visible), contenu et conditions d’essai, ainsi que les conditions d’utilisation, la politique de confidentialité et « Restaurer les achats ».
• Les liens vers les conditions d’utilisation et la confidentialité sont exigés à deux endroits : dans l’app et dans les métadonnées App Store.
• Le premier abonnement et son groupe partent dans la même soumission qu’une version de l’app, avec une capture et des notes pour App Review.
• App Review achète en sandbox : testez avec StoreKit dans Xcode, puis en sandbox et sur TestFlight, et vérifiez que votre serveur accepte les transactions sandbox.

Les règles qui s’appliquent aux abonnements

Quatre textes décident du sort d’un abonnement. Lisez-les dans le texte : les règles App Review et le guide des abonnements à renouvellement automatique d’Apple sont courts et précis.

Les durées possibles sont fixées par App Store Connect : une semaine, un mois, deux mois, trois mois, six mois ou un an. Un abonnement peut proposer un essai gratuit, à condition de le configurer dans App Store Connect comme offre de lancement : c’est alors l’App Store qui gère l’éligibilité et la facturation.

Ce que le paywall doit afficher

Le guide d’Apple sur les abonnements détaille le contenu de l’écran d’inscription, et l’examinateur le vérifie point par point. Avant le bouton d’achat, affichez :

1. Le nom de l’abonnement et son contenu : fonctions, contenus, stockage, « combien de numéros par mois », pour reprendre l’exemple de la règle 3.1.2(c).
2. La durée de chaque formule et son prix de renouvellement complet, dans la devise locale. Le montant réellement facturé doit être le prix le plus visible : pour une formule annuelle, le prix annuel. Un équivalent « 2,50 € par mois » peut figurer, mais en plus petit et en position secondaire.
3. Les conditions de l’essai gratuit : sa durée et le prix facturé à son terme.
4. Le renouvellement, en termes simples : la formule se renouvelle automatiquement jusqu’à résiliation.
5. Des liens fonctionnels vers vos conditions d’utilisation (CLUF) et votre politique de confidentialité.
6. Un moyen pour les abonnés existants de restaurer leurs achats ou de se connecter.

Ce qui fait refuser un paywall : un bouton de fermeture qui n’apparaît qu’après quelques secondes, un essai présélectionné dont le prix après essai se cache en petits caractères gris, un prix hebdomadaire affiché pour une formule facturée à l’année, ou un bouton « Continuer » qui déclenche un achat sans le dire. La règle 3.1.2(a) est explicite : les apps qui piègent l’utilisateur pour le faire s’abonner sont retirées, et le développeur peut être exclu du programme.

Conditions d’utilisation et confidentialité : dans l’app et dans les métadonnées

C’est le refus 3.1.2 le plus courant. Le message liste deux blocs d’éléments manquants : ce qui doit figurer dans l’app (un lien fonctionnel vers les conditions d’utilisation et un autre vers la politique de confidentialité) et ce qui doit figurer dans les métadonnées App Store (les deux mêmes liens). Les avoir sur le paywall ne suffit pas.

• Confidentialité, côté métadonnées : le champ URL de politique de confidentialité d’App Store Connect, obligatoire de toute façon pour une app iOS.
• Conditions d’utilisation, si vous utilisez le CLUF standard d’Apple : il s’applique par défaut, mais l’examinateur attend tout de même un lien dans la description de l’app. Ajoutez l’URL du CLUF standard d’Apple en fin de description.
• Conditions d’utilisation, si vous avez les vôtres : saisissez-les comme contrat de licence personnalisé dans App Store Connect (Informations sur l’app), et liez le même texte depuis le paywall.

Chaque description de nos apps à abonnement se termine par un court bloc de ce type. Évitez d’y inscrire des prix : ils varient selon le pays, et le paywall les affiche déjà dans la bonne devise.

Fieldnote Pro est un abonnement facultatif à renouvellement automatique (mensuel ou annuel).
Les nouveaux abonnés à la formule annuelle bénéficient d'un essai gratuit de 7 jours.
Le paiement est débité sur votre compte Apple. L'abonnement se renouvelle automatiquement
sauf résiliation au moins 24 heures avant la fin de la période en cours.
Gérez-le ou résiliez-le à tout moment dans les réglages de votre compte Apple.

Conditions d'utilisation : https://www.apple.com/legal/internet-services/itunes/dev/stdeula/
Politique de confidentialité : https://example.com/confidentialite

La politique de confidentialité doit elle-même concorder avec vos réponses « Confidentialité de l’app » et votre manifeste de confidentialité. Si un SDK d’abonnement ou d’analyse est en jeu, lisez notre guide du manifeste de confidentialité iOS avant de déclarer « Données non collectées ».

Configurer l’abonnement dans App Store Connect

Aucun produit ne se charge, même en sandbox, tant que le titulaire du compte n’a pas signé le contrat pour les apps payantes et renseigné fiscalité et banque. Ensuite, dans Monétisation › Abonnements :

1. Créez un groupe d’abonnements avec un nom de référence, puis ajoutez un nom de groupe localisé.
2. Ajoutez chaque abonnement : nom de référence (64 caractères maximum, usage interne), identifiant produit (lettres, chiffres, tirets, points et tirets bas, 100 caractères maximum, jamais réutilisable même après suppression), durée, prix et disponibilité.
3. Localisez-le : un nom affiché de 2 à 30 caractères et une description de 45 caractères maximum, dans chaque langue de l’app.
4. Remplissez les informations pour App Review : une capture qui montre clairement ce qui est vendu (votre paywall, dans une taille prise en charge par l’app ; elle n’apparaît jamais sur l’App Store) et des notes de 4 000 caractères maximum.
5. En option, ajoutez une image promotionnelle de 1024 × 1024 pixels (nécessaire pour mettre l’abonnement en avant sur votre fiche ou utiliser les offres de reconquête), et configurez vos offres.
6. Soumettez-le avec le binaire. Le premier abonnement à renouvellement automatique doit être soumis avec une nouvelle version de l’app, et tout nouvel abonnement avec son groupe. Ajoutez la version, le groupe et chaque abonnement à la même soumission en brouillon avant de cliquer sur « Soumettre pour vérification ». Une fois le premier approuvé, les suivants peuvent partir sans nouvelle version.

Groupes d’abonnements et niveaux

Un client ne peut détenir qu’un abonnement par groupe à la fois : c’est ainsi qu’Apple applique la règle 3.1.2(b). Placez les formules mensuelle et annuelle d’un même service dans un seul groupe ; la plupart des apps n’en ont besoin que d’un. Classez les formules par niveau de service (le niveau 1 est le plus élevé). Une montée en gamme prend effet immédiatement, avec remboursement au prorata ; une descente prend effet au prochain renouvellement ; un changement entre formules de même niveau est immédiat si les durées sont identiques, sinon au prochain renouvellement. Deux groupes pour les mêmes fonctions, c’est le moyen sûr de faire payer deux fois l’utilisateur, et l’examinateur le relève.

Nouveauté 2026 : depuis le 27 avril 2026, un abonnement d’un an peut aussi proposer une facturation mensuelle avec engagement de 12 mois, pour les clients sous iOS 26.4 ou ultérieur, partout sauf aux États-Unis et à Singapour. Si vous l’activez, le paywall doit rendre l’engagement aussi lisible que la mensualité.

Offres de lancement, offres promotionnelles et codes d’offre

Pour App Review, l’essentiel est l’information. Si votre paywall annonce « 7 jours gratuits », vérifiez d’abord l’éligibilité avec product.subscription?.isEligibleForIntroOffer : un ancien abonné qui a déjà profité de l’essai sera débité tout de suite, et lui promettre un essai gratuit serait trompeur. Affichez le prix après l’offre à côté de chaque offre.

Construire le paywall avec StoreKit 2

La voie la plus rapide vers un paywall conforme est SubscriptionStoreView (iOS 17 et ultérieur). Cette vue affiche les noms, descriptions et prix localisés issus d’App Store Connect, ainsi que des boutons vers les conditions d’utilisation et la politique de confidentialité, que vous pouvez faire pointer vers vos propres pages :

SubscriptionStoreView(groupID: "YOUR_GROUP_ID") {
    PaywallHeader() // nom + contenu de l'abonnement
}
.storeButton(.visible, for: .restorePurchases)
.subscriptionStorePolicyDestination(url: termsURL, for: .termsOfService)
.subscriptionStorePolicyDestination(url: privacyURL, for: .privacyPolicy)

Avec un paywall sur mesure, la logique reste courte : charger les produits, lire les droits actifs dans Transaction.currentEntitlements, écouter Transaction.updates dès le lancement, et n’appeler AppStore.sync() que sur un appui explicite sur « Restaurer » (l’utilisateur doit s’authentifier) :

import StoreKit

@MainActor
final class Store: ObservableObject {
    @Published var products: [Product] = []
    @Published var isPro = false
    @Published var loadFailed = false

    func load() async {
        do {
            products = try await Product.products(for: ["com.example.pro.yearly",
                                                        "com.example.pro.monthly"])
            loadFailed = products.isEmpty
        } catch {
            loadFailed = true // bouton « Réessayer », jamais de paywall vide
        }
        await refreshEntitlements()
    }

    func refreshEntitlements() async {
        var active = false
        for await result in Transaction.currentEntitlements {
            if case .verified(let transaction) = result,
               transaction.revocationDate == nil {
                active = true
            }
        }
        isPro = active
    }

    func restore() async {
        try? await AppStore.sync() // uniquement sur action de l'utilisateur
        await refreshEntitlements()
    }
}

Deux détails comptent pour la validation. Une liste de produits vide doit produire un message d’erreur visible avec un bouton pour réessayer, pas un écran blanc que l’examinateur signalera comme « achats intégrés introuvables ». Et proposez showManageSubscriptions(in:) dans vos réglages, pour que l’abonné puisse résilier ou changer de formule sans quitter l’app.

Tester : Xcode, sandbox, TestFlight et environnement de vérification

• StoreKit Testing dans Xcode. Un fichier de configuration .storekit, local ou synchronisé avec App Store Connect (Xcode 14 et ultérieur), permet de tester achats, essais, renouvellements, remboursements et échecs dans le simulateur, hors ligne, avant même d’avoir créé les produits. Voir Setting up StoreKit Testing in Xcode.
• Sandbox. Créez des comptes Apple sandbox dans App Store Connect et connectez-vous dans Réglages › Développeur sur l’appareil. Les réglages sandbox permettent de modifier la cadence de renouvellement, d’effacer l’historique d’achat (le compte redevient éligible aux offres de lancement) et de tester les achats interrompus. Une modification des métadonnées peut mettre jusqu’à une heure à atteindre la sandbox.
• TestFlight. Les builds TestFlight utilisent toujours la sandbox pour les achats intégrés : les testeurs ne sont jamais débités. Notre guide TestFlight détaille groupes, vérification bêta et expiration des builds.
• App Review. Le build examiné est signé pour la production et dialogue avec vos serveurs de production, mais les achats passent par l’environnement de test de l’App Store. Si votre serveur valide les transactions, il doit accepter celles de la sandbox : avec l’App Store Server API, lisez l’environnement de la transaction et interrogez l’adresse sandbox pour les transactions sandbox.

Les refus d’abonnement fréquents et leurs correctifs

Pour un problème de métadonnées seulement, comme un lien manquant dans la description, inutile d’envoyer un nouveau build : modifiez la description et répondez dans App Store Connect. Pour tout ce qui touche au binaire, corrigez, incrémentez le numéro de build et soumettez à nouveau avec une courte note sur ce qui a changé. Notre checklist de soumission App Store couvre le reste du processus.

Liens d’achat externes aux États-Unis : ce qui a changé

Depuis mai 2025, à la suite d’une décision de justice américaine dans l’affaire Epic Games contre Apple, les règles 3.1.1(a) et 3.1.3 n’interdisent plus, sur la vitrine des États-Unis, les boutons, liens externes ou autres incitations vers d’autres moyens de paiement. Ailleurs, un lien sortant exige toujours l’un des droits (entitlements) qu’Apple accorde selon les pays. Le contentieux se poursuit en 2026 (Apple l’a porté devant la Cour suprême des États-Unis), et ces conditions peuvent encore évoluer. Retenez surtout deux choses : l’achat intégré reste obligatoire pour les fonctions numériques sur toutes les vitrines, donc votre abonnement StoreKit et ses mentions passent toujours par App Review ; et un lien externe s’ajoute à l’achat intégré, il ne le remplace pas.

Checklist avant soumission

• Paywall : nom, contenu, durée et prix facturé de chaque formule ; durée de l’essai et prix ensuite ; mention du renouvellement ; liens vers les conditions et la confidentialité ; « Restaurer les achats ».
• Métadonnées : lien vers les conditions d’utilisation dans la description ou CLUF personnalisé ; URL de confidentialité ; description cohérente avec les formules de l’app.
• App Store Connect : contrat pour les apps payantes actif ; noms et descriptions localisés ; prix et disponibilité ; capture et notes pour App Review ; abonnements dans la même soumission que la version.
• Tests : achat, essai, changement de formule, restauration et résiliation en sandbox ; installation propre via TestFlight ; serveur qui accepte la sandbox ; paywall accessible en quelques gestes.

Comment Develak gère la validation des abonnements

Develak publie plus de 30 apps sur l’App Store, dont beaucoup sont gratuites au téléchargement avec un abonnement facultatif. Pillio, notre rappel de médicaments, en est un exemple : une formule mensuelle et une formule annuelle avec essai gratuit de 7 jours, exactement le type de paywall où les conditions d’essai et le prix facturé doivent être sans ambiguïté. Lors de nos soumissions, nous confrontons le paywall à la liste ci-dessus, terminons la description par les liens vers les conditions et la confidentialité, joignons le paywall comme capture pour App Review et indiquons dans les notes comment l’atteindre.

Vous lancez un produit à abonnement ? Notre offre de développement de MVP inclut le paywall StoreKit 2, la configuration App Store Connect et la première validation. Pour une app déjà publiée, notre service de maintenance d’application iOS tient paywall, SDK et métadonnées à jour des règles d’Apple. Nul ne peut garantir une validation, puisque seule Apple décide, mais ces contrôles éliminent les refus évitables.

Questions fréquentes