Rejet de l'App Store IPv6


89

Notre mise à jour a été rejetée deux fois aujourd'hui pour des problèmes de connectivité réseau ipv6. Notre code de mise en réseau n'a pas changé entre la version précédente et cette version actuelle.

L'application ne fait que des requêtes réseau https à api.metooapp.io, qui est correctement configuré pour ipv6 [ 0 ] et s'exécute derrière route53 sur AWS. Il n'y a pas d'adresses IP codées en dur dans le code.

Je suis incapable de reproduire ce problème, même après avoir suivi les étapes pour créer un réseau ipv6 à [ 1 ] qui est le lien qui a été fourni dans l'avis de rejet. Il semble que je ne sois pas le seul à rencontrer ce problème [ 2 ].


Utilisez-vous AFNetworking(si oui, quelle version)? Reachability? Bibliothèques tierces?
Brandon

Alamofire 3.4.0 et Reachability.swift , mais la façon dont j'utilise l'accessibilité est juste pour les tâches d'arrière-plan facultatives. Mon principal problème est que je ne parviens pas à reproduire cela, même après avoir suivi les instructions d'Apple.
Sean Thielen

Ajoutez également votre code de réseau dans la question
error2007s

@ error2007s Le code réseau est Alamofire
Sean Thielen

1
avez-vous acheté le dernier dongle Apple IPv6?
anders

Réponses:


37

Après un peu de stress, je peux confirmer que le problème était lié au fait que notre backend n'était pas correctement configuré pour IPv6. Apparemment, AWS ne prend pas en charge IPv6, ni le DNS IPv6 uniquement via Route53. J'ai fini par déplacer tous les bits Internet du backend d'AWS pour le moment.

Je voulais laisser cela en place parce que je pense qu'il y en aura probablement d'autres qui se retrouveront avec des problèmes similaires lorsque les gens commenceront à soumettre des mises à jour au-delà de la restriction IPv6 uniquement. Le meilleur outil que j'ai trouvé pour tester la préparation du serveur / DNS a été: http://ready.chair6.net/


2
Pouvez-vous me dire si la cause du rejet de l'App Store était que vos serveurs ne supportaient pas le trafic IPv6? J'ai maintenant 3 refus consécutifs d'Apple mais mon code n'a pas changé par rapport aux versions précédentes. J'utilise Xamarin iOS et j'ai également mis à jour leur plug-in de connectivité vers la dernière version car ils ont eu des problèmes avec IPv6. Je deviens désespéré! Je ne peux pas reproduire le crash sur mes appareils iOS ici (même sur un réseau NAT64 IPV6 via le partage Internet de mon Mac).
Jon

ce rejet est provoqué dans votre serveur, votre serveur ne prend pas en charge ipv6. Mangist
Pablo Ruan

Salut @Sean Thielan, j'ai testé notre serveur avec ready.chair6.net et il échoue pour la connectivité réseau IPV6, mais l'application fonctionnait bien avec le même serveur que nous avons testé en créant un réseau NAT64 (pour le réseau IPV6) sur notre Appareil iPhone 5S avec la version du système d'exploitation 10.0.2, pouvez-vous guider pour ce qui suit, devons-nous soumettre à nouveau l'application à l'App Store ou contacter le support technique Apple. Ou bien devons-nous configurer notre serveur pour prendre en charge le réseau IPV6?
Venkatesh

Salut @Venkatesh avez-vous trouvé une solution à ce problème car je suis bloqué par le rejet d'Apple dans le même cas?
Mohamed Fadl Allah

bonjour Sean. J'ai testé mes API. Il échoue ces trois tests .. DNS (IPv6 NS) DNS (MX Record) DNS (Glue) .. Le résultat de ces trois tests est WARN. est ce problème qu'Apple rejette mon application. ?? Il est nécessaire de passer tous les tests du domaine .. sur ready.chair6.net ?????
JAck

11

Veuillez noter que le lien Prise en charge des réseaux IPv6 uniquement et IPv6 et examen des applications peut être très utile pour déterminer quel est le problème des rejets Apple. Dans ce cas précis, les articles indiquent clairement que vous pouvez configurer le réseau de test DNS64 / NAT64 mais que "Ce réseau de test n'est pas exactement le même que le réseau utilisé par App Review", c'est pourquoi tout peut fonctionner dans l'environnement de test et l'application a été rejetée.

De plus:

Le réseau App Review, comme les réseaux déployés par les fournisseurs de services, prend en charge la connectivité IPv6 vers IPv6. Ainsi, si votre serveur prend en charge IPv6, votre application lui parlera directement, sans passer par le traducteur NAT64. C'est, en général, une bonne chose, mais cela peut vous tromper si votre serveur prétend prendre en charge IPv6 mais que le support IPv6 est interrompu. Par exemple, si: le nom DNS est incorrect, le DNS est correct mais le serveur n'écoute pas sur IPv6, le serveur écoute sur IPv6 mais échoue lorsqu'une demande arrive sur IPv6

Donc, si votre serveur backend prend en charge IPv6, le réseau de test Apple l'utilisera, et c'est ce qui ne va pas dans ce cas.

J'ajoute ceci comme référence et point de départ pour les autres utilisateurs qui rencontrent le même problème


10

Nous avons rencontré le même problème, et il s'est avéré que pendant que nous avions configuré un enregistrement AAAA pour IPv6, puisque nous n'avions pas réellement de support IPv6 (nous utilisons également Route53), cela a tout dérangé. La suppression de l'enregistrement AAAA a résolu le problème.

J'ai déposé un radar sur l'écart entre la documentation pour les tests et la configuration qu'utilise App Review - nous n'avons pu le diagnostiquer que parce que notre CTO était à la WWDC et a pu se connecter à son réseau, ce qui n'est pas exactement une situation on peut se reproduire régulièrement.


Intéressant. J'ai fait configurer Route53 de la même manière, avec l'enregistrement AAAA aliasé sur un ELB. Peut-être que dans la prochaine version mineure, je vais l'essayer sur AWS, mais sans l'enregistrement AAAA. La section des résultats de votre radar reflète fidèlement mes propres expériences. À un moment donné, j'ai réinitialisé un routeur, un macbook et un iPhone afin de m'assurer complètement qu'il ne s'agissait pas d'un problème de mise en cache absurde. Je continuerais d'enquêter, mais je suis juste heureux que la mise à jour ait été effectuée et j'espère ne plus jamais y penser.
Sean Thielen

Avez-vous reçu une réponse d'Apple à votre radar?
Kaiserludi

1
@Kaiserludi pas officiellement, même si j'ai vu que dans les forums de développement, si vous recherchez des messages de Quinn The Eskimo, il les a mis à jour avec beaucoup plus d'informations pour vous aider à déboguer. Celui-ci semble particulièrement utile: forums.developer.apple.com/message/147579#147579
DesignatedNerd

Merci beaucoup. Ce lien est en effet très instructif.
Kaiserludi

6

Nous avons rencontré une situation similaire. Notre application a été rejetée en raison de problèmes de connectivité dans les réseaux IPv6. Nos serveurs utilisent également AWS.

J'ai effectué un test pour IPv6 DNS64 / NAT64 sans aucun problème de mon côté, et nous décidons de faire appel à ce rejet.

Nous avons expliqué que le test de notre côté s'est terminé avec succès et que nous utilisons l'infrastructure AWS.

Après deux jours supplémentaires, l'application a de nouveau été examinée et acceptée


5

nous avons rencontré le même problème。 Notre application a été rejetée fois pour des raisons d'ipv6. Mais nous avons été testés dans le réseau ipv6 qui a été configuré en tant que document officiel d'APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparinglefort.html uid / TP40010220-CH213-SW1


6
Avez-vous trouvé une solution à cela? Je ne peux pas faire accepter l'avis de mon application par Apple et je suis à court d'idées
Jon

5

Notre application est rejetée la première fois, nous configurons l'environnement de test local basé sur le document Apple et trouvons que notre bibliothèque curl est trop ancienne sans activer ipv6 par défaut. Nous construisons donc la dernière bibliothèque curl et cela fonctionne. Mais il est de nouveau rejeté pour la même raison. Je vérifie beaucoup d'informations, je trouve que quelqu'un a eu la même expérience, il suffit de se plaindre au réviseur Apple pour dire que votre application fonctionne bien dans l'environnement de test et de leur demander de fournir un ingénieur pour les aider s'ils insistent sur le fait qu'il y a une erreur. L'équipe d'examen Apple a approuvé notre application ce week-end lorsqu'elle a vu nos plaintes.

Comme je le sais, il y a 2 problèmes que vous devez vérifier. Codez-vous l'adresse IP en dur dans votre application? Configurez-vous votre enregistrement AAAA pour votre domaine de serveur pour montrer qu'il prend en charge ipv6, mais votre serveur n'écoute pas ipv6. Si oui, supprimez simplement cet enregistrement AAAA dans les paramètres de votre domaine à partir du site de votre fournisseur de domaine.



2

C'est la deuxième fois que je rencontre ce problème après 6 mois. Auparavant, c'était dans un projet Objective-C utilisant AFNetworking et j'ai utilisé cette solution et cela a fonctionné en une seule fois. Maintenant, la même chose s'est produite avec Alamofire. Les gars, cette solution a fonctionné pour moi 2 fois et j'ai trouvé que cette question venait en premier dans Google, donc je poste la réponse.

Recherchez AF_INET dans l'espace de travail et remplacez-le par AF_INET6 partout où vous l'avez trouvé. Je pense qu'il doit être dans la bibliothèque AFNetworking ou la bibliothèque Alamofire si vous l'utilisez. C'est dans la classe NetworkReachabilityManager.

J'ai trouvé cette réponse de la source ci-dessous.

https://stackoverflow.com/a/38196337/4030971

EDIT: - 24 juin -

Cela m'a aidé tellement de fois, mais il existe également une solution étrange à ce problème. Dans notre récent projet, nous avons appliqué cette solution, mais Apple a toujours rejeté la demande. Ensuite, nous avons fait une vidéo qui montrait que l'application fonctionnait bien avec une connexion à un réseau NAT64 créé sur un Mac à partir de l'option de partage wifi. Nous avons lancé un appel pour examen avec la vidéo et ils ont approuvé la demande. Donc, si vous avez terminé toutes vos options, essayez celle-ci aussi.



1

J'ai effectué le test IPv6 DNS64/NAT64sans aucun problème, comme prescrit par la documentation Apple

cependant, nous ne pouvons pas reproduire le problème (Crash). Nous avons réussi à installer l'application sur nos appareils sans plantages.

  • Nous avons pris une vidéo de ce processus de test total (qui comprend la présentation de la connectivité, le téléchargement à partir de testflight, la connexion réseau NAT64, les opérations de l'application)
  • et appel au rejet avec le fichier vidéo

Enfin , l'App Store a APPROUVÉ mon application


1
assurez-vous que votre application n'a pas d'adresse IP codée en dur dans l'application, y compris les plugins
Phani Sai

0

J'ai rencontré le même rejet d'application lors de l'utilisation du SDK Facebook. Si vous utilisez le SDK Facebook pour vous connecter, il est extrêmement important de déconnecter l'utilisateur lors de la fin d'une session. Sinon, vous serez confronté à des refus d'applications similaires à l'avenir. J'ai inclus le code ci-dessous pour aider ceux qui peuvent rencontrer des problèmes similaires.

let loginManager = FBSDKLoginManager()
loginManager.logOut()

0

J'ai résolu le problème en leur envoyant une vidéo, montrant que mon application fonctionne sur ipv6.

  1. Configurer ipv6 avec votre macOS
  2. Bande vidéo que vous êtes connecté au réseau IPv6 partagé et prouvez que votre application fonctionne dans cet environnement.

J'ai essayé la route vidéo. Il leur a montré que je configurais mon Mac en tant que wifi IPV6, y connectais mon téléphone et exécutais mon application sans problème. Je viens de recevoir un autre rejet de leur part, en disant "Merci pour votre réponse. Lors de notre examen, nous avons constaté que votre application se lance toujours sur un écran blanc, même si elle est testée sur plusieurs appareils". Suit ensuite les conseils sur la façon de tester avec les réseaux IPV6; ce sont les mêmes étapes que je leur avais montrées dans ma vidéo. Dans l'ensemble, la réponse semblait être automatisée. Comment traiter avec une vraie personne de l'équipe de révision Apple?
ChillyPenguin

Peut-être devprograms@apple.com.
Steve Ham

0

mon application est rejetée deux fois sur l'App Store. Ils donnent une erreur lors de la connexion Twitter sur l'iPhone ayant l'os 11.4. Le principal problème que nous avons à cause de l'URL de rappel de Twitter, qui n'est pas définie sur le compte développeur de Twitter. lorsque je définis l'URL de rappel sur le compte développeur de Twitter. Cela résout mon problème. Lorsque nous ne définissons pas d'URL de rappel sur le compte du développeur de Twitter, la connexion à Twitter est réussie lorsque l'appareil dispose d'une application Twitter. mais en cas d'absence de l'application Twitter sur l'appareil, l'erreur 403 est interdite.

Donc, la définition de l'URL de rappel résout mon problème et l'application est acceptée.

Je vous remercie

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.