Rejeição da App Store IPv6

Nossa atualização foi rejeitada duas vezes hoje por problemas de conectividade de rede ipv6. Nosso código de rede não mudou entre a versão anterior e esta versão atual.

O aplicativo só faz solicitações de rede https para api.metooapp.io, que está configurado corretamente para ipv6 [ 0 ] e é executado por trás de route53 na AWS. Não há endereços IP embutidos no código.

Não consigo reproduzir esse problema, mesmo depois de seguir as etapas para criar uma rede ipv6 em [ 1 ], que é o link fornecido no aviso de rejeição. Parece que não sou o único com esse problema [ 2 ].

Depois de um pouco de estresse, posso confirmar que o problema era um problema com nosso back-end não configurado corretamente para IPv6. Aparentemente, a AWS não oferece suporte a IPv6, nem DNS somente IPv6 por meio do Route53. Acabei movendo toda a internet que enfrenta bits do back-end para longe da AWS por enquanto.

Eu queria deixar isso de lado porque acho que provavelmente haverá outros que terão problemas semelhantes quando as pessoas começarem a enviar atualizações além da restrição apenas ao IPv6. A melhor ferramenta que encontrei para testar a prontidão do servidor / dns foi: http://ready.chair6.net/

Por favor note que Apoiando apenas IPv6 Networks e IPv6 e App Review link pode ser muito útil para determinar qual é o problema com rejeições de maçã. Neste caso específico, os artigos afirmam claramente que você pode configurar a rede de teste DNS64 / NAT64, mas que "Esta rede de teste não é exatamente a mesma que a rede usada pelo App Review", é por isso que tudo pode funcionar no ambiente de teste e ainda ter o aplicativo foi rejeitado.

Além disso:

A rede App Review, assim como as redes implantadas por provedores de serviços, oferece suporte à conectividade IPv6 para IPv6. Assim, se seu servidor suportar IPv6, seu aplicativo se comunicará diretamente com ele, sem passar pelo tradutor NAT64. Isso é, em geral, uma coisa boa, mas pode enganá-lo se o seu servidor alegar suporte a IPv6, mas o suporte a IPv6 for interrompido. Por exemplo, se: o nome DNS está incorreto, o DNS está correto, mas o servidor não está escutando no IPv6, o servidor está escutando no IPv6, mas falha quando chega uma solicitação no IPv6

Portanto, se o seu servidor de back-end tiver suporte para IPv6, a rede de teste da apple irá usá-lo, e é isso que está errado neste caso.

Eu adiciono isso como uma referência e ponto de partida para outros usuários que enfrentam o mesmo problema

Encontramos este mesmo problema, e enquanto tínhamos configurado um registro AAAA para IPv6, já que não tínhamos suporte para IPv6 (também estamos usando Route53), ele funcionou em tudo. Remover o registro AAAA corrigiu o problema.

Eu arquivei um radar sobre a discrepância entre a documentação para teste e a configuração que o App Review está usando - nós só pudemos diagnosticar porque nosso CTO estava no WWDC e foi capaz de se conectar à sua rede, o que não é exatamente uma situação podemos reproduzir regularmente.

Corremos para uma situação semelhante. Nosso aplicativo foi rejeitado devido a problemas de conectividade em redes IPv6. Além disso, nossos servidores estão usando AWS.

Realizei o Teste para IPv6 DNS64 / NAT64 sem nenhum problema da minha parte e decidimos apresentar um recurso a esta rejeição.

Explicamos que o teste do nosso lado foi concluído com sucesso e que estamos usando a infraestrutura da AWS.

Depois de mais dois dias, o aplicativo foi revisado e aceito novamente

encontramos o mesmo problema。 Nosso aplicativo foi rejeitado vezes serval por motivo de ipv6. Mas temos sido testados na rede ipv6 que foi configurada como Documento oficial da APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingple_UnderstandingandPreparingple_IPv6//apition.html// uid / TP40010220-CH213-SW1

