Rejet du magasin d'applications IPv6

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

L'application ne fait que des requêtes réseau https à api.metooapp.io, qui est correctement configuré pour ipv6 [ 0 ] et exécute 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 sur [ 1 ], qui est le lien fourni dans l'avis de rejet. Il semble que je ne sois pas le seul à avoir ce problème [ 2 ].

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

    Je voulais laisser tomber cela parce que je pense qu'il y aura probablement d'autres qui se retrouvent avec des problèmes similaires à mesure que les gens commencent à soumettre des mises à jour après la ressortingction IPv6 seulement. Le meilleur outil que j'ai trouvé pour tester la disponibilité du server / DNS a été: http://ready.chair6.net/

    Veuillez noter que la prise en charge des réseaux IPv6 uniquement et du lien IPv6 et App Review peut être très utile pour déterminer quel est le problème avec les rejets d'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 celui utilisé par App Review", c'est pourquoi tout fonctionne dans l'environnement de test. l'application rejetée.

    De plus:

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

    Donc, si votre server dorsal 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 une reference et un sharepoint départ pour d'autres users qui rencontrent le même problème

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

    J'ai déposé un radar sur la divergence entre la documentation à tester et la configuration utilisée par App Review – nous avons seulement pu la diagnostiquer car notre CTO était à la WWDC et a pu se connecter à leur réseau, ce qui n'est pas exactement une situation nous pouvons reproduire régulièrement.

    nous avons rencontré le même problème.Notre application a été rejetée serval fois pour raison ipv6. Mais Nous avons été testé sur le réseau ipv6 qui a été configuré comme document officiel d'Apple: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/ uid / TP40010220-CH213-SW1

    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 curl lib est trop ancienne sans activer ipv6 par défaut. Nous construisons donc la dernière version de curl lib et cela fonctionne. Mais il est rejeté à nouveau pour la même raison. Je vérifie beaucoup d'informations, je trouve quelqu'un qui a la même expérience, je me plains au critique d'Apple pour dire que votre application fonctionne bien dans un environnement de test et je request à un ingénieur de l'aider s'il insiste sur une erreur. L'équipe d'Apple a approuvé notre application le week-end quand ils ont vu nos plaintes.

    Comme je sais, il y a 2 problèmes à vérifier. Avez-vous une adresse IP fixe dans votre application? Configurez-vous votre logging AAAA pour votre domaine de server pour montrer qu'il supporte ipv6, mais votre server n'écoute pas ipv6. Si oui, supprimez simplement cet logging AAAA dans les parameters de votre domaine à partir du site de votre fournisseur de domaine.

    Nous avons rencontré une situation similaire. Notre application a été rejetée en raison de problèmes de connectivité dans les réseaux IPv6. De plus, nos servers utilisent AWS.

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

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

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

    La bibliothèque d'accessibilité doit prendre en charge les parameters réseau IPv6. Donc, utilisez cette class d'accessibilité.

    https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007324

    C'est la deuxième fois que j'ai rencontré ce problème après 6 mois. Auparavant, c'était dans le projet Objective-C utilisant AFNetworking et j'ai utilisé cette solution et cela a fonctionné en une fois. Maintenant, même chose avec Alamofire. Les gars cette solution a fonctionné pour moi 2 fois et j'ai trouvé que cette question vient d'abord dans google ainsi je signale la réponse.

    Recherchez dans l'espace de travail pour AF_INET et remplacez-le par AF_INET6 partout où vous avez trouvé. Je pense qu'il doit être dans la bibliothèque AFNetworking ou dans la bibliothèque Alamofire si vous l'utilisez. C'est dans la class 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 y a aussi une étrange solution à ce problème. Dans notre projet récent, nous avons appliqué cette solution mais Apple a quand même rejeté l'application. Ensuite, nous avons fait une video qui montre que l'application fonctionne bien avec connecté à un réseau NAT64 créé sur un Mac à partir de l'option de partage wifi. Nous avons lancé un appel pour la révision avec la video et ils ont approuvé la request. Donc, si vous avez terminé avec toutes vos options, essayez celui-ci aussi.

    J'ai effectué Test pour IPv6 DNS64/NAT64 sans aucun problème tel que prescrit par la documentation Apple

    Cependant, nous ne sums pas en mesure de reproduire le problème (Crash). Nous avons réussi à installer l'application dans nos appareils sans accidents.

    • Nous avons pris une video de ce process de test total (qui inclut la connectivité, le téléchargement depuis testflight, la connection réseau NAT64, les opérations de l'application)
    • et appel au rejet avec le file video

    Enfin , app store APPROUVE mon application

    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 se déconnecter de l'user à la fin d'une session. Sinon, vous devrez faire face à des rejets d'applications similaires à l'avenir. J'ai inclus le code ci-dessous pour aider ceux qui pourraient rencontrer des problèmes similaires.

     let loginManager = FBSDKLoginManager() loginManager.logOut()