ios amazon-web-services app-store itunesconnect alamofire

ios - Rechazo de la tienda de aplicaciones IPv6



amazon-web-services app-store (13)

Después de bastante estrés, puedo confirmar que el problema fue un problema con nuestro backend no configurado correctamente para IPv6. Aparentemente, AWS no admite IPv6, ni DNS solo IPv6 a través de Route53. Terminé moviendo todo el Internet hacia partes del back-end lejos de AWS por el momento.

Quería dejar esto en alto porque creo que probablemente habrá otros que se encuentren con problemas similares a medida que las personas comiencen a enviar actualizaciones más allá 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/

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á 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 red ipv6 en [ 1 ], que es el enlace que se proporcionó en el aviso de rechazo. Parece que tampoco soy el único que experimenta este problema [ 2 ].


Esta es la segunda vez que encuentro este problema después de 6 meses. Anteriormente estaba en el proyecto Objective-C usando 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é 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á utilizando. Está en la clase NetworkReachabilityManager.

Encontré esta respuesta de la siguiente fuente.

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

EDITAR: - 24 de junio -

Esto me ayudó muchas veces, pero también hay una solución extraña para 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 funciona bien con la opción de compartir wifi conectada a una red NAT64 creada en una Mac. Apelamos la revisión del video y aprobaron la solicitud. Entonces, si ha terminado con todas sus opciones, pruebe esta también.


He realizado la prueba para IPv6 DNS64/NAT64 sin 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 conectividad, descargar desde testflight, conexión de red NAT64, operaciones de aplicaciones)
  • y apelar al rechazo con el archivo de video

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



Me encontré con el mismo rechazo de aplicaciones al usar 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, se enfrentará a 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()


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

He archivado un radar sobre la discrepancia entre la documentación para las pruebas y la configuración que está utilizando App Review: solo pudimos diagnosticarlo porque nuestro CTO estaba en WWDC y podía conectarse a su red, lo cual 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.

He realizado 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 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


Nuestra aplicación es rechazada la primera vez, configuramos el entorno de prueba local basado en el documento de Apple y descubrimos que nuestro curl lib es demasiado antiguo sin habilitar ipv6 de forma predeterminada. Así que creamos la última versión de curl lib y funciona. Pero se rechaza 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 decirle 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 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.



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

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

Tenga en cuenta que las redes compatibles solo con IPv6 y el enlace IPv6 y App Review 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 utilizada por App Review", es por eso que todo puede funcionar en el entorno de prueba y aún tener 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 hacer que te tropieces si tu servidor dice que es compatible con IPv6, pero ese soporte de IPv6 no funciona. 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.

Añado esto como referencia y punto de partida para otros usuarios que experimentan el mismo problema


mi aplicación es rechazada dos veces en la tienda de aplicaciones. Dan un error al inicio de sesión de Twitter en un iPhone que tiene el sistema operativo 11.4. El problema principal que tenemos es 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, esa vez 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, se produce el error prohibido 403.

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

Gracias


nos encontramos con el mismo problema。 Nuestra aplicación ha sido rechazada en tiempos de servicio por razones ipv6. Pero hemos sido probados en la red ipv6 que se configuó como el documento oficial de APPLE: 1