Comment tester les codes d’offre StoreKit dans Xcode 27.2 RC ? Tutoriel 2026

Le 19 octobre 2026, Apple a publié Xcode 27.2 RC, selon sa fiche officielle de publication. Pour tester les codes d’offre StoreKit, configurez un fichier StoreKit, vérifiez séparément l’échange dans l’app et la simulation hors app avec Transaction Manager, puis contrôlez la transaction, les droits accordés et sa clôture. Ce test local ne remplace ni la validation dans l’environnement Sandbox de l’App Store ni les essais avant publication.

Ce guide s’adresse aux développeurs iOS qui ajoutent un échange de code à un achat intégré ou à un abonnement et veulent valider le parcours dans l’app.
Il convient aussi aux personnes qui maintiennent la réception des mises à jour de transaction et l’attribution des droits après un échange hors app.
Les petites équipes qui testent avec Xcode 27.2 RC y trouveront une séparation claire entre preuve locale et validation de publication.

Dernière vérification : 30 octobre 2026, d’après la fiche de publication Xcode, les notes de mise à jour de l’App Store Connect et la documentation StoreKit d’Apple citée dans les étapes ci-dessous.

Configuration StoreKit locale ou données de l’App Store Connect

Avant de toucher à l’interface de l’app, déterminez ce que vous cherchez à prouver. Le test StoreKit dans Xcode sert à exercer localement un scénario d’achat configuré pour le projet. Il permet notamment de vérifier un échange de code d’offre défini dans le fichier de configuration. Il ne crée pas, à lui seul, une transaction réelle dans la boutique ni une preuve de fonctionnement avec les données commerciales de production.

La distinction importe si votre écran affiche un prix ou si votre logique accorde un accès à un abonnement. Les produits du fichier local servent aux tests du projet ; ne présentez pas une valeur de test comme le prix réellement proposé aux clients. Consultez la documentation Apple sur la configuration des tests StoreKit dans Xcode et celle consacrée aux tests à chaque étape du développement pour choisir le niveau de validation adapté.

Préparez votre projet dans cet ordre :

• Vérifiez la cible et le schéma de lancement. Assurez-vous que le schéma utilisé pour exécuter l’app est celui que vous souhaitez tester. Un fichier StoreKit rattaché au mauvais schéma peut conduire à tester un autre jeu de produits que celui attendu.
• Créez ou sélectionnez le fichier StoreKit. Dans les paramètres du schéma de lancement, associez le fichier de configuration destiné au test local. Gardez son nom explicite et évitez de le confondre avec les informations de vos produits dans App Store Connect.
• Définissez le produit concerné. Vérifiez que le produit auquel le code est associé existe dans la configuration et que son type correspond à votre cas d’usage. Un achat consommable, un achat non consommable et un abonnement n’ont pas les mêmes effets sur l’accès ni les mêmes conditions de répétition.
• Ajoutez un code d’offre de test. Dans le fichier StoreKit, configurez l’offre voulue pour le produit avant d’ouvrir l’app. La documentation Apple sur la prise en charge des codes d’offre dans une app décrit le parcours à prendre en charge ; suivez-la plutôt que de traiter un code local comme un code commercial actif.
• Relancez l’app avec la bonne configuration. Confirmez que le schéma exécute bien le fichier associé et que le produit testé correspond au code que vous avez préparé.

Comment vérifier que le code d’offre correspond au bon produit ? Comparez l’identifiant produit utilisé par le parcours de l’app avec celui défini dans le fichier StoreKit, puis vérifiez que l’offre configurée est rattachée à ce produit. Si l’écran de saisie s’ouvre mais que le scénario attendu ne produit pas de transaction, contrôlez d’abord cette association et la configuration du schéma avant de modifier votre logique d’achat.

La publication officielle indique également que la version Xcode 27.2 RC peut servir aux dépôts vers l’App Store et TestFlight, d’après les notes de mise à jour de l’App Store Connect déjà citées. Cette disponibilité ne démontre pas que le comportement d’une version RC est identique à celui d’une version finale. Vérifiez les notes au moment de votre essai et conservez la version réellement utilisée dans vos comptes rendus.

Échange dans l’app ou simulation hors app

Les deux parcours répondent à des questions différentes. Dans le premier, l’utilisateur lance l’échange depuis votre app. Dans le second, vous simulez l’échange hors app avec Transaction Manager et vérifiez que l’app détecte ensuite la transaction. Ne validez pas l’un en supposant que l’autre fonctionne automatiquement.

