Rechazo de la tienda de aplicaciones IPv6

Nuestra actualización ha sido rechazada dos veces hoy para los problemas de conectividad de networking de ipv6. Nuestro código de networking no ha cambiado entre la versión anterior y esta versión actual.

La aplicación solo realiza requestes de networking https a api.metooapp.io, que está configurada correctamente para ipv6 [ 0 ] y se ejecuta detrás de route53 en AWS. No hay direcciones IP codificadas en el código.

No puedo reproducir este problema, incluso después de seguir los pasos para crear una networking ipv6 en [ 1 ], que es el enlace que se proporcionó en el aviso de rechazo. Parece que no soy el único que experimenta este problema, [ 2 ].

Después de un poco de estrés, puedo confirmar que el problema era un problema con nuestro backend no configurado correctamente para IPv6. Aparentemente, AWS no es compatible con IPv6, ni DNS con solo IPv6 a través de Route53. Terminé moviendo todos los bits de Internet del lado del backend lejos de AWS por el momento.

Quería dejar esto porque creo que probablemente haya otros que se encuentren con problemas similares cuando las personas comienzan a enviar actualizaciones más allá de la restricción solo de IPv6. La mejor herramienta que encontré para probar la preparación del server / dns ha sido: http://ready.chair6.net/

Tenga en count que la compatibilidad con las networkinges solo IPv6 y el enlace IPv6 y revisión de aplicaciones puede ser muy útil para determinar cuál es el problema con los rechazos de Apple. En este caso específico, los artículos indican claramente que puede configurar la networking de testing DNS64 / NAT64 pero que "esta networking de testing no es exactamente la misma que la utilizada por la Revisión de aplicaciones", por eso todo puede funcionar en el entorno de testing y aún así la aplicación rechazada

Además:

La networking App Review, como las networkinges desplegadas por los proveedores de services, admite la conectividad IPv6 a IPv6. Por lo tanto, si su server admite IPv6, su aplicación hablará directamente con él, sin pasar por el traductor NAT64. Esto es, en general, una buena cosa, pero puede hacerte tropezar si tu server dice ser compatible con IPv6, pero ese soporte de IPv6 está roto. Por ejemplo, si: el nombre DNS es incorrecto, el DNS es correcto, pero el server no escucha en IPv6, el server escucha en IPv6, pero falla cuando una request entra en IPv6

Entonces, si su server back-end tiene soporte para IPv6, la networking de testing Apple lo usará, y es lo que ha estado mal en este caso.

Agrego esto como reference y punto de partida para otros usuarios que experimentan el mismo problema

Nos topamos con el mismo problema, y ​​resultó que mientras habíamos configurado un logging AAAA para IPv6, ya que en realidad no contábamos con soporte para IPv6 (también usamos Route53), lo solucionó todo. Eliminar el logging de AAAA solucionó el problema.

Archivé un radar sobre la discrepancia entre la documentation para las testings y la configuration que está utilizando la Revisión de la aplicación, solo pudimos diagnosticarla porque nuestro CTO estaba en WWDC y pudo conectarse a su networking, lo cual no es exactamente una situación Podemos reproducirlo regularmente.

Nuestra aplicación se rechaza la primera vez, configuramos el entorno de testing local basado en el documento de Apple y encontramos que nuestro curl lib es demasiado antiguo sin habilitar ipv6 por defecto. Entonces construimos la última versión de curl lib y funciona. Pero es rechazado nuevamente por la misma razón. Reviso mucha información, encuentro a alguien que haya tenido la misma experiencia, solo se queja al revisor de Apple para decir que su aplicación funciona bien en un entorno de testing y pedirle que le brinde un ingeniero para que lo ayude si insisten en que hay algún error. El equipo de revisión de Apple aprobó nuestra aplicación el fin de semana cuando vieron nuestras quejas.

Como sé que hay 2 problemas que necesitas revisar. ¿Tiene dirección IP de código duro en su aplicación? ¿Configura su logging AAAA para su dominio de server para mostrar que es compatible con ipv6, pero su server no escucha ipv6. En caso afirmativo, simplemente elimine ese logging de AAAA en la configuration de su dominio del sitio del proveedor de su dominio.

nos encontramos con el mismo problema. Nuestra aplicación ha sido rechazada por razones de ipv6. Pero hemos sido testeados en la networking ipv6 que se configuró como documento oficial de APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/ uid / TP40010220-CH213-SW1

Nos encontramos con una situación similar. Nuestra aplicación fue rechazada debido a problemas de conectividad en las networkinges IPv6. También nuestros serveres están utilizando AWS.

He realizado Test for IPv6 DNS64 / NAT64 sin ningún inconveniente por mi parte, y decidimos presentar una apelación a este rechazo.

Explicamos que la testing de nuestro lado terminó con éxito y que estamos utilizando la infraestructura de AWS.

Después de dos días más la aplicación fue nuevamente revisada y aceptada

La biblioteca de accesibilidad debe ser compatible con la configuration de networking IPv6. Entonces, use esta class de scope.

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

Esta es la segunda vez que me he encontrado con este problema después de 6 meses. Anteriormente fue en el proyecto Objective-C utilizando AFNetworking y usé esta solución y funcionó de una vez. Ahora mismo sucedió con Alamofire. Chicos, esta solución me funcionó 2 veces y encontré esta pregunta que viene primero en google, así que estoy publicando la respuesta.

Busque en el espacio de trabajo para AF_INET y cámbielo a AF_INET6 en cualquier lugar que encuentre. Creo que debe estar dentro de la biblioteca AFNetworking o la biblioteca Alamofire si la estás usando. Está en la class NetworkReachabilityManager.

Encontré esta respuesta de la siguiente fuente.

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

EDITAR: – 24 de junio –

Esto me ayudó tantas veces, pero también hay una solución extraña a este problema. En nuestro proyecto reciente, hemos aplicado esta solución, pero Apple rechazó la aplicación. Luego hicimos un video que mostraba que la aplicación se está ejecutando bien conectada a una networking NAT64 creada en una Mac desde la opción de compartir wifi. Solicitamos la revisión con el video y aprobaron la request. Entonces, si has terminado con todas tus opciones, testing esta también.

He realizado la testing para IPv6 DNS64/NAT64 sin ningún problema según lo prescrito por la documentation de Apple

Sin embargo, no podemos reproducir el problema (Crash). Implementamos exitosamente la aplicación en nuestros dispositivos sin fallas.

  • Tomamos un video de este process de testing total (que incluye mostrar la conectividad, la descarga desde el testflight, la connection de networking NAT64, las operaciones de la aplicación)
  • y apelar por el rechazo con el file de video

Finalmente , la tienda de aplicaciones APROBÓ mi aplicación

Me encontré con el mismo rechazo de la aplicación al usar Facebook SDK. Si está utilizando el Facebook SDK para iniciar session, es increíblemente importante que cierre session cuando finalice una session. De lo contrario, se enfrentará a rechazos de aplicaciones similares en el futuro. He incluido el código a continuación para ayudar a aquellos que pueden estar experimentando problemas similares.

 let loginManager = FBSDKLoginManager() loginManager.logOut()