iOS / iPhone: sandbox d'achat in-app cassé alors que l'application est dans l'état "rejeté"?

(Voir MAIN THRUST ci-dessous pour passer à l'essentiel de ma question.)

Mon application iOS a été rejetée dans le process de révision Apple pour une raison mineure qui a été facile à résoudre.

Cependant, je voulais donner un nouveau test à la nouvelle version, notamment en testant de nouveau notre achat embedded (il n'y a qu'un seul article pouvant être acheté dans l'application).

Et maintenant, l'application se bloque lors de la récupération initiale des informations sur le produit. Il ne s'est jamais écrasé de cette manière auparavant, et le code n'a pas changé depuis que nous avons testé avec succès l'achat in-app en mode bac à sable plusieurs fois. (En fait, aucun code n'a changé du tout entre la version initialement soumise et cette version avec le correctif mineur, le correctif était juste un changement de paramètre info.plist.)

Pour compliquer les choses, j'utilise le SDK Airplay / Marmalade pour la construction de l'application, et ils enveloppent le mécanisme d'appels et de callback Objective C avec leur propre mécanisme d'API et de callback. Cependant, cette enveloppe est très fine, donc j'espère / je crois que c'est vraiment une question d'achat générale iOS / in-app, pas quelque chose de spécifique à Marmalade.

Donc, comme je l'ai dit, il se bloque quelque part entre le moment où je fais l'appel Marmalade pour récupérer des informations sur le produit et le moment où mon callback (C ++) devrait être appelé. (C'est-à-dire, quelque part entre le moment où Marmalade appelle [startRequest] sur un object SKProductsRequest, et le moment où la fonction productsRequest: didReceiveResponse () est appelée et Marmalade me callbackle à son tour.)

MAIN THRUST de ma question:

Mon application est en état "rejeté" sur iTunesConnect. En outre, lorsque je regarde l'article d'achat embedded dans iTunesConnect, il est également marqué comme "Rejeté". Cependant, j'ai déjà discuté de mon achat via l'application avec Apple pendant le process de révision, et je crois que l'achat embedded à l'application fonctionne bien pour eux, et le seul problème restant est le problème mineur que j'ai déjà fixe (c'est ce que disent leurs détails de rejet: juste ce point).

Donc: Je dois comprendre si, lorsque mon application (et son achat embedded associé) est dans cet état "rejeté" en attendant un nouveau téléchargement binary de moi, il est difficile (ou peut-être impossible) de re-tester l'application embeddede acheter, et mon meilleur plan d'action est juste de resoumettre l'application avec le correctif mineur et avoir la foi que (puisque c'est le même code qui a fonctionné pendant le test normal lorsque les choses n'étaient pas dans l'état rejeté) l'état de l'in-app L'achat se fera une fois que Apple réinitialisera tout pour tester le nouveau binary.

Ou y at-il quelque chose de différent que je devrais faire à ce stade qui me permettrait de re-tester l'achat in-app?

Je pensais à requestr à Apple dans la correspondance iTunesConnect, mais je ne voulais pas introduire de complications avec eux, car le process d'examen a été incroyablement rapide et efficace jusqu'à présent.

J'ai reçu une réponse du support technique d'Apple à ce sujet:

Je réponds à votre question ci-dessous concernant l'in app purchase et le problème où le process de contrôle en amont du produit échoue maintenant. La réponse à ce problème est documentée dans la note technique 2259 – «Ajout de l'in app purchase à votre application iOS». http://developer.apple.com/library/ios/#technotes/tn2259/_index.html

Dans la section FAQ, vous findez la list des raisons suivantes pour ce problème

Pourquoi les identifiants de mes produits sont-ils renvoyés dans le tableau invalidProductIdentifiers? Vos identifiants de produit peuvent être returnnés dans le tableau invalidProductIdentifiers pour une ou plusieurs des raisons suivantes:

Vous n'avez pas rempli toutes les exigences financières (voir la section «Contrats, renseignements fiscaux et bancaires» de ce document). Vous n'avez pas utilisé d'identifiant d'application explicite. Vous n'avez pas utilisé le profil d'approvisionnement associé à votre identifiant d'application explicite. Vous n'avez pas utilisé l'identifiant de produit correct dans votre code. Pour plus d'informations sur les identificateurs de produit, reportez-vous à la section Questions techniques QA1329, «Identificateurs de produit d'achat d'applications». Vous n'avez pas effacé vos produits In App Purchase en vente dans iTunes Connect. Vous avez peut-être modifié vos produits, mais ces modifications ne sont pas encore disponibles pour tous les servers App Store. Si vous ou App Review avez rejeté votre file binary le plus récent dans iTunes Connect.

Notez la dernière raison – qui s'applique dans votre cas. La solution est la suivante: lorsque vous voulez tester l'application, vous devez download "temporairement" une copy de votre application sur iTunesConnect afin que l'état de l'application ne soit plus "rejeté". Au lieu de cela, il sera dans l'état "en attente d'examen". Allez-y et effectuez tous les tests dont vous avez besoin, puis en supposant que l'application a encore besoin de travail, rejetez l'application elle-même afin qu'elle n'atteigne pas la révision de l'application. À un certain moment, vous aurez un produit fini et vous soumettrez finalement la request formellement.

Cette réponse n'était pas totalement correcte dans mon cas. J'ai reçu une réponse séparée de la part de l'équipe de révision de l'application. Le simple téléchargement d'un nouveau file binary ne réinitialise pas l'état "rejeté" de l'article d'achat embedded à l'application. Apparemment, ils doivent réinitialiser manuellement eux-mêmes (à ce moment je crois que les deux et moi pouvons le tester). Donc actuellement j'ai mon nouveau binary téléchargé mais ils n'ont pas encore réinitialisé l'article d'achat in-app.

J'appendai plus à ce post quand le process est terminé …