Comment tester l’échange d’un code dans l’app avec Xcode 27.2 RC ? Lancez l’app avec le fichier StoreKit sélectionné, ouvrez votre entrée d’échange, puis suivez le dialogue système jusqu’à confirmation du code configuré. Ensuite, vérifiez la réception et le traitement de la transaction dans l’app. L’apparition de l’interface de confirmation prouve seulement que vous avez atteint cette étape : elle ne prouve pas que votre code a accordé les droits prévus.

Utilisez la documentation Apple sur les codes d’offre dans l’app pour vérifier le chemin d’intégration. Notez le résultat observé à chaque point : ouverture du parcours, confirmation de l’offre, réception de la transaction, mise à jour des droits et fin du traitement. Si un point échoue, vous pourrez isoler le problème sans confondre l’interface, StoreKit et votre couche d’accès.

Après l’échange, contrôlez les effets réels dans l’app. Pour un abonnement, vérifiez que l’état reconnu par votre logique correspond à l’offre testée. Pour un achat non consommable, vérifiez que l’accès attendu est disponible après actualisation ou relance selon le fonctionnement de votre application. Pour un consommable, confirmez le résultat prévu par votre propre logique. Ces vérifications relèvent de votre code métier : le simple affichage d’un écran de confirmation n’en tient pas lieu.

Transaction Manager ou entrée de code dans l’app

Transaction Manager sert à simuler un échange effectué en dehors de l’interface de votre application. C’est utile pour vérifier un cas fréquemment oublié : l’utilisateur obtient une transaction sans avoir d’abord ouvert l’écran d’achat dans l’app, puis votre application doit la détecter et réconcilier ses droits.

Comment simuler un échange hors app avec Transaction Manager ? Lancez le scénario StoreKit configuré, ouvrez Transaction Manager dans Xcode et sélectionnez le produit et le code d’offre de test concernés. Déclenchez la simulation, puis observez le processus de l’app : il doit recevoir la mise à jour de transaction, l’interpréter et appliquer les droits correspondants. Apple décrit ce parcours dans sa documentation sur les tests d’achats effectués hors de l’app.

Ne considérez pas la sélection de l’offre dans Transaction Manager comme une preuve suffisante. Faites en sorte que l’app soit déjà capable d’observer les transactions pertinentes, y compris quand l’échange n’a pas été initié par un bouton de son interface. Avec StoreKit 2, vérifiez en particulier le traitement de Transaction.updates et la manière dont votre application rapproche l’événement reçu de son état d’accès. La documentation Apple sur Transaction.updates précise le rôle de cette séquence de mises à jour.

Pour rendre le diagnostic reproductible, consignez :

• le produit et le code configurés dans le fichier StoreKit ;
• le parcours déclenché — échange initié dans l’app ou simulation dans Transaction Manager ;
• l’événement reçu par le code qui observe les transactions ;
• l’état de droit avant et après le traitement ;
• le moment où votre application termine la transaction, lorsqu’elle doit le faire.

Si la simulation apparaît dans Transaction Manager mais que le compte utilisateur reste verrouillé, inspectez d’abord le consommateur de transactions et la règle d’attribution des droits. Si l’app accorde l’accès mais ne termine pas le traitement, le scénario reste incomplet : répéter le test sans examiner cet état peut rendre les essais suivants difficiles à interpréter.

Droits mis à jour ou simple confirmation affichée

Le test est réussi seulement si toute la chaîne prévue par votre application est cohérente. Cela signifie que l’événement est observé, que le produit est reconnu, que la règle d’accès s’applique au bon compte et que le traitement de transaction se termine conformément au modèle choisi. Une fenêtre système visible ne confirme pas ces étapes applicatives.

Comment confirmer que l’app a reçu la mise à jour après l’échange ? Ajoutez un point d’observation dans le traitement de transaction, puis comparez-le au changement visible des droits. Vous devez pouvoir relier l’événement observé à la mise à jour d’état qui ouvre effectivement le contenu ou la fonction concernés. Si les journaux indiquent une transaction reçue sans changement d’accès, cherchez l’échec dans la validation métier ou la synchronisation des droits, plutôt que dans le dialogue de saisie.

Adaptez le contrôle au type de produit :

• Abonnement. Vérifiez que l’app interprète le statut pertinent pour l’accès, et ne se contente pas de mémoriser qu’un échange a eu lieu. Si votre service d’accès maintient un état séparé, consignez aussi le résultat de sa mise à jour.
• Achat non consommable. Confirmez que l’accès est restaurable selon les règles de votre application et qu’il ne dépend pas uniquement de la session qui a affiché l’échange.
• Achat consommable. Vérifiez que le traitement applique l’effet prévu sans attribuer un bénéfice différent de celui défini dans votre logique.