Nosso aplicativo foi rejeitado na primeira vez, configuramos o ambiente de teste local com base no documento da apple e descobrimos que nossa lib curl é muito antiga sem habilitar ipv6 por padrão. Então nós construímos a última lib do curl e ela funciona. Mas é rejeitado novamente pelo mesmo motivo. Eu verifico muitas informações, encontro alguém com a mesma experiência, apenas reclamo ao revisor da Apple para dizer que seu aplicativo funciona bem no ambiente de teste e peço a ele para fornecer um engenheiro para ajudar se insistir que há algum erro. A equipe de análise da Apple aprovou nosso aplicativo no fim de semana quando viram nossas reclamações.

Como eu sei, há 2 problemas que você precisa verificar. Você codifica o endereço IP em seu aplicativo? Você configurou seu registro AAAA para o domínio do servidor para mostrar que ele suporta ipv6, mas seu servidor não escuta ipv6. Em caso afirmativo, apenas remova esse registro AAAA nas configurações de domínio do site do seu provedor de domínio.

A biblioteca de acessibilidade deve oferecer suporte às configurações de rede IPv6. Portanto, use esta classe de acessibilidade.

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

Esta é a segunda vez que encontrei esse problema após 6 meses. Anteriormente, estava no projeto Objective-C usando AFNetworking e usei essa solução e funcionou de uma vez. Agora o mesmo aconteceu com Alamofire. Galera essa solução funcionou pra mim 2 vezes e achei que essa pergunta vem primeiro no google então estou postando a resposta.

Pesquise AF_INET na área de trabalho e altere-o para AF_INET6 em qualquer lugar que você encontrar. Acho que deve estar dentro da biblioteca AFNetworking ou da biblioteca Alamofire, se você estiver usando. Está na classe NetworkReachabilityManager.

Eu encontrei essa resposta na fonte abaixo.

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

EDITAR: - 24 de junho -

Isso me ajudou muitas vezes, mas também há uma solução estranha para esse problema. Em nosso projeto recente, aplicamos essa solução, mas ainda assim a apple rejeitou o aplicativo. Então fizemos um vídeo que mostrava que o aplicativo está funcionando bem conectado a uma rede NAT64 criada em um Mac a partir da opção de compartilhamento wi-fi. Apelamos para revisão com o vídeo e eles aprovaram a inscrição. Portanto, se você concluiu todas as suas opções, tente esta também.

Você pode verificar sua API no site abaixo, se sua API iPV6 está configurada ou não!

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

Executei o teste IPv6 DNS64/NAT64sem nenhum problema, conforme prescrito pela documentação da Apple

no entanto, não podemos reproduzir o problema (falha). Conseguimos instalar o aplicativo em nossos dispositivos sem travar.

• Gravamos um vídeo desse processo de teste total (que inclui mostrar a conectividade, baixar do testflight, conexão de rede NAT64, operações do aplicativo)
• e apelo de rejeição com o arquivo de vídeo

Finalmente , a app store APROVOU meu aplicativo

Encontrei a mesma rejeição do aplicativo ao usar o SDK do Facebook. Se você estiver usando o SDK do Facebook para fazer login, é extremamente importante fazer o logout do usuário ao encerrar uma sessão. Caso contrário, você enfrentará rejeições de aplicativos semelhantes no futuro. Incluí o código abaixo para ajudar aqueles que podem estar enfrentando problemas semelhantes.

let loginManager = FBSDKLoginManager()
loginManager.logOut()

Resolvi o problema enviando um vídeo para eles, mostrando que meu aplicativo funciona em ipv6.

1. Configure o ipv6 com seu macOS
2. Grave em vídeo que você está conectado à rede ipv6 compartilhada e prove que seu aplicativo funciona naquele ambiente.

meu aplicativo foi rejeitado duas vezes na app store. Eles dão um erro de login do twitter no iphone com sistema operacional 11.4. O principal problema que temos é por causa da url de retorno de chamada do Twitter, que não é definida na conta do desenvolvedor do Twitter. quando eu defino o url de retorno na conta de desenvolvedor do Twitter. Isso resolve meu problema. Quando não definimos o url de retorno de chamada na conta do desenvolvedor do Twitter, o login do Twitter é bem-sucedido quando o dispositivo tem o aplicativo Twitter. mas em caso de ausência de aplicativo do Twitter no dispositivo dá erro proibido 403.

Portanto, definir a url de retorno de chamada supera meu problema e o aplicativo é aceito.

Obrigado