Rechazo de la App Store de IPv6


89

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


¿Está usando AFNetworking(si es así, qué versión)? Reachability? Bibliotecas de terceros?
Brandon

Alamofire 3.4.0 y Reachability.swift , pero la forma en que estoy usando Reachability es solo para tareas en segundo plano opcionales. Mi problema principal es que no puedo reproducir esto, incluso después de seguir las instrucciones de Apple.
Sean Thielen

Agregue su código de red también en la pregunta
error2007s

@ error2007s El código de red es Alamofire
Sean Thielen

1
¿Compraste el último dongle IPv6 de Apple?
anders

Respuestas:


37

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/


2
¿Puede decirme si la causa del rechazo de la App Store fue que sus servidores no admitían tráfico IPv6? Tengo 3 rechazos seguidos ahora de Apple, pero mi código no ha cambiado con respecto a versiones anteriores. Estoy usando Xamarin iOS y también actualicé su complemento de conectividad a la última versión porque tenían problemas con IPv6. ¡Me estoy desesperando! No puedo replicar el bloqueo en mis dispositivos iOS aquí (incluso en una red NAT64 IPV6 a través del uso compartido de Internet de mi Mac).
Jon

este rechazo es causado en su servidor, su servidor no es compatible con ipv6. Mangist
Pablo Ruan

Hola @Sean Thielan, he probado nuestro servidor con ready.chair6.net y falla para la conectividad de red IPV6, pero la aplicación funcionaba bien con el mismo servidor que probamos creando una red NAT64 (para red IPV6) en nuestro Dispositivo iPhone 5S con versión 10.0.2 del sistema operativo, ¿puede guiarnos para lo siguiente? ¿Necesitamos volver a enviar la aplicación a la tienda de aplicaciones o contactar con el soporte técnico de Apple? ¿O necesitamos configurar nuestro servidor para que admita la red IPV6?
Venkatesh

Hola @Venkatesh, ¿encontró una solución para este problema porque estoy atrapado con el rechazo de Apple en el mismo caso?
Mohamed Fadl Allah

hola Sean. Probé mis API. No pasa estas tres pruebas .. DNS (IPv6 NS) DNS (Registro MX) DNS (Glue) .. El resultado de esas tres es WARN. ¿Es ese problema que Apple está rechazando mi aplicación? Es necesario pasar todas las pruebas de dominio .. en ready.chair6.net ?????
JAck

11

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.


10

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.


Interesante. Tenía Route53 configurado de la misma manera, con el registro AAAA alias a un ELB. Quizás en la próxima versión menor lo vuelva a intentar en AWS, pero sin el registro AAAA. La sección de resultados de su radar refleja con precisión mis propias experiencias. En un momento dado, restablecí de fábrica un enrutador, una macbook y un iPhone para asegurarme por completo de que no era un problema absurdo de almacenamiento en caché. Seguiría investigando, pero estoy feliz de que la actualización se haya realizado y espero no volver a pensar en ello nunca más.
Sean Thielen

¿Recibiste alguna respuesta de Apple a tu radar?
Kaiserludi

1
@Kaiserludi no oficialmente, aunque he visto que en los foros de desarrollo si buscas algunas publicaciones de Quinn The Eskimo, las ha estado actualizando con mucha más información para ayudarte a depurar. Este parece particularmente útil: forums.developer.apple.com/message/147579#147579
DesignatedNerd

Muchas gracias. Ese enlace es realmente muy informativo.
Kaiserludi

6

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.


5

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


6
¿Has encontrado una solución a esto? No puedo hacer que Apple acepte la revisión de mi aplicación y no tengo ideas
Jon

5

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.



2

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.



1

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


1
asegúrese de que su aplicación no tenga ninguna dirección IP codificada en la aplicación, incluidos los complementos
Phani Sai

0

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

0

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.

Probé la ruta del video. Les mostró configurando mi Mac como wifi IPV6, conectando mi teléfono y ejecutando mi aplicación sin problema. Acabo de recibir otro rechazo de ellos, diciendo "Gracias por su respuesta. Durante nuestra revisión, descubrimos que su aplicación todavía se inicia en una pantalla blanca, incluso cuando se está probando en varios dispositivos". Luego sigue los consejos sobre cómo realizar pruebas con redes IPV6; Estos son los mismos pasos que les mostré en mi video. En general, parecía que la respuesta podría estar automatizada. ¿Cómo tratar con una persona real del equipo de revisión de Apple?
ChillyPenguin

Quizás devprograms@apple.com.
Steve Ham

0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.