Paywall iOS : 7 erreurs de débutant qui bloquent tes ventes

Pourquoi ton paywall iOS ne vend pas

Ton application est sur l'App Store, les installations arrivent, et pourtant presque personne ne s'abonne. Dans la plupart des cas, le problème n'est ni ton idée ni ton code : c'est ton paywall iOS, l'écran qui présente l'offre payante et demande à l'utilisateur de s'engager. Un paywall montré au mauvais moment, sans essai gratuit, sans bouton de restauration ou sans les mentions qu'Apple exige ne vend pas, ou se fait refuser à la revue.

Voici les 7 erreurs que je vois le plus souvent sur une première app, et comment corriger chacune. Pas de recette magique : des réglages concrets, vérifiables, que tu peux appliquer avant ton prochain envoi à Apple.

Je publie mes propres apps iOS à abonnement : Solys, un réveil à mini-jeux, et TradaZen, un simulateur de trading, toutes les deux branchées sur RevenueCat. Sur les deux, j'ai vécu la même situation : beaucoup d'installations, très peu d'essais gratuits démarrés. Le produit n'était pas en cause. Le paywall et l'onboarding ne menaient pas assez clairement à l'essai. C'est une des raisons qui m'ont poussé à les retravailler en profondeur, et c'est de là que vient cette liste.

Erreur n°1 : montrer le paywall trop tôt, ou trop tard

C'est l'erreur la plus coûteuse, et elle se présente dans les deux sens.

Trop tôt, c'est le paywall qui s'affiche avant que l'utilisateur ait compris ce que fait l'app. Il ouvre l'app, voit un prix, ferme. Il n'a aucune raison de payer puisqu'il n'a encore rien vu.

Trop tard, c'est le paywall caché derrière un bouton « Premium » dans les réglages, ou qui n'apparaît qu'au bout de plusieurs jours d'usage. La plupart des utilisateurs ne le verront jamais. Or un utilisateur qui ne voit pas ton offre ne peut pas s'abonner.

Le bon moment se situe entre les deux : à la fin de l'onboarding, juste après que l'utilisateur a perçu la valeur de l'app. Il a répondu à quelques questions, il a vu ce que l'app va faire pour lui, il a peut-être testé la fonction principale. C'est là que l'offre a du sens.

Concrètement :

• l'onboarding pose des questions utiles et montre un aperçu du résultat ;
• le paywall arrive à la fin de ce parcours, pas au milieu ;
• tu peux le remontrer plus tard, à un moment où l'utilisateur touche une limite de la version gratuite. Si tu rends payante une fonction jusque-là gratuite, lis d'abord le guide de la guideline 3.2.2.

Erreur n°2 : ne pas proposer d'essai gratuit

Pour une app que personne ne connaît encore, demander de payer tout de suite est un gros saut. L'essai gratuit réduit ce saut : l'utilisateur teste sans risque, et le paiement ne démarre qu'à la fin de la période d'essai s'il ne résilie pas.

Apple prévoit ce mécanisme sous le nom d'offre de lancement (introductory offer) pour les abonnements auto-renouvelables. Deux règles à retenir, tirées de la page d'Apple sur les abonnements :

• un client ne peut profiter que d'une seule offre de lancement par groupe d'abonnements ;
• dans le parcours d'achat, tu dois indiquer clairement la durée de l'essai et le prix facturé une fois l'essai terminé.

L'erreur fréquente, c'est de proposer un essai sans le dire. Si ton bouton affiche seulement « S'abonner », l'utilisateur ne sait pas qu'il peut essayer gratuitement. Écris-le en toutes lettres sur le bouton ou juste au-dessus : durée de l'essai, puis prix. C'est exactement le genre de détail qui fait la différence entre des installations qui dorment et des essais qui démarrent.

Erreur n°3 : mal mettre en avant l'abonnement annuel

Beaucoup de premières apps proposent un mensuel et un annuel, mais les présentent comme deux options identiques, côte à côte, sans hiérarchie. Résultat : l'utilisateur hésite, et un utilisateur qui hésite ferme souvent l'écran.

L'annuel a pourtant des avantages pour toi comme pour l'utilisateur : un prix mensuel équivalent plus bas pour lui, un engagement plus long pour toi. Pour le mettre en valeur honnêtement :

• présélectionne-le et donne-lui une présentation visuelle distincte ;
• affiche l'équivalent mensuel à côté du prix annuel, pour que la comparaison soit immédiate ;
• indique l'économie réelle par rapport au mensuel, calculée sur tes vrais prix, jamais sur un prix de référence inventé.

Attention à ne pas tomber dans l'excès inverse : le prix réellement facturé doit rester le plus visible. Apple demande que le prix de renouvellement complet soit affiché de façon claire et visible. Un équivalent mensuel en gros et le vrai prix annuel en tout petit, c'est un paywall trompeur, et c'est un motif de refus au titre de la guideline 3.1.2.

Erreur n°4 : oublier le bouton de restauration d'achat

C'est l'oubli le plus bête et l'un des plus fréquents. Un abonné change d'iPhone, réinstalle l'app, et se retrouve devant le paywall alors qu'il paie déjà. Sans bouton « Restaurer mes achats », il n'a aucun moyen de récupérer son accès.

Ce n'est pas une option. Les règles de revue de l'App Store (règle 3.1.1) demandent un mécanisme de restauration pour tout achat intégré restaurable, et la page d'Apple sur les abonnements liste parmi les éléments de l'écran d'inscription « un moyen pour les abonnés actuels de se connecter ou de restaurer leurs achats ».

Avec RevenueCat, la restauration tient en un appel. Le vrai travail, c'est de vérifier ce qui se passe ensuite :

• l'abonné retrouve bien son accès, sans avoir à relancer l'app ;
• un utilisateur sans achat reçoit un message clair, pas une erreur technique ;
• le bouton est visible sur le paywall lui‑même, pas seulement dans les réglages.

Erreur n°5 : oublier les mentions qu'Apple exige

Un paywall qui ne dit pas clairement ce que l'utilisateur va payer peut être refusé. Apple détaille sur sa page consacrée aux abonnements ce qui doit figurer sur l'écran d'inscription :

• le nom et la durée de l'abonnement, et ce qu'il donne pendant cette période ;
• le prix de renouvellement complet, affiché clairement et localisé dans les devises disponibles ;
• un moyen de restaurer ses achats (voir l'erreur précédente).

Ajoute une phrase explicite sur le renouvellement automatique : l'abonnement se renouvelle tant que l'utilisateur ne le résilie pas, et il peut le résilier dans les réglages de son compte Apple.

La même page précise aussi que l'app et ses métadonnées App Store doivent contenir des liens vers les conditions d'utilisation et la politique de confidentialité. C'est un point que beaucoup découvrent au moment du refus : il ne suffit pas de mettre ces liens dans l'app, il faut aussi un rappel des conditions de l'abonnement et ces deux liens dans la description de la fiche App Store. Sans eux, c'est un refus au titre de la règle 3.1.2. Sur mes apps à abonnement, je termine la description par un court bloc : conditions de l'abonnement, puis lien vers les conditions d'utilisation et lien vers la politique de confidentialité. Et si ta fiche est traduite, ce bloc doit exister dans chaque langue.

Avant de coller tes liens, ouvre-les dans un navigateur. Un lien vers une page qui n'existe pas vaut un lien absent.

J'ai détaillé les autres motifs de refus qui reviennent souvent dans cet article sur les refus d'Apple, et la fiche App Store elle‑même a sa page : optimiser sa fiche sur l'App Store.

Erreur n°6 : ne pas tester le paywall en bac à sable

Un paywall qui s'affiche bien sur le simulateur n'est pas un paywall qui fonctionne. Entre la configuration des produits dans App Store Connect, les offres dans RevenueCat et le code de l'app, il y a beaucoup d'endroits où un détail peut casser : un produit mal rattaché, un prix qui ne se charge pas, un essai qui ne s'affiche pas.

Apple fournit pour ça un environnement de test, le bac à sable (sandbox), avec des comptes Apple de test que tu crées dans App Store Connect, dans « Utilisateurs et accès », onglet Sandbox. Ces comptes servent à tester les achats sans être débité, y compris les renouvellements, les échecs de paiement et les remboursements, comme l'explique la documentation d'App Store Connect.

Avant chaque envoi, déroule au minimum ce parcours sur un vrai iPhone :

1. premier lancement, onboarding complet, arrivée sur le paywall ;
2. démarrage de l'essai avec un compte de test ;
3. vérification que l'accès premium s'ouvre bien ;
4. suppression de l'app, réinstallation, restauration de l'achat ;
5. affichage correct du paywall sur le plus petit et le plus grand iPhone que tu supportes.

Le reviewer d'Apple testera lui aussi l'achat. S'il bloque, c'est un refus.

Erreur n°7 : ne rien mesurer

C'est l'erreur qui empêche de corriger toutes les autres. Sans mesure, tu ne sais pas où les utilisateurs décrochent. Tu vois seulement le résultat final : peu d'abonnés. Tu ne sais pas si le problème est l'onboarding, le paywall, le prix ou l'essai.

C'est exactement ce qui m'a permis de voir le problème sur mes propres apps : les installations étaient là, les essais démarrés non. Sans ces deux chiffres côte à côte, j'aurais pu passer des semaines à retravailler autre chose.

Pose des événements d'analytics à chaque étape clé, par exemple avec PostHog :

• début de l'onboarding ;
• fin de l'onboarding ;
• affichage du paywall ;
• essai démarré ;
• achat ou abonnement confirmé ;
• restauration réussie.

Avec ces événements, tu obtiens un entonnoir. Tu vois l'étape où les utilisateurs partent, et tu sais quoi retravailler en priorité. RevenueCat complète la vue côté revenus : essais, conversions, renouvellements, résiliations.

Un dernier conseil : ne change pas tout en même temps. Si tu modifies le prix, l'essai et le design du paywall le même jour, tu ne sauras jamais ce qui a fait bouger les chiffres.

La checklist paywall avant ton prochain envoi

• Le paywall arrive à la fin de l'onboarding, après une preuve de valeur.
• L'essai gratuit est affiché en clair : durée, puis prix après l'essai.
• L'annuel est mis en avant honnêtement, le prix réellement facturé reste lisible.
• Le bouton « Restaurer mes achats » est sur le paywall et fonctionne.
• Nom, durée, prix de renouvellement et renouvellement automatique sont indiqués.
• Les liens vers les conditions d'utilisation et la politique de confidentialité sont dans l'app et dans la description App Store, dans chaque langue.
• Le parcours d'achat complet a été testé en bac à sable sur un vrai iPhone.
• Les événements d'analytics couvrent chaque étape, de l'onboarding à l'achat.

Si tu hésites encore sur le modèle lui‑même, abonnement ou paiement unique, j'ai écrit un guide dédié : abonnement ou achat unique pour ta première app iOS. Et pour la partie technique complète, produits, RevenueCat et validation, tout est sur la page abonnements in-app iOS.

Construire ton paywall avec le Kit iOS

Le paywall n'est qu'une pièce. Il dépend de l'onboarding qui le précède, du prix que tu fixes, de la fiche App Store qui amène les utilisateurs, et de la fonction principale de l'app, celle qu'il faut garder simple dans une première version bien cadrée.

Si tu veux partir d'une base prête, l'onboarding, le paywall et les abonnements sont déjà dans le code de départ du Kit iOS, et la troisième étape de son parcours sert à les brancher sur ta propre app. Personne ne peut te garantir un revenu.

Avant l'envoi, les skills Claude Code du Kit Review Apple relisent ton paywall et les mentions qu'Apple exige. Et l'accueil montre comment lancer ton application mobile avec ce paywall déjà branché.

Questions fréquentes

Quelles erreurs de paywall iOS bloquent les ventes d'une première app ?

Sept erreurs reviennent sur une première app : un paywall montré trop tôt ou trop tard, pas d'essai gratuit, un abonnement annuel mal mis en avant. Viennent ensuite un bouton de restauration oublié, des mentions qu'Apple exige absentes, un paywall jamais testé en bac à sable et aucune mesure. Chacune se corrige par un réglage concret, à vérifier avant ton prochain envoi à Apple.

Quand afficher le paywall dans une app iOS ?

À la fin de l'onboarding, juste après que l'utilisateur a perçu la valeur de l'app. Trop tôt, il voit un prix sans avoir compris ce que fait l'app. Trop tard, par exemple derrière un bouton « Premium » dans les réglages, la plupart des utilisateurs ne le verront jamais. Tu peux le remontrer plus tard, quand l'utilisateur touche une limite de la version gratuite.

Que doit afficher un paywall iOS pour respecter les règles d'Apple ?

Apple demande sur l'écran d'inscription le nom et la durée de l'abonnement, ce qu'il donne, le prix de renouvellement complet affiché clairement et un moyen de restaurer ses achats. Il faut aussi des liens vers les conditions d'utilisation et la politique de confidentialité, dans l'app et dans la description de ta fiche App Store. Sans eux dans la description, c'est un refus. Ajoute une phrase explicite sur le renouvellement automatique.

Faut-il proposer un essai gratuit dans une app iOS ?

Oui, surtout pour une app que personne ne connaît encore : demander de payer tout de suite est un gros saut, et l'essai permet de tester sans risque. Apple appelle ça une offre de lancement, limitée à une par groupe d'abonnements pour un même client. Écris la durée de l'essai puis le prix facturé ensuite sur le bouton ou juste au-dessus.

Comment mettre en avant l'abonnement annuel sans tromper l'utilisateur ?

Présélectionne l'annuel, donne-lui une présentation visuelle distincte et affiche son équivalent mensuel à côté du prix annuel. Indique l'économie réelle par rapport au mensuel, calculée sur tes vrais prix, jamais sur un prix de référence inventé. Ne cache pas le vrai prix : un équivalent mensuel en gros et le prix annuel en tout petit, c'est un paywall trompeur et un motif de refus.

Comment tester un paywall iOS avant l'envoi à Apple ?

Avec le bac à sable (sandbox) d'Apple : des comptes de test, créés dans App Store Connect, qui permettent d'acheter sans être débité. Sur un vrai iPhone, déroule le parcours complet : onboarding, démarrage de l'essai, accès premium, puis suppression de l'app, réinstallation et restauration de l'achat. Vérifie aussi l'affichage sur le plus petit et le plus grand iPhone que tu supportes.