Rechazo de la App Store de IPv6

Nuestra actualización ha sido rechazada dos veces hoy por problemas de conectividad de red 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 tampoco soy el único que tiene este problema [ 2 ].

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

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

Tenga en cuenta que la compatibilidad con redes solo IPv6 e IPv6 y el enlace de revisión de aplicaciones pueden ser muy útiles para determinar cuál es el problema con los rechazos de Apple. En este caso específico, los artículos establecen 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", por eso 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 implementadas por los proveedores de servicios, admite la conectividad IPv6 a IPv6. Por lo tanto, si su servidor admite IPv6, su aplicación se comunicará con él directamente, sin pasar por el traductor NAT64. Esto es, en general, algo bueno, pero puede hacerle tropezar si su servidor afirma que es compatible con IPv6 pero que no funciona con IPv6. 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 backend tiene soporte para IPv6, la red de prueba de Apple lo usará, y eso es lo que ha estado mal en este caso.

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

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

Presenté un radar sobre la discrepancia entre la documentación para las pruebas y la configuración que usa App Review; solo pudimos diagnosticarlo porque nuestro CTO estaba en WWDC y pudo conectarse a su red, lo cual no es exactamente una situación podemos reproducirnos con regularidad.

Nos encontramos con una situación similar. Nuestra aplicación fue rechazada debido a problemas de conectividad en redes IPv6. Además, nuestros servidores utilizan AWS.

Realicé la prueba para IPv6 DNS64 / NAT64 sin ningún problema por mi parte, y decidimos presentar una apelación a este rechazo.

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

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

nos encontramos con el mismo problema。 Nuestra aplicación ha sido rechazada por motivos de ipv6. Pero hemos sido probados en la red ipv6, que se confijó como documento oficial de APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparing/heIPml#doc//Transition uid / TP40010220-CH213-SW1

Nuestra aplicación es rechazada la primera vez, configuramos el entorno de prueba local basado en el documento de Apple y encontramos que nuestra lib curl es demasiado antigua sin habilitar ipv6 de forma predeterminada. Así que creamos la última lib curl y funciona. Pero es rechazado nuevamente por la misma razón. Verifico mucha información, encuentro que alguien tuvo la misma experiencia, solo me quejo 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é, hay 2 problemas que debe verificar. ¿Codifica la dirección IP en su aplicación? ¿Configura su registro AAAA para el dominio de su servidor para mostrar que admite ipv6, pero su servidor no escucha ipv6? Si es así, simplemente elimine ese registro AAAA en la configuración de su dominio del sitio de su proveedor de dominio.

La biblioteca de accesibilidad debe admitir la configuración de red IPv6. Entonces use esta clase de Accesibilidad.

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

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 pasó con Alamofire. Chicos, esta solución me funcionó 2 veces y encontré que esta pregunta es la primera en Google, así que estoy publicando la respuesta.

Busque en el espacio de trabajo 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á 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 Apple aún rechazó la solicitud. Luego hicimos un video que mostraba que la aplicación funciona bien con la conexión a una red NAT64 creada en una Mac desde la opción de compartir wifi. Solicitamos la revisión del video y aprobaron la solicitud. Entonces, si ha terminado con todas sus opciones, pruebe esta también.

Puede verificar su API en el siguiente sitio web, ¿está configurada su API iPV6 o no?

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

Realicé la prueba IPv6 DNS64/NAT64sin ningún problema según lo prescrito por la documentación de Apple

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

• Tomamos un video de este proceso de prueba total (que incluye mostrar la conectividad, descargar desde testflight, conexión de red NAT64, operaciones de la aplicación)
• y apelación de rechazo con el archivo de video

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

Me encontré con el mismo rechazo de la aplicación cuando usé el SDK de Facebook. Si está utilizando el SDK de Facebook para iniciar sesión, es muy importante que cierre la sesión del usuario al finalizar una sesión. De lo contrario, enfrentará rechazos de aplicaciones similares en el futuro. He incluido el siguiente código para ayudar a quienes puedan estar experimentando problemas similares.

let loginManager = FBSDKLoginManager()
loginManager.logOut()

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

1. Configura ipv6 con tu macOS
2. Grabe que está conectado a la red ipv6 compartida y demuestre 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 iPhone con sistema operativo 11.4. El problema principal que tenemos debido a la URL de devolución de llamada de Twitter, que no está configurada en la cuenta de desarrollador de Twitter. cuando configuro la URL de devolución de llamada en la cuenta de desarrollador de Twitter. Resuelve mi problema. Cuando no configuramos la URL de devolución de llamada en la cuenta de desarrollador de Twitter, el inicio de sesión de Twitter es exitoso cuando el dispositivo tiene una aplicación de Twitter. pero en caso de ausencia de la aplicación de Twitter en el dispositivo, aparece el error 403 prohibido.

Por lo tanto, configurar la URL de devolución de llamada soluciona mi problema y se acepta la aplicación.

Gracias