Terminez le traitement au moment approprié, après avoir vérifié la transaction et appliqué les effets requis par votre app. La fin de transaction n’est pas un substitut à la validation du droit ; inversement, accorder un accès sans terminer correctement le traitement attendu laisse un test incomplet. Consultez les recommandations StoreKit d’Apple sur les étapes de test et sur les mises à jour pour faire correspondre votre implémentation à l’événement réellement reçu.

Répétition du test ou réinitialisation de l’état

Un scénario qui réussit une fois peut être impossible à rejouer tel quel si le produit ou l’état de transaction influence l’éligibilité. Ne concluez donc pas que toutes les offres se répètent de la même manière. Le comportement dépend du type de produit, de l’état créé par vos essais et des conditions de l’offre configurée.

Comment réinitialiser les transactions pour rejouer un scénario ? Examinez d’abord l’état dans Transaction Manager et les droits conservés par votre app. Vérifiez ensuite si l’essai concerne un abonnement, un produit non consommable ou un consommable : une transaction ou un droit déjà présent peut changer le résultat attendu. Réinitialisez ou supprimez uniquement l’état de test applicable à ce scénario, puis relancez le test depuis la même configuration. Les outils de gestion des transactions sont décrits dans la documentation Apple consacrée aux achats simulés hors app et à la configuration StoreKit dans Xcode.

Avant de supprimer un état, enregistrez ce qui a été testé et ce qui doit être rejoué. Sinon, vous risquez de confondre deux résultats : un code refusé en raison d’une condition d’éligibilité et un événement non traité par l’application. Après la remise à zéro, confirmez que le schéma utilise toujours le bon fichier StoreKit et que le testeur observe le bon processus de l’app.

Une remise à zéro réussie ne constitue pas une validation commerciale. Elle prépare seulement un nouveau scénario local. Pour tester les produits et comportements avec l’environnement Sandbox de l’App Store, passez à cette étape séparément et vérifiez les conditions propres à ce parcours. Le guide Apple sur les étapes de test StoreKit distingue les tests locaux de ceux réalisés dans Sandbox.

Poste actuel ou Mac distant pour les reprises

Un poste local suffit si vous pouvez y exécuter la version Xcode visée, garder le projet et ses dépendances disponibles, puis répéter le scénario avec le même schéma et la même configuration. Le poste devient moins pratique si le disque est déjà occupé par les outils et simulateurs, si plusieurs personnes doivent reprendre le diagnostic ou si la machine de test n’est pas disponible au moment où vous en avez besoin. Un service distant ne corrige toutefois ni un mauvais fichier StoreKit ni une logique de transaction défaillante : il change le lieu d’exécution, pas la frontière entre test local, Sandbox et production.

Si vous devez répéter ces essais dans un environnement macOS accessible à distance, examinez les conditions de travail et d’accès présentées dans le guide des environnements Mac distants. Pour comparer le coût d’un usage loué à une machine dédiée, consultez également le guide de tarification du Mac mini M4. Évaluez votre besoin selon la durée des tests, la disponibilité requise et la nécessité d’accéder à une machine physique ; un achat peut rester plus adapté à une charge permanente ou à un besoin matériel local.

Avant de considérer le scénario reproductible, vérifiez que le Mac distant exécute bien la version Xcode sélectionnée, que le projet utilise le fichier StoreKit attendu, que le schéma lance la bonne app et que les événements de transaction comme l’état des droits sont consignés. Séparez explicitement ces éléments dans votre compte rendu : accès au bureau distant, exécution du test local StoreKit, traitement applicatif réussi et validation dans Sandbox. Ce sont des preuves différentes.

Pour une petite équipe qui teste ponctuellement une offre, un Mac déjà disponible peut être le choix le plus simple. Pour des reprises récurrentes, un environnement distant peut éviter de réserver en permanence le poste principal, tout en facilitant la continuité des essais. Si votre Mac actuel est encombré, difficile à partager ou indisponible pour les tests, la location d’un Mac auprès de MacDate peut offrir une expérience plus adaptée à ces sessions répétées ; si vous avez besoin d’une machine locale en continu ou d’interfaces physiques, conservez plutôt votre propre matériel. Dans tous les cas, validez d’abord la chaîne StoreKit dans le local, puis passez par Sandbox avant de considérer le parcours prêt à publier.