Rechazo de la tienda de aplicaciones IPv6

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

La aplicación solo realiza solicitudes de red https a api.metooapp.io, que está configurado 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 red ipv6 en [ 1 ], que es el enlace que se proporcionó en el aviso de rechazo. Parece que no soy el único que está experimentando este problema, tampoco [ 2 ].

Después de un poco de estrés, puedo confirmar que el problema era un problema con nuestro servidor no configurado correctamente para IPv6. Aparentemente, AWS no es compatible con IPv6, ni DNS solo IPv6 a través de Route53. Terminé moviendo todas las partes del backend de Internet alejadas de AWS por el momento.

Quería dejar esto porque creo que probablemente haya otros que se encuentren con problemas similares a medida que las personas comiencen a enviar actualizaciones después de la restricción de solo IPv6. La mejor herramienta que encontré para probar la disponibilidad del servidor / DNS ha sido: http://ready.chair6.net/

Tenga en cuenta que el solo hecho de admitir redes IPv6 e IPv6 y el enlace 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 red de prueba DNS64 / NAT64 pero que “esta red de prueba no es exactamente la misma que la red utilizada por App Review”, es por eso que todo puede funcionar en el entorno de prueba y aún así la aplicación rechazada

Además:

La red App Review, al igual que las redes desplegadas por los proveedores de servicios, admite la conectividad IPv6 a IPv6. Por lo tanto, si su servidor admite IPv6, su aplicación le hablará directamente, sin pasar por el traductor de NAT64. Esto es, en general, algo bueno, pero puede hacer que se tropiece si su servidor dice que es compatible con IPv6 pero que la compatibilidad con IPv6 está rota. Por ejemplo, si: el nombre DNS es incorrecto, el DNS es correcto pero el servidor no está escuchando en IPv6, el servidor está escuchando en IPv6, pero falla cuando llega una solicitud a través de IPv6.

Entonces, si su servidor de back-end tiene soporte para IPv6, la red de prueba de apple lo usará, y es lo que ha estado mal en este caso.

Lo agrego como referencia y punto de partida para otros usuarios que experimentan el mismo problema

Nos encontramos con este mismo problema, y ​​resultó que habíamos configurado un registro AAAA para IPv6, ya que en realidad no teníamos soporte para IPv6 (también estamos usando Route53), lo corrige todo. La eliminación del registro AAAA solucionó el problema.

He archivado un radar sobre la discrepancia entre la documentación para probar y la configuración que App Review está usando, solo pudimos diagnosticarla porque nuestra CTO estaba en WWDC y pudimos conectarnos a su red, lo que no es exactamente una situación podemos reproducirnos regularmente

Nos encontramos con una situación similar. Nuestra aplicación fue rechazada debido a problemas de conectividad en redes IPv6. También nuestros servidores están usando AWS.

Realicé Test para IPv6 DNS64 / NAT64 sin ningún problema de mi parte, y decidimos enviar una apelación a este rechazo.

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

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

nos encontramos con el mismo problema. Nuestra aplicación ha sido rechazada por la razón ipv6. Pero hemos sido sometidos a prueba en la red de IPv6 que confiere el documento oficial de APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingForvIP6Transition/UnderstandingandPreparingForvIP6Transition.html#//apple_ref/doc/ uid / TP40010220-CH213-SW1

Nuestra aplicación se rechaza la primera vez, configuramos el entorno de prueba local basado en el documento de Apple y descubrimos que nuestra lib lib es demasiado antigua sin habilitar ipv6 de manera predeterminada. Así que construimos la última lib libl y funciona. Pero es rechazado nuevamente por la misma razón. Compruebo mucha información, encuentro que alguien tuvo la misma experiencia, solo le hago una queja al revisor de Apple para decir que su aplicación funciona bien en el entorno de prueba y les pido que proporcionen un ingeniero para ayudar 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 necesita comprobar. ¿Codifica duro la dirección IP en su aplicación? ¿Configura su registro AAAA para su dominio de servidor para mostrar que es compatible con ipv6, pero su servidor no escucha ipv6. En caso afirmativo, simplemente elimine ese registro AAAA en la configuración de su dominio del sitio de su proveedor de dominio.

La biblioteca de accesibilidad debe ser compatible con la configuración de red de IPv6. Entonces usa esta clase de Accesibilidad.

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

Realicé Test para IPv6 DNS64/NAT64 sin ningún problema según lo estipulado en la documentación de Apple

sin embargo, no podemos reproducir el problema (locking). Hemos instalado con éxito la aplicación en nuestros dispositivos sin fallas.

  • Tomamos un video de este proceso de prueba total (que incluye la demostración de conectividad, descarga de testflight, conexión de red NAT64, operaciones de la aplicación)
  • y apelar por el rechazo con el archivo de video

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

Esta es la segunda vez que me encuentro con este problema después de 6 meses. Anteriormente estaba en el proyecto Objective-C usando AFNetworking y utilicé esta solución y funcionó de una vez. Ahora mismo sucedió con Alamofire. Chicos esta solución me funcionó 2 veces y encontré que esta pregunta 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 de la biblioteca Alamofire si lo está usando. Está en la clase NetworkReachabilityManager.

Encontré esta respuesta de la siguiente fuente.

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

EDITAR: – 24 de junio –

Esto me ayudó muchas veces, pero también hay una extraña solución a este problema. En nuestro proyecto reciente, hemos aplicado esta solución, pero todavía Apple rechazó la aplicación. Luego hicimos un video que mostraba que la aplicación está funcionando bien con conexión a una red NAT64 creada en una Mac desde la opción de compartir wifi. Apelamos para una revisión con el video y ellos aprobaron la solicitud. Entonces, si terminaste con todas tus opciones, prueba esta también.

Puedes verificar tu API en el siguiente sitio web, ¡es tu API iPV6 configurada o no!

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

Me encontré con el mismo rechazo de la aplicación cuando uso el SDK de Facebook. Si está utilizando el SDK de Facebook para iniciar sesión, es increíblemente importante cerrar la sesión del usuario al finalizar una sesión. De lo contrario, enfrentarás rechazos de aplicaciones similares en el futuro. He incluido el código a continuación para ayudar a aquellos que puedan estar experimentando problemas similares.

 let loginManager = FBSDKLoginManager() loginManager.logOut() 

Resolví el problema enviándoles un video, que muestra que mi aplicación funciona en ipv6.

  1. Configura ipv6 con tus macOS
  2. Cinta de video que está conectado a la red ipv6 compartida y demostrar que su aplicación funciona en ese entorno.

mi aplicación es rechazada dos veces en la tienda de aplicaciones. Dan un error al inicio de sesión de twitter en el iPhone con el código os 11.4. El problema principal que tenemos es la URL de callback de twitter, que no está configurada en la cuenta de desarrollador de Twitter. cuando configuro la URL de callback en la cuenta de desarrollador de twitter. Soluciona mi problema. Cuando no establecemos la URL de callback en la cuenta de desarrollador de Twitter, esa vez, el inicio de sesión de Twitter es exitoso cuando el dispositivo tiene la aplicación de Twitter. pero en caso de ausencia de la aplicación de Twitter en el dispositivo se da el error prohibido 403.

Así que configurar la URL de callback supera mi problema y la aplicación es aceptada.

Gracias