App Store Connect Retention Messaging ne s’affiche pas dans Sandbox ? Diagnostic 2026

Cette semaine, commencez par déterminer si votre test utilise les messages configurés dans App Store Connect ou la Retention Messaging API en temps réel, puis vérifiez le statut, l’abonnement associé et le parcours d’annulation Sandbox. Un brouillon récent peut être visible par les testeurs Sandbox même s’il n’est pas encore approuvé : l’absence d’approbation ne suffit donc pas à expliquer le problème. Si vous utilisez l’API, contrôlez aussi sa réponse et les messages de repli documentés par Apple.

Cet article s’adresse aux développeurs iOS qui ne voient pas la message attendue après une annulation d’abonnement dans Sandbox, ainsi qu’aux ingénieurs StoreKit et serveur qui doivent valider l’éligibilité aux offres et les identifiants utilisés. Il concerne aussi les responsables CI et publication qui cherchent à séparer un problème de compilation d’un défaut de configuration ou de parcours de test.

Dernière mise à jour : 8 novembre 2026. Vérification effectuée à partir des informations Apple publiées le 4 novembre 2026, de la documentation App Store Connect, des guides Sandbox et des documents de la Retention Messaging API. (annonce Apple, documentation de l’API)

Configuration dans App Store Connect ou sélection en temps réel : deux chemins distincts

Avant de modifier le projet ou de reconstruire l’environnement, identifiez le mécanisme qui doit fournir la message. Les deux parcours peuvent aboutir à une présentation dans le flux d’annulation, mais ils ne produisent pas les mêmes éléments de diagnostic.

Dans le parcours configuré, vous créez une Retention Message dans App Store Connect et l’associez à un abonnement. L’enquête porte alors sur le contenu, son état, son association au produit et les conditions applicables à l’abonné. Le point de départ est la configuration enregistrée, puis son aperçu et enfin le test du parcours réel. Le guide Apple de configuration des Retention Messages décrit la création et la mise en place de ces messages.

Avec la Retention Messaging API, votre service participe à la sélection en temps réel. Il faut alors examiner la requête reçue, la réponse produite, les identifiants transmis et les règles de repli. Un aperçu App Store Connect ne prouve pas à lui seul que le service a répondu correctement à l’appel effectué pendant l’annulation. La présentation officielle de la Retention Messaging API permet de replacer ce parcours dans le flux prévu par Apple.

Cette distinction évite un diagnostic fréquent mais coûteux : chercher un défaut de réponse serveur alors que l’application dépend d’un message configuré, ou inversement inspecter uniquement l’interface App Store Connect alors que la sélection doit venir du service. Notez le parcours attendu avant chaque reproduction et conservez séparément les preuves obtenues pour chacun.

Pourquoi la Retention Message n’apparaît-elle pas pendant l’annulation Sandbox ?

Une annulation dans Sandbox ne valide pas simplement l’existence d’un texte dans App Store Connect. Il faut que le compte, l’abonnement, l’environnement et l’entrée dans le parcours correspondent au cas que vous essayez de reproduire. Un décalage sur l’un de ces points peut donner l’impression que le message ne fonctionne pas alors que la configuration elle-même est présente.

Vérifiez d’abord l’environnement et le compte utilisés

Confirmez que le test s’effectue bien avec le compte Sandbox prévu et dans l’environnement de test correspondant. Vérifiez également que le compte concerné est celui qui détient l’abonnement testé ; une configuration correcte ne garantit pas que le compte actuellement connecté est éligible à ce message ou à l’offre qui l’accompagne.

Comparez les informations visibles dans votre journal de test : compte, produit d’abonnement, environnement et moment où le parcours d’annulation a été déclenché. Si votre équipe alterne entre comptes Sandbox, builds et données de test, consignez ces éléments au même endroit que la reproduction. Sans cette trace, vous risquez de comparer l’aperçu d’un produit à l’annulation d’un autre abonnement.

Apple indique que Sandbox permet de tester les Retention Messages et que les testeurs peuvent voir les brouillons les plus récents. En conséquence, ne déduisez pas automatiquement d’un état « en attente » ou d’un brouillon que Sandbox doit masquer la message. Vérifiez plutôt le statut exact et le parcours testé. Les règles de visibilité selon l’état sont détaillées dans la référence Apple des statuts de Retention Message.

Le parcours d’annulation doit être celui de l’abonnement testé

Pour valider l’affichage, déclenchez l’annulation par le parcours Sandbox prévu par Apple, en utilisant le compte et l’abonnement que vous venez de vérifier. Un bouton interne qui simule « annuler » peut être utile pour tester l’interface de votre application, mais il ne démontre pas que le flux système d’annulation présente la Retention Message.

Cette différence compte particulièrement dans les suites de tests automatisées : une action qui met à jour un état local ou masque une interface n’équivaut pas nécessairement à une annulation réelle de l’auto-renouvellement dans le parcours Apple. Suivez les étapes décrites dans la documentation officielle sur la désactivation du renouvellement automatique pour les tests StoreKit, puis observez si la message apparaît dans ce flux.

Si elle n’apparaît toujours pas, recommencez avec un compte Sandbox clairement identifié et un seul abonnement à la fois. Vous pourrez ainsi distinguer une erreur de parcours d’un problème d’association ou d’éligibilité, au lieu de réinitialiser tout le jeu de données dès la première absence.

Un brouillon peut-il être testé avant l’approbation ?

Oui, le fait qu’une message n’ait pas encore obtenu son approbation ne signifie pas à lui seul qu’elle est inutilisable en Sandbox. Apple précise que les testeurs Sandbox peuvent voir les brouillons les plus récents. Il faut donc interpréter l’état selon l’environnement, et ne pas appliquer automatiquement au test Sandbox les mêmes attentes qu’à la présentation en production.

Dans App Store Connect, examinez le statut affiché pour la message et vérifiez qu’il correspond bien à l’élément que vous êtes en train de tester. Un brouillon, une demande en cours d’examen, un élément approuvé ou un élément refusé ne représentent pas le même état de traitement. La page consacrée aux statuts doit servir de référence avant de conclure à une anomalie.

Le statut n’est toutefois qu’une partie du contrôle. Pour un test Sandbox, comparez aussi la version du contenu visible dans l’aperçu avec celle que vous venez de modifier. Si vous avez changé une image ou un texte, assurez-vous de ne pas diagnostiquer l’ancienne configuration à partir d’un test antérieur, d’une capture conservée ou d’un autre produit d’abonnement.

À l’inverse, ne prenez pas la visibilité du brouillon dans Sandbox comme une preuve que la configuration est prête pour les utilisateurs en production. Les conditions de test et l’état de disponibilité ne se confondent pas. Séparez dans votre compte rendu les observations Sandbox, l’état App Store Connect et la validation requise pour la mise en production.

Le message est configuré, mais quel lien vérifier en premier ?

Commencez par l’association entre la Retention Message et l’abonnement effectivement soumis au test. Confirmez que l’identifiant du produit correspond, sans vous fier uniquement au nom affiché dans une interface : deux produits peuvent avoir des libellés proches tout en représentant des abonnements distincts. Vérifiez également que le compte Sandbox utilisé détient bien l’abonnement concerné.

Ensuite, séparez les messages sans offre des messages avec offre. Pour une message sans avantage tarifaire, vérifiez le texte, l’image éventuelle, l’aperçu et le produit lié. Pour une message qui inclut une offre, contrôlez en plus que l’utilisateur et l’abonnement correspondent aux conditions applicables à cette offre. Une inadmissibilité à l’offre ne prouve pas que la message elle-même est absente ou mal configurée.

L’aperçu est utile pour valider le contenu et son association, mais il ne remplace pas le parcours d’annulation réel. Si l’aperçu est correct et que l’annulation Sandbox ne présente rien, revenez aux éléments d’exécution : compte, environnement, abonnement, chemin de sélection de la message et déclenchement de l’annulation. Si l’aperçu lui-même montre un autre contenu ou ne reflète pas l’association attendue, corrigez la configuration avant de poursuivre les essais d’intégration.

Il est aussi utile de faire relire la configuration par une personne qui n’a pas créé la message. Elle peut comparer, sans présumer du résultat attendu, l’identifiant d’abonnement de l’application, celui sélectionné dans App Store Connect et le compte de test. Cette vérification croisée ne remplace pas les contrôles Apple, mais elle réduit le risque de confondre les noms commerciaux visibles et les identifiants utilisés par le code.

Que vérifier si la Retention Messaging API ne renvoie pas de sélection ?

Pour le parcours API, reconstruisez l’échange observé au moment du test plutôt que de vous limiter à une vérification générale de la disponibilité du service. Relevez la requête reçue par votre serveur, les paramètres pertinents, la réponse générée, l’horodatage du test et le message sélectionné. Ces traces doivent vous permettre de déterminer si l’appel est arrivé, si le serveur a répondu et si la réponse désigne un message cohérent avec l’abonnement concerné.

Inspectez ensuite le format de la réponse et la correspondance entre le produit, le message choisi et les données du testeur. Une requête reçue sans réponse exploitable n’est pas équivalente à une réponse valide qui sélectionne une message. De même, une réponse bien formée ne prouve pas que l’identifiant renvoyé correspond à une configuration disponible dans App Store Connect.

En cas d’absence de réponse ou de réponse invalide, ne présumez pas que l’écran restera vide ni qu’un même message de secours s’affichera dans tous les cas. Apple décrit un ordre de sélection et des options de repli qui peuvent inclure la réponse en temps réel, les messages configurés dans App Store Connect et le message par défaut de l’API. Vérifiez les conditions applicables à votre configuration dans la documentation officielle de la Retention Messaging API, puis consignez séparément les cas « réponse valide », « réponse invalide » et « absence de réponse ». Ce sont des scénarios distincts, qui ne doivent pas être regroupés sous un seul résultat supposé.

Si l’environnement de test paraît correctement configuré mais que les réponses changent selon la charge ou le comportement du service, consultez également les règles Apple relatives aux limites d’accès et aux tests de performance. La documentation dédiée explique comment identifier les limites de requêtes et comment lancer un test de performance. N’attribuez toutefois pas l’absence d’une message à une limite ou à une exigence de performance sans disposer de traces qui étayent cette conclusion.

Les équipes qui adaptent leurs outils à App Store Connect API 4.6 doivent distinguer les appels de gestion de configuration des requêtes en temps réel de Retention Messaging : le numéro de version d’une API ne constitue pas, à lui seul, une preuve du chemin effectivement utilisé pendant l’annulation. Pour toute affirmation sur cette version ou ses changements, appuyez-vous sur les notes de version App Store Connect et sur les documents propres à l’API appelée.

Une reproduction de bout en bout permet d’isoler le défaut

Procédez par étapes courtes, en conservant une trace du résultat à chaque point, afin de revenir au premier contrôle qui diverge au lieu de reconstruire l’environnement complet.

• Ouvrez la configuration de la Retention Message dans App Store Connect et notez son statut, son produit associé ainsi que le contenu attendu.
• Examinez l’aperçu afin de confirmer que le texte, l’image et, le cas échéant, l’offre correspondent au scénario visé.
• Vérifiez le compte Sandbox, l’environnement et l’identifiant de l’abonnement utilisé par l’application.
• Déclenchez l’annulation par le parcours de test Apple correspondant, et non par un mécanisme interne qui ne ferait que simuler l’état d’annulation.
• Si le scénario repose sur l’API, corrélez l’événement avec la requête reçue par le serveur et sa réponse ; notez aussi si la configuration de repli a été utilisée.
• Comparez le résultat observé aux attentes documentées et reprenez le diagnostic au premier écart identifié.

Ces vérifications évitent de confondre trois catégories de panne : une configuration qui ne cible pas le bon abonnement, un test qui n’entre pas dans le parcours Sandbox attendu, et une réponse en temps réel absente ou incohérente. Pour distinguer une erreur d’environnement d’un défaut de construction, vous pouvez aussi consulter nos guides de développement et de validation sur Mac.

Choisir le bon environnement de validation

Si le contenu, le statut et le parcours sont corrects, mais que vous ne parvenez pas à reproduire le résultat dans l’équipe, séparez les outils nécessaires à la compilation des outils nécessaires à la validation du parcours. Construire ou signer une version iOS exige un environnement macOS et Xcode ; observer l’annulation et l’éligibilité demande ensuite un compte Sandbox, le bon abonnement et le parcours de test approprié. Ces contrôles répondent à des questions différentes.

Les scripts CI peuvent compiler et signer le test à partir d’un environnement Mac, tandis que les journaux serveur servent à suivre la sélection en temps réel. Cela ne garantit pas que le test de l’interface ou l’accès à un appareil physique soit couvert par la même infrastructure. Si le scénario exige une validation sur appareil, confirmez séparément que votre méthode de test permet cet accès ; ne le déduisez pas de la seule disponibilité d’un Mac distant.

Pour une exécution ponctuelle, une machine Linux accompagnée d’un simulateur d’annulation interne peut sembler moins contraignante, mais elle ne remplace pas macOS et le parcours Apple requis pour produire et vérifier ce scénario. À l’inverse, louer un Mac n’est pas nécessaire si votre équipe dispose déjà d’un environnement macOS fiable et de la procédure Sandbox appropriée. Vous trouverez les informations sur les solutions Mac proposées par OSXPort si le blocage réel concerne la compilation ou la signature, plutôt que la configuration de Retention Messaging.

La décision est donc conditionnelle : si vos erreurs se trouvent dans les données d’abonnement, l’état de la message ou la logique de réponse serveur, corrigez d’abord ces éléments, car changer de machine ne les résoudra pas. Si votre équipe ne peut pas construire ou signer le paquet iOS faute d’un environnement macOS disponible, un Mac distant peut éviter l’achat d’une machine dédiée pour une période de test. Cette option implique néanmoins une dépendance à l’accès réseau et ne doit pas être présentée comme un accès garanti à un appareil physique.

Avant de choisir, comparez votre solution actuelle à un Mac distant sur les points qui affectent réellement la validation : disponibilité d’un environnement macOS/Xcode, contrôle des identifiants de signature, accès continu aux journaux et facilité de reproduction par l’équipe. Un poste partagé peut créer des conflits de disponibilité et compliquer la conservation d’un état de test ; une infrastructure non macOS ne permet pas de remplacer les outils macOS nécessaires à la construction. Le Mac distant apporte un environnement Mac accessible sans achat matériel, mais ne corrige ni une mauvaise association d’abonnement ni un serveur qui renvoie une réponse invalide. Si le manque d’environnement macOS est bien le frein, vous pouvez examiner l’option de location chez OSXPort ; si le défaut est dans le flux de test ou l’API, corrigez-le avant d’engager cette dépense.