Comment mettre en œuvre l'achat intégré iOS dans WebView

Découvrez comment intégrer des achats in-app via WebView dans vos applications iOS tout en respectant les règles strictes d'Apple et les enjeux financiers qui en découlent.

Vous développez une application et souhaitez permettre aux utilisateurs d'acheter des fonctionnalités ou du contenu supplémentaires directement dans l'application. Une méthode courante pour ce faire est d'utiliser WebView, qui permet à votre application d'afficher du contenu web directement. Cependant, dans le cas des applications conçues pour iOS, Apple a des règles strictes concernant les paiements dans les applications.

Dans ce guide, nous allons aborder ce qu'est WebView dans le développement d'applications, comment fonctionnent les achats in-app dans WebView et pourquoi les développeurs iOS le préfèrent.

Nous discuterons également des politiques d'Apple sur ces achats, des raisons de ces règles, des moyens possibles d'inclure des achats in-app dans WebView, de leur efficacité, et des conséquences si Apple découvre une solution de contournement.

Qu'est-ce que WebView dans le développement d'applications ?

WebView dans le développement d'applications est un composant qui agit comme un mini navigateur web à l'intérieur de votre application mobile. Il permet aux applications d'afficher du contenu web directement dans l'interface de l'application sans ouvrir un navigateur séparé.

Les développeurs utilisent WebView pour afficher des pages web, telles que des sections d'aide, des accords d'utilisateur, ou même des options d'achat in-app, alliant parfaitement contenu web et éléments natifs de l'application pour améliorer l'expérience utilisateur.

Qu'est-ce que l'achat in-app dans WebView ?

Les achats in-app sont une façon de vendre du contenu ou des services numériques au sein de votre application. Pensez à eux comme à une boutique virtuelle où les utilisateurs peuvent acheter de nouvelles fonctionnalités, accéder à du contenu premium, ou obtenir d'autres biens numériques pour améliorer leur expérience d'application.

Lorsqu'on parle de rendre ces achats possibles via WebView, nous faisons référence à une méthode spécifique de présentation de ces opportunités. WebView peut afficher des pages web sans quitter l'application, permettant aux utilisateurs de faire des achats ou de s'abonner à des services.

D'un autre côté, les achats in-app natifs sont intégrés directement dans l'application en utilisant les systèmes et outils fournis par les plateformes (dans ce cas, iOS). Cette méthode entièrement intégrée est conçue pour fonctionner dans l'interface de l'application et respecte toutes les règles établies par Apple. Pour les utilisateurs, acheter quelque chose de manière native semble fluide et sécurisé parce que cela fait partie de l'application qu'ils utilisent.

Pourquoi les développeurs iOS recherchent-ils WebView pour les achats in-app ?

Pour plusieurs raisons, les développeurs cherchent souvent à ajouter WebView pour les achats in-app dans les applications iOS. Tout d'abord, il y a l'aspect financier. Apple prélève une commission de 15 à 30 % sur tous les achats in-app effectués via son système natif. En utilisant WebView pour gérer les transactions, les développeurs espèrent éviter ou réduire ces frais, gardant ainsi une part plus importante de leurs revenus.

Deuxièmement, les développeurs recherchent plus de flexibilité et de contrôle sur l'expérience d'achat. WebView leur permet de personnaliser l'apparence et la sensation du processus d'achat bien au-delà de ce qui est possible avec le système d'achat in-app natif d'Apple.

Cette personnalisation peut inclure des éléments de marque, des champs d'informations supplémentaires et des options de paiement uniques, offrant une expérience adaptée qui s'aligne mieux sur le design et la fonctionnalité de l'application.

Apple permet-il les achats in-app dans WebView ?

Apple maintient une position claire concernant les achats in-app (IAP) via WebView : ce n'est pas autorisé. Selon les Lignes directrices de révision de l'App Store d'Apple, en particulier la section 3.1.1 Achats in-app, les développeurs doivent utiliser le système natif IAP d'Apple pour vendre des biens et services numériques dans leurs applications.

Cette politique garantit que les transactions sont sécurisées, cohérentes et intégrées au sein de l'écosystème iOS, offrant une expérience fluide pour les utilisateurs. Les directives stipulent que si une application propose du contenu, des abonnements ou des fonctionnalités qui doivent être débloquées ou achetées, cela doit se faire via le mécanisme IAP d'Apple.

Ce système gère automatiquement le processus de transaction, de la facturation à la distribution de biens numériques, et respecte les normes de confidentialité et de sécurité d'Apple. En exigeant l'utilisation de son système IAP, Apple vise à protéger les utilisateurs et à maintenir la qualité et l'intégrité de l'écosystème d'application sur sa plateforme.

Comprendre les raisons derrière les restrictions d'Apple

Les restrictions d'Apple sur les achats in-app, en particulier son interdiction de WebView pour les transactions, reposent sur plusieurs préoccupations clés :

1. Sécurité

Les règles strictes d'Apple concernant les achats in-app visent principalement à garantir la sécurité des utilisateurs. Le système natif protège contre la fraude et les violations de données, sécurisant des informations sensibles comme les cartes de crédit.

Détails via des transactions cryptées.

2. Expérience utilisateur

Les directives d'Apple se concentrent sur l'assurance d'une expérience utilisateur fluide. Le système d'achat natif s'intègre dans les applications, offrant des transactions cohérentes et sans interruption qui maintiennent la confiance des utilisateurs et le flux de l'application.

3. Intégrité de l'écosystème

Les politiques d'Apple visent également à maintenir la qualité et la fiabilité de l'écosystème. En imposant l'utilisation de son système d'achat in-app, Apple peut faire respecter ses normes dans toutes les applications, garantissant une plateforme sûre et de haute qualité pour les utilisateurs et les développeurs.

Méthodes de paiement autorisées par iOS

Dans iOS, Apple distingue entre les biens et services numériques et physiques en ce qui concerne les méthodes de paiement autorisées. Cette distinction garantit à la fois sécurité et flexibilité dans divers types de transactions.

1. Biens et services numériques

Pour les biens et services numériques—comme le déverrouillage de contenu premium d'applications, l'abonnement à des magazines numériques, ou l'achat de monnaie virtuelle—les développeurs doivent utiliser le système d'achat in-app d'Apple. Cette approche garantit que toutes les transactions numériques sont traitées de manière sécurisée et cohérente, offrant aux utilisateurs une expérience d'achat fluide et intégrée au sein de l'application.

2. Biens et services physiques

Les développeurs peuvent mettre en œuvre des méthodes de paiement alternatives pour les biens et services physiques—comme la commande de produits physiques, la réservation de services réels, ou l'achat de billets pour des événements.

Cela peut inclure diverses options de traitement des paiements en dehors du système d'achat in-app d'Apple, comme les paiements par carte de crédit, Apple Pay, ou des passerelles de paiement tierces. La clé ici est que ces transactions concernent des biens ou des services utilisés ou consommés en dehors de l'application, n'affectant donc pas directement le contenu numérique ou l'expérience de l'application.

Contournements pour ajouter l'achat in-app iOS dans WebView

Avis : Ce contenu sur les contournements est uniquement à des fins éducatives. Nous ne recommandons ni ne promouvons l'évasion des règles d'Apple, ce qui peut entraîner de graves conséquences. Suivez toujours les directives d'Apple pour les développeurs.

Les développeurs explorent souvent des stratégies pour contourner les exigences strictes d'achat in-app d'Apple, en particulier la demande d'utiliser le système d'Apple pour les transactions numériques. Ces contournements sont largement discutés dans les communautés de développeurs, y compris sur des plateformes comme Reddit.

Bien que certains développeurs signalent un succès temporaire, ces méthodes comportent des risques importants et des conséquences potentielles. Voici un aperçu de certaines de ces stratégies :

1. Diriger les utilisateurs vers un navigateur web

Ce contournement consiste à inviter les utilisateurs dans l'application à finaliser leur achat dans un navigateur web externe. Par exemple, un bouton ou un lien dans l'application pourrait ouvrir le navigateur web par défaut de l'utilisateur vers une page où la transaction peut être finalisée.

Le but est de contourner le système d'achat in-app d'Apple et les frais associés en traitant les paiements via le site web du développeur ou un processeur de paiement tiers.

Bien que cette méthode évite les frais d'Apple, elle perturbe l'expérience utilisateur en sortant les utilisateurs de l'environnement de l'application. Elle risque de violer les directives de l'App Store, ce qui pourrait entraîner le rejet ou la suppression de l'application.

2. Services d'abonnement en dehors de l'application

Les développeurs vendent un service d'abonnement sur leur site web ou une autre plateforme en dehors de l'application iOS. Les utilisateurs achètent là-bas puis se connectent à l'application avec leur compte pour accéder au contenu ou aux fonctionnalités d'abonnement.

En vendant des abonnements en dehors de l'application, les développeurs visent à conserver une plus grande part des revenus en évitant la commission d'Apple.

Cette méthode dépend des utilisateurs complétant des transactions en dehors de l'application, ce qui peut constituer un obstacle significatif à la conversion. Si Apple détermine que l'application est principalement conçue pour contourner les achats in-app, elle peut faire face à des conséquences similaires à celles des autres méthodes de contournement.

3. Intégration de contenu web via WebView

Les développeurs intègrent du contenu web directement dans l'application en utilisant WebView, créant une expérience web intégrée pour effectuer des achats. Cette stratégie tente d'offrir le meilleur des deux mondes : maintenir l'expérience in-app tout en traitant les paiements d'une manière qui contourne les frais d'Apple.

Cette approche suit de près les directives d'Apple. Bien que techniquement, la transaction se déroule dans un WebView au sein de l'application, elle peut toujours être perçue comme une tentative d'éviter le système d'achat in-app. L'efficacité de cette méthode est conditionnelle à...

Le processus de révision d'Apple est rigoureux, et il comporte le risque de suppression de l'application si elle est jugée en violation des directives.

Conséquences si votre contournement est détecté

Les politiques d'Apple sont transparentes et strictement appliquées. Toute tentative d'échapper à ces règles comporte des risques significatifs. Les conséquences possibles vont au-delà de la simple perte d'argent ; elles peuvent affecter chaque aspect des activités présentes et futures d'un développeur sur l'App Store. Voici un aperçu de ce qui est en jeu :

• Suppression immédiate de l'application : Si Apple découvre qu'une application contourne son système IAP, elle peut retirer l'application de l'App Store sans avertissement. Cette action coupe instantanément l'accès à des millions d'utilisateurs potentiels, empêchant toute future téléchargement ou mise à jour.
• Suspension du compte développeur : Les développeurs qui violent à plusieurs reprises les directives d'Apple ou commettent une violation grave peuvent voir leurs comptes développeur suspendus. Cela affecte l'application en question et impacte la capacité du développeur à gérer ou mettre à jour d'autres applications.
• Perte financière : En plus de perdre des revenus provenant des ventes d'applications, les développeurs surpris à contourner le système IAP peuvent faire face à des pénalités financières. Apple pourrait exiger un remboursement équivalent à sa part des transactions traitées en dehors du système IAP.
• Dégâts à la réputation : La suppression de l'App Store pour violation des directives peut nuire à la réputation d'un développeur. La confiance et la crédibilité établies avec les utilisateurs au fil du temps peuvent rapidement être perdues, impactant l'application ainsi que les autres projets et activités futures du développeur.

Questions et réponses à maîtriser

iOS autorise-t-il les applications WebView  ?

Oui, iOS autorise les applications WebView. Voici quelques points clés à retenir :

• -

Définition

: Les applications WebView permettent aux sites Web de fonctionner comme des applications natives sur iOS.
• Fonctionnalité : Elles peuvent offrir une expérience utilisateur fluide, intégrant des éléments interactifs et visuels.
• Accès aux fonctionnalités : Bien que WebView donne accès à certaines fonctionnalités graphiques et interactives, l'accès à des fonctionnalités système est souvent limité par rapport aux applications natives.
• Utilisation courante : De nombreuses applications iOS utilisent des WebViews pour afficher du contenu, notamment pour des éléments de navigation ou des intégrations tierces. En résumé, les applications WebView sont une option viable pour créer des expériences utilisateur sur iOS.

Comment activer les achats intégrés sur iOS ?

Pour activer les achats intégrés sur iOS, suivez ces étapes simples :

 

• Ouvrez les Paramètres de votre appareil.
• Accédez à Temps d'écran.
• Sélectionnez Restrictions du contenu et de la confidentialité.
• Touchez Achats iTunes et App Store.
• Cliquez sur Achats In-app.
• Choisissez Autoriser pour activer les achats intégrés ou Ne pas autoriser pour les désactiver. Assurez-vous que les restrictions sont configurées selon vos préférences afin de gérer les achats intégrés sur votre appareil.

 

Quel est l'équivalent IOS de Webview  ?

L'équivalent iOS de WebView est WKWebView. Voici quelques points clés à retenir :

• -

Remplacement de UIWebView

: WKWebView a été introduit à partir d'iOS 8, remplaçant la classe UIWebView.
• Compatibilité : WKWebView est également utilisé dans macOS à partir de la version 10.10 en remplacement de la classe WebView.
• Intégration : Vous pouvez intégrer un objet WKWebView dans votre hiérarchie de vues par programmation ou via Interface Builder.
• Avantages : WKWebView offre de meilleures performances et une sécurité améliorée par rapport à son prédécesseur. En résumé, WKWebView est le choix recommandé pour afficher du contenu web dans les applications iOS et macOS.

Comment autoriser un achat depuis une app ?

Pour autoriser un achat depuis une application, suivez ces étapes simples :

 

• Ouvrez l'app Réglages sur votre appareil.
• Accédez à la section Famille :
  • - Touchez l’option

  Famille

  .
• Sélectionnez le membre de la famille :
• Touchez le nom d’un membre pour lequel vous souhaitez gérer les autorisations.
• Activez l'option d'autorisation d'achat :
• Touchez Demander l'autorisation d'achat.
• Activez ou désactivez l’option Exiger une demande d'autorisation selon vos préférences. En suivant ces étapes, vous pourrez facilement gérer les autorisations d’achat pour les applications sur votre appareil.

 

Maintenant que tu as fini de lire Comment mettre en œuvre l'achat intégré iOS dans WebView, nous t'invitons à explorer davantage la catégorie IOS. Tu y trouveras d'autres articles intéressants qui élargiront tes connaissances et te tiendront informé. Ne cesse pas de lire et de découvrir plus!