Rejet de l'App Store IPv6

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 ].

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/

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

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.

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

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

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.

La bibliothèque d'accessibilité doit prendre en charge les paramètres réseau IPv6. Utilisez donc cette classe 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 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.

Vous pouvez vérifier votre API sur le site Web ci-dessous, est-ce que votre API iPV6 est configurée ou non!

http://ipv6-test.com/validate.php

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

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()

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.

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