Table des matières
Apple prend généralement une commission de 30 % sur les apps payantes et les achats in-app, ce qui peut réduire considérablement les revenus des développeurs indépendants. (Les apps gratuites ne paient pas de commission.) Ce taux standard s'applique à la plupart des transactions numériques dans les apps iOS, ce qui rend difficile la réalisation d'une plus-value pour les petits développeurs. Heureusement, Apple et les autorités de régulation ont mis en place des moyens pour réduire cette réduction. Dans cet article, nous expliquons le modèle de commission d'Apple, décrivons les allègements approuvés par Apple (comme le Small Business Program) et explorons des solutions de contournement pratiques - des contrôles Web basés sur Stripe aux Progressive Web Apps (PWA) et aux modèles d'abonnement purement Web. Nous examinons les avantages et les inconvénients de chaque approche (résumés dans le tableau ci-dessous), les implications juridiques et la conformité réglementaire, et donnons des conseils sur la manière de rester dans les bonnes grâces d'Apple tout en maximisant les revenus.
Traduit avec DeepL.com (version gratuite)
La commission 30% d'Apple et ses conséquences
Par défaut, l'App Store prélève une taxe de 30 % sur toutes les applications payantes et tous les biens numériques vendus via des achats intégrés (IAP). Par exemple, pour une vente d'app d'une valeur de 10 dollars, le développeur ne reçoit que 7 dollars. Cette "taxe Apple" de 30 pour cent s'applique également aux abonnements, bien qu'Apple l'ait réduite à 15 pour cent pour les abonnements récurrents après la première année. La commission s'applique dans le monde entier, que votre application soit vendue comme un achat unique ou comme un abonnement. Pour les petites apps, la perte de 30 % peut être dévastatrice.
La commission d'Apple est élevée pour le secteur (les normes du secteur se situent plutôt entre 10 et 20 % pour le traitement des paiements). Les rapporteurs tech font référence aux marges "supracompétitives" d'Apple, et les développeurs se sont longtemps insurgés contre cette commission. La plainte d'Epic Games et la pression des autorités de régulation du monde entier (UE, Japon, Corée du Sud) reflètent ces tensions. Pour de nombreux développeurs indépendants, trouver un moyen de conserver ces 15-30 % sur les ventes peut faire la différence entre le succès et l'échec d'un projet.
Programme d'Apple pour les petites entreprises (15%)
Pour aider les petits développeurs, Apple a introduit en janvier 2021 l'App Store Small Business Program (SBP). Ce programme permet aux développeurs qualifiés de ne payer qu'une commission de 15% sur les ventes. Les principales conditions sont les suivantes :
- seuil de chiffre d'affaires : Vous (et tous les comptes de développeur associés) devez avoir généré ≤ 1 million de dollars de revenus App Store (moins les commissions et les taxes d'Apple) au cours des 12 mois précédents et rester en dessous de 1 million de dollars pour l'année en cours. Si vous dépassez 1 million de dollars au cours d'une année, votre taux sera réinitialisé à 30 % pour le reste de l'année et vous ne pourrez pas vous qualifier à nouveau pour 15 % tant que vous ne serez pas passé sous ce seuil au cours d'une année ultérieure.
- Éligibilité : Presque tous les développeurs d'applications qui vendent des biens numériques sont éligibles s'ils sont en dessous du seuil de chiffre d'affaires. Cela vaut également pour les nouveaux développeurs qui n'ont pas encore réalisé de ventes (les nouveaux venus bénéficient immédiatement de l'avantage 15 %).
- Inscription : Pour participer au SBP, le titulaire du compte doit accepter l'accord "Paid Apps" d'Apple et répertorier tous les comptes de développeurs associés dans l'App Store Connect. Il n'y a pas de frais ni de demande compliquée - il suffit de s'inscrire via App Store Connect dès que l'on est qualifié. Apple appliquera alors automatiquement le taux de 15 % à vos ventes 15 jours après votre inscription.
Le taux SBP est d'une grande aide pour les développeurs individuels et les petits studios. Par rapport aux 30 % habituels, le paiement de 15 % sur les premiers 1 million de dollars de chiffre d'affaires double effectivement vos revenus. (Le communiqué de presse d'Apple précise que cela s'applique à "la grande majorité des développeurs qui vendent des produits numériques"). Le seul inconvénient est la limite du chiffre d'affaires. Si votre application dépasse rapidement 1 million de dollars, vous vous retrouverez à nouveau à 30 %, à moins que vous ne puissiez diviser le chiffre d'affaires ou utiliser plusieurs comptes.
Tableau : comparaison des stratégies de réduction des commissions
| Stratégie | Avantages | Inconvénients |
|---|---|---|
|
Achat in-app Apple - Programme Small Biz (15%)
|
Commission réduite (15 % contre 30 %) sur les ventes qualifiées- Flux d'achat sans faille dans le store géré par Apple (paiement, fraude, taxes)- Accès à la portée et à la confiance dans l'App Store |
Vous continuez à payer une taxe de 15 % sur toutes les ventes in-app - Vous devez réaliser un chiffre d'affaires inférieur à 1 million de dollars/an - Vous êtes soumis aux politiques d'audit et de remboursement d'Apple |
|
Achats in-app Apple - Standard (30%) |
Accès complet à l'App Store, aucune restriction sur les contenus/modèles in-app- Apple prend en charge l'ensemble du traitement des paiements, de la sécurité et des taxes |
La commission élevée de 30 % réduit le bénéfice - Contrôle limité sur l'UX de la caisse - Le taux d'abonnement ne baisse qu'après la première année d'un abonné à 15 % (pour les abonnements) |
|
Paiements externes sur le web (Stripe, etc.) |
Les développeurs reçoivent jusqu'à 97 % du chiffre d'affaires (Stripe prend 2,9 % + 0,30 $ contre 30 % pour Apple) - Contrôle total du flux de caisse, des prix et des promotions - Solution de paiement unifiée pour le web et le mobile (UX multiplateforme) |
Vous devez mettre en place et gérer votre propre infrastructure de paiement (gestion des rejets de débit, des remboursements, de la fraude, de la TVA, etc.) - Conformité PCI requise et charge de travail supplémentaire pour le support client - Dépend de l'évolution de la politique d'Apple en matière de liens externes (encore en cours de développement) |
|
Application web progressive (PWA) |
Pas d'App Store impliqué - pas de frais Apple pour les transactions- Mises à jour instantanées (pas de délai de vérification), fonctionne sur toutes les plateformes- Relation et analyse directes avec les utilisateurs (e-mail, push, etc.) |
Prise en charge iOS limitée (navigateur Safari uniquement ; certaines fonctionnalités natives sont manquantes)- Non répertorié dans l'App Store (la découverte est plus difficile ; pas de trafic de recherche dans l'App Store)- API historiquement limitées (iOS a récemment ajouté les notifications PWA push dans 16.4, mais toujours plus limitées que natives)
|
Utilisation de paiements web externes (par exemple Stripe)
La récente décision de justice dans l'affaire Epic contre Apple a changé la donne. En mai 2025, un tribunal américain a ordonné à Apple de ne plus empêcher les développeurs de créer des liens vers des options d'achat externes et de ne plus demander de commissions pour les ventes effectuées en dehors de l'application. Dans la pratique, cela signifie
Pas de frais Apple pour les ventes externes : Pour tout achat effectué via un site web ou une caisse web en dehors de l'application, les frais Apple de 30 % (ou 15 %) ne peuvent pas être prélevés. Les développeurs conservent 100 % de ces recettes (moins les frais du prestataire de services de paiement).
Liberté de créer des liens : Apple doit désormais autoriser les applications de l'App Store américain à contenir des boutons ou des invitations à agir qui dirigent l'utilisateur vers une page de paiement externe. (Apple a mis à jour ses directives pour tenir compte explicitement de ce point). Il est important de noter qu'il est interdit à Apple d'imposer des avertissements en pleine page ou des "écrans d'horreur" lorsqu'un utilisateur suit un tel lien.
Mise en œuvre technique : Vous pouvez donc intégrer un service tel que Stripe pour traiter les paiements sur Internet. La documentation de Stripe (et le reportage de TechCrunch) explique l'approche : votre application contient un lien ou un bouton qui ouvre Stripe Checkout dans une vue web sécurisée ou un navigateur, l'utilisateur y finalise le paiement et retourne ensuite à votre application. En pratique, vous générez une URL Stripe Checkout unique sur votre serveur (ou à l'aide du SDK de Stripe) et ouvrez cette URL dans l'application. Une fois le paiement effectué, vous le vérifiez dans votre backend et activez le contenu de l'application pour l'utilisateur.
Stripe a même publié un guide pour les développeurs iOS afin de mettre cela en place. TechCrunch rapporte que le PDG de Stripe, Michael Luo, a qualifié de "grande nouvelle" le fait que les développeurs puissent désormais "accepter les paiements avec @stripe en dehors de leur application, sans commissions de l'App Store iOS". Les nouveaux documents de Stripe montrent comment utiliser Stripe Checkout au sein d'une application iOS, en redirigeant simplement les clients vers une page de paiement sécurisée hébergée par Stripe. Cela permet de contourner complètement le système in-app d'Apple. L'inconvénient est le travail du développeur : vous devez créer et maintenir vous-même la page de paiement hébergée et la logique web. Mais les frais forfaitaires de Stripe (2,9 % + 0,30 $ par transaction) sont bien inférieurs à 30 %.
exemple : Si vous vendez un produit numérique d'une valeur de 10 $, Apple prendrait normalement 3 $ (30 %) et vous donnerait 7 $. Si vous utilisez Stripe à la place, Apple encaisse 0 $, Stripe encaisse environ 0,59 $, ce qui vous donne un montant net de ~ 9,41 $ - plus de 30 % de plus qu'avec IAP. Même en comparant avec le taux de 15% de SBP, Stripe ne coûte que ~$0,59 par rapport à $1,50 d'Apple - une économie considérable.
Avantages : Réduction drastique des frais (vous conservez la majeure partie des revenus), contrôle total du flux de paiement (branding, offres, tests A/B) et pas besoin d'attendre App Review pour modifier les prix ou les plans. Vous pouvez intégrer les ventes web et mobiles (pour qu'un utilisateur puisse se connecter à votre site web et débloquer votre application iOS de manière transparente).
Inconvénients : Ils reprennent tout ce qu'Apple faisait auparavant. Cela signifie que vous devez mettre en œuvre un système de paiement sécurisé : Traitement des cartes de crédit, conformité PCI, rejets de débit, remboursements, prévention de la fraude et collecte des taxes sur les ventes ou de la TVA. Cela ne peut pas être trivial. RevenueCat met en garde : "Les équipes d'abonnement ne sont pas habituées à gérer directement la relation de paiement avec le client... Apple fait une grande partie du travail difficile en coulisses. Mais lorsqu'on met en œuvre des paiements externes, les développeurs sont soudain confrontés à de nouvelles responsabilités - rétrofacturations, remboursements, fraude aux paiements, retards de paiement, conformité à la TVA - et la liste ne s'arrête pas là". Le coût de la mise en place (ou de l'externalisation) de l'ensemble de l'infrastructure peut compenser une partie des 15-30 % de bénéfice, en particulier pour les très petites applications.
Une autre considération : Expérience utilisateur et confiance. La redirection des utilisateurs vers une caisse web peut sembler moins transparente que le formulaire d'achat propre à Apple. Votre application doit indiquer clairement où va l'argent (par exemple, "achat sur OurSite.com"). Il est possible que les utilisateurs doivent se connecter deux fois ou qu'ils doivent faire face à des problèmes mineurs. Et bien sûr, vous devez vous assurer que la redirection de l'application vers le web n'enfreint pas les règles d'Apple : Pour les apps américaines, vous pouvez désormais utiliser librement des liens externes, mais vous devez respecter l'esprit des directives (pas de pop-ups pleine page, utilisation de mentions neutres). Selon les règles révisées de l'App Store, vous pouvez insérer un lien externe sans avoir besoin d'une autorisation spéciale d'Apple, mais vous devez l'indiquer clairement. En bref, cette méthode est désormais légale sous iOS aux États-Unis (et déjà autorisée dans l'UE dans le cadre des conditions de paiement alternatives d'Apple), mais elle nécessite une mise en œuvre minutieuse.
Applications web progressives (PWA)
Une Progressive Web App (PWA) est essentiellement un site web qui se comporte comme une application. Les utilisateurs l'ouvrent dans leur navigateur (ou l'ajoutent à leur écran d'accueil), mais elle ne passe pas par l'App Store. Les PWA peuvent fonctionner hors ligne, envoyer des notifications push (Safari sur iOS le prend désormais en charge à partir d'iOS 16.4) et se comporter comme une application. Le grand avantage est évident : pas d'App Store signifie pas de commission Apple ou de retards de vérification. Vous pouvez mettre à jour l'application immédiatement en modifiant votre site web.
Les PWA ont gagné en attractivité auprès des entreprises qui souhaitent contourner les restrictions des App Stores. Des études menées par Movement, une plateforme spécialisée dans les PWA, montrent par exemple que seul un petit pourcentage des meilleurs développeurs dépendent des App Stores - de nombreuses applications à succès vivent exclusivement sur le web. En renonçant aux frais d'App Store, ces entreprises conservent 100 % des revenus générés par les ventes (hormis les frais de traitement des paiements).
Avantages : Une PWA contourne complètement l'écosystème d'Apple, de sorte que toutes les ventes sont libres de la part d'Apple. Vous contrôlez l'ensemble de l'expérience utilisateur et pouvez effectuer des mises à jour à tout moment. Les PWA fonctionnent en outre sur toutes les plates-formes (iOS, Android, desktop) via une seule base de code.
Inconvénients : Sur iOS, il y a toujours des restrictions. Les PWA ne peuvent être exécutées que dans le moteur Safari (pas de Chrome ou autre moteur de navigation sur iOS). Jusqu'à récemment, elles ne pouvaient pas envoyer de notifications push ou se mettre à jour en arrière-plan, mais Apple a progressivement amélioré la prise en charge (par exemple, les notifications push PWA ont été ajoutées dans iOS 16.4). Néanmoins, certaines intégrations d'appareils (comme Bluetooth, Apple Pay sur le web, les badges de l'écran d'accueil ou certaines API) peuvent ne pas fonctionner aussi bien dans une PWA. En outre, les PWA ne sont pas répertoriées dans l'App Store, de sorte que vous ne pouvez pas être trouvé via la recherche d'applications. Vous devez diriger les utilisateurs vers votre site web (via le marketing, les codes QR, etc.). Et sur iOS, il n'y a pas de "demande d'installation" - les utilisateurs doivent ajouter manuellement la PWA à leur écran d'accueil via Safari. Pour ces raisons, les PWA sont souvent mieux adaptées aux applications axées sur le contenu (actualités, publications, services) qu'aux jeux ou utilitaires hautement interactifs qui dépendent d'une intégration matérielle profonde.
En bref, une PWA est une possibilité de contourner complètement l'App Store. C'est une solution viable si la fonctionnalité de votre application peut être entièrement utilisée sur le web et si vous pouvez vous adresser à des utilisateurs en dehors de la place de marché d'Apple. Cela nécessite certes des investissements dans le développement d'applications web, mais cela peut s'avérer payant, car vous pouvez économiser les 15 à 30 % de réduction et accélérer le développement. (Il est à noter qu'Apple ne peut pas bloquer les PWA, et même les préoccupations dans l'UE ont été retirées).
Abonnements basés sur le web et applications "Reader
Une autre stratégie courante, notamment pour les applications de contenu (magazines, actualités, musique, vidéo, etc.), consiste à vendre des abonnements directement sur un site web plutôt que via l'application. L'utilisateur se connecte alors à votre application iOS pour accéder au contenu qu'il a acheté. Vous mettez donc en place un système d'adhésion sur votre domaine web, et l'application devient simplement un client. C'est ainsi que fonctionnent des services comme Netflix, Spotify et Kindle (ils ne forcent pas les utilisateurs à acheter via l'IAP d'Apple).
Realview Digital, une plateforme d'édition, explique qu'en vendant des abonnements sur votre site web, "tous les revenus vous restent acquis" et "l'abonné peut se connecter partout et avec n'importe quel appareil". Cette approche présente de grands avantages : 100 % des recettes d'abonnement vous reviennent, et vous obtenez des données complètes sur les utilisateurs et une flexibilité multiplateforme. Vous pouvez même proposer des offres web et papier ou des réductions supplémentaires pour inciter les utilisateurs à s'abonner en dehors de l'application.
Le hic, ce sont les règles d'Apple : les liens directs vers des sites d'achat externes étaient interdits dans le passé. Vous ne pouvez pas insérer dans votre application un bouton "S'abonner à notre site web" - cela serait contraire aux anciennes règles. À la place, Apple a autorisé une exception limitée : les apps "lecteurs" (qui se concentrent sur les livres, les magazines, la vidéo, l'audio, etc.) peuvent désormais demander l'autorisation de créer des liens externes. Si celle-ci est accordée, l'application peut contenir un lien vers la gestion du compte sur votre site web (par exemple "Gérer le compte" ou "S'abonner au site web"). La documentation d'Apple indique que les applications Reader fournissent principalement du contenu, comme des magazines ou des fichiers audio, permettent de se connecter et n'ont pas besoin de proposer le PAI dans iOS si elles utilisent ce lien. En substance, les applications Reader peuvent guider les utilisateurs plus librement vers l'extérieur.
Si votre application n'entre pas dans la catégorie "lecteur" (par exemple un outil de productivité ou un jeu), Apple continue d'interdire les liens ouverts. Vous pouvez toutefois mentionner en clair que les utilisateurs peuvent s'inscrire sur votre site web, à condition que vous proposiez également un achat in-app. Realview conseille de ne pas avoir de "gros bouton" qui mène les utilisateurs directement à un site d'abonnement, mais vous pouvez mentionner dans votre application qu'une option externe existe. Apple tolère ce type de redirection passive pour les utilisateurs avertis qui se connectent d'eux-mêmes à Internet.
Dans la pratique, de nombreux développeurs renoncent totalement à la vente in-app et s'appuient sur l'entonnoir de leur site web. Les utilisateurs qui ont téléchargé l'application savent (grâce au marketing) qu'ils doivent s'inscrire sur le site web. L'app ne contient alors qu'un écran de "connexion". D'un point de vue technique, cela correspond aux règles d'Apple (il n'y a pas de lien d'achat in-app) et c'est devenu une pratique courante. C'est une stratégie 100%ig légale : Apple ne peut pas empêcher les utilisateurs de visiter votre site web en dehors de l'application pour se connecter. Mais cela signifie perdre la commodité de l'IAP en un seul clic.
Avantages : Revenus complets et propriété des utilisateurs lors de la vente sur votre propre site web. Vous n'êtes pas limité par le barème de prix d'Apple et vous constituez une liste de clients par e-mail (que vous n'obtenez pas avec l'IAP d'Apple). Pour les entreprises qui proposent du contenu, cela offre également un accès multi-appareils (lecture sur le web, dans l'application iOS, etc.). Si vous vous qualifiez en tant qu'application "lecteur", vous obtenez une autorisation officielle de créer des liens.
Inconvénients : Vous supportez toute la complexité de la facturation (gestion des abonnements, respect des conditions de paiement, taxes, etc.) Vous devez acquérir des utilisateurs en dehors de l'App Store (via le webmarketing, les médias sociaux, etc.). Et jusqu'à récemment, il n'était pas possible de créer des liens directement dans l'application, ce qui représentait un effort supplémentaire pour les utilisateurs. Même avec l'autorisation de lier des lecteurs, vous perdez le caractère d'achat impulsif de l'IAP. En outre, certains développeurs ont signalé qu'Apple peut toujours critiquer ces procédures - par exemple en vous obligeant à conserver une option IAP ou en refusant les applications qui redirigent de manière trop agressive. Cette méthode nécessite donc un respect minutieux et de la clarté.
Implications juridiques et de conformité
Toute stratégie visant à économiser des commissions est liée à des considérations juridiques et politiques :
Politique d'Apple : Vous devez toujours respecter les App Store Review Guidelines d'Apple. Les règles relatives aux paiements externes ont évolué. Depuis mai 2025 (États-Unis), les directives d'Apple autorisent explicitement les "boutons, liens externes ou autres invitations à l'action" pour les options d'achat dans les apps américaines. En d'autres termes, les apps américaines peuvent désormais faire librement référence à des achats externes sur le web. Dans l'UE, des autorisations similaires avaient déjà été introduites auparavant dans le cadre de la loi européenne sur les marchés numériques. Apple fournit même des autorisations et des API spéciales (comme le StoreKit External Purchase Entitlement) aux apps qui souhaitent utiliser des fournisseurs de paiement externes. Assurez-vous d'adopter ces mécanismes officiels - dans l'UE, vous devez par exemple accepter l'Alternative Terms Addendum d'Apple et utiliser les API StoreKit si vous traitez des paiements en dehors de l'IAP.
Divulgation et flux d'utilisateurs : Soyez transparent même en cas d'autorisation légale. Évitez les UX trompeuses. La nouvelle injonction interdit par exemple à Apple d'afficher des avertissements en pleine page qui dissuadent à tort les utilisateurs de cliquer sur des liens d'achat externes. Apple ne peut plus non plus vous interdire de mentionner des méthodes de paiement alternatives. Toutefois, vous devez continuer à identifier clairement tous les flux de paiement externes (par exemple, "Vous serez redirigé vers example.com pour finaliser votre achat") et vous assurer que l'intention de l'utilisateur est respectée. N'effectuez pas de redirection automatique sans action de l'utilisateur.
Conformité des transactions : Si vous acceptez les paiements par Internet, vous devez vous conformer aux réglementations financières. Cela inclut la mise en œuvre de PCI-DSS si vous stockez ou transférez des données de carte de crédit, le respect du GDPR ou du CCPA pour les données personnelles et la gestion correcte des taxes (Apple et Stripe prenaient auparavant en charge les taxes pour IAP, mais vous en êtes désormais responsable). La législation européenne peut par exemple exiger que vous vous acquittiez de la TVA sur les services numériques. Vous avez besoin de conditions d'utilisation et de politiques de confidentialité sur votre site web pour couvrir les transactions. Les directives européennes d'Apple indiquent même explicitement que vous devez signaler les achats externes via la nouvelle API et suivre des modèles pour éviter les fraudes. Dans la pratique, travailler avec un prestataire de services de paiement fiable comme Stripe ou Paddle peut simplifier une grande partie de ces démarches, mais vous devez tout de même être conscient de vos obligations.
Risque de révision : N'oubliez pas qu'Apple vérifie toujours votre application. Si vous effectuez des paiements incorrects ou si vous semblez frauder le système, Apple pourrait refuser votre application. Par exemple, si vous vendez le même produit à la fois via l'IAP et moins cher sur votre site web, cela pourrait être considéré comme une incitation à acheter en dehors du magasin (bien que les nouvelles règles assouplissent ce point pour les apps américaines). Pour être sûrs de ne pas se tromper, de nombreux développeurs conservent les deux options, mais s'assurent qu'ils n'enfreignent pas une règle spécifique à leur catégorie lorsqu'ils utilisent des paiements externes. Par exemple, les applications non lectrices aux États-Unis peuvent désormais renoncer totalement au PAI, mais certains développeurs indiquent que le processus de vérification des applications n'est pas encore terminé, ce qui laisse planer une certaine incertitude. Il est préférable de tester minutieusement et de documenter votre respect des règles mises à jour (par exemple, l'utilisation des API StoreKit pour les achats externes dans l'UE ou l'activation du nouveau lien pour iOS comme étant autorisé).
Observation continue : Apple fait appel de la décision d'Epic, de sorte que les directives peuvent à nouveau changer. Il est conseillé de se tenir au courant des actualités des développeurs Apple et d'être préparé aux ajustements. Gardez également un œil sur les autres changements (par exemple, les 3 % de "frais de traitement des paiements" d'Apple dans l'UE pour l'utilisation du système de paiement Apple). De manière générale, pour toute solution de contournement, gardez un œil sur les explications d'Apple et les forums de la communauté afin d'identifier les éventuels problèmes.
Conclusion
Pour les développeurs iOS indépendants, l'époque des 30 % de commission sur l'App Store, qui n'était pas contestée, touche à sa fin. Le Small Business Program d'Apple a déjà réduit les frais à 15 % pour les développeurs éligibles, et des décisions de justice autorisent désormais la création de liens vers des sites de paiement externes - sans devoir payer la part d'Apple. Ceux qui utilisent Stripe (ou des fournisseurs similaires) pour rediriger les achats vers le web peuvent économiser jusqu'à 27 % de frais, mais doivent en contrepartie assumer le surcroît de travail. La création d'une Progressive Web App ou le fait de diriger les utilisateurs vers son propre site web pour les abonnements peut permettre de contourner complètement l'App Store (Realview recommande, dans le domaine de l'édition numérique, la vente directe via le web afin de "conserver la totalité du chiffre d'affaires"). Dans l'UE, de nouvelles réglementations permettent déjà d'utiliser des fournisseurs de paiement alternatifs - avec seulement une petite taxe Apple (3-17 %).
Chaque option présente des avantages et des inconvénients. Le Small Business Program est le plus simple si vous remplissez les conditions requises ; les paiements externes génèrent le plus de bénéfices, mais nécessitent des efforts techniques ; les PWA et les modèles basés sur le web contournent l'App Store, mais perdent en visibilité. L'essentiel est de choisir l'approche qui convient à votre produit et aux capacités de votre équipe. Il est important que la mise en œuvre soit correcte : utilisez les titres officiels d'Apple, respectez les directives actualisées de l'App Store et tenez compte des directives légales telles que les taxes et la protection des données.
De nombreux développeurs combinent ces approches - par exemple en proposant à une partie des utilisateurs des achats in-app via le SBP (15 %) et en fournissant à d'autres un flux de connexion via le web ou en gérant simultanément une application et une PWA complémentaire. Les conditions générales évoluent actuellement à un rythme effréné - restez donc informés et testez soigneusement. Vous pourrez ainsi maximiser vos revenus tout en respectant les règles d'Apple et en satisfaisant vos utilisateurs.
Sources : Pour élaborer ce guide, nous avons consulté des documents officiels d'Apple, des articles d'actualité, des informations de Stripe, des analyses de développeurs et des blogs du secteur.
FR 
DE 
EN 
ES