Odrzucenie sklepu z aplikacjami IPv6

89

Nasza aktualizacja została dzisiaj dwukrotnie odrzucona z powodu problemów z łącznością sieciową ipv6. Nasz kod sieciowy nie zmienił się między poprzednią a obecną wersją.

Aplikacja wysyła tylko żądania sieciowe HTTPS do api.metooapp.io, które jest poprawnie skonfigurowane dla IPv6 [ 0 ] i działa za routingiem53 w AWS. W kodzie nie ma zakodowanych adresów IP.

Nie mogę odtworzyć tego problemu, nawet po wykonaniu czynności związanych z utworzeniem sieci IPv6 pod adresem [ 1 ], do której należy łącze podane w powiadomieniu o odrzuceniu. Wygląda na to, że nie tylko ja mam ten problem [ 2 ].

Sean Thielen
źródło
Czy używasz AFNetworking(jeśli tak, jakiej wersji)? Reachability? Biblioteki innych firm?
Brandon
Alamofire 3.4.0 i Reachability.swift , ale sposób, w jaki używam Reachability, dotyczy tylko opcjonalnych zadań w tle. Moim głównym problemem jest to, że nie mogę tego odtworzyć, nawet po wykonaniu instrukcji Apple.
Sean Thielen
Dodaj również swój kod sieciowy w pytaniu
błąd 2007
@ error2007s Kod sieciowy to Alamofire
Sean Thielen
1
kupiłeś najnowszy klucz sprzętowy Apple IPv6?
anders

Odpowiedzi:

37

Po pewnym stresie mogę potwierdzić, że problem polegał na tym, że nasz backend nie był poprawnie skonfigurowany pod kątem IPv6. Najwyraźniej AWS nie obsługuje IPv6 ani DNS tylko dla IPv6 za pośrednictwem Route53. Skończyło się na tym, że na razie przeniosłem cały internet naprzeciwko części zaplecza od AWS.

Chciałem to zostawić, ponieważ myślę, że prawdopodobnie pojawią się inne osoby, które będą miały podobne problemy, gdy ludzie zaczną przesyłać aktualizacje po przekroczeniu ograniczenia dotyczącego tylko IPv6. Najlepsze narzędzie do testowania gotowości serwera / dns to: http://ready.chair6.net/

Sean Thielen
źródło
2
Czy możesz mi powiedzieć, czy przyczyną odrzucenia App Store były Twoje serwery nie obsługujące ruchu IPv6? Mam 3 odrzucenia z rzędu od Apple, ale mój kod nie zmienił się od poprzednich wersji. Używam Xamarin iOS i zaktualizowałem ich wtyczkę Connectivity do najnowszej wersji, ponieważ mieli problemy z IPv6. Robię się zdesperowany! Nie mogę tutaj odtworzyć awarii na moich urządzeniach z iOS (nawet w sieci NAT64 IPV6 poprzez udostępnianie Internetu na komputerze Mac).
Jon
to odrzucenie jest spowodowane na twoim serwerze, twój serwer nie obsługuje IPv6. Mangist
Pablo Ruan
Cześć @Sean Thielan, przetestowałem nasz serwer z ready.chair6.net i nie działa on w przypadku połączenia sieciowego IPV6, ale aplikacja działała dobrze z tym samym serwerem, który przetestowaliśmy, tworząc sieć NAT64 (dla sieci IPV6) na naszym Urządzenie iPhone 5S z wersją systemu operacyjnego 10.0.2. Czy możesz przedstawić poniższe wskazówki, czy musimy ponownie przesłać aplikację do sklepu z aplikacjami lub skontaktować się z pomocą techniczną Apple. Czy też musimy skonfigurować nasz serwer do obsługi sieci IPV6?
Venkatesh
Cześć @Venkatesh, czy znalazłeś rozwiązanie tego problemu, ponieważ utknąłem z odrzuceniem Apple w tym samym przypadku?
Mohamed Fadl Allah
cześć Sean. Przetestowałem moje API. Te trzy testy nie powiodły się. DNS (IPv6 NS) DNS (MX Record) DNS (Glue) .. Wyniki tych trzech testów to WARN. czy to problem, że Apple odrzuca moją aplikację. ?? Konieczne jest zdanie wszystkich testów domeny .. na ready.chair6.net ?????
JAck
11

Należy pamiętać, że Wsparcie IPv6 tylko sieci i IPv6 i App review link może być bardzo pomocne w ustalaniu, co jest problem z odrzucenia jabłek. W tym konkretnym przypadku artykuły jasno stwierdzają, że można skonfigurować sieć testową DNS64 / NAT64, ale „Ta sieć testowa nie jest dokładnie taka sama jak sieć używana przez App Review”, dlatego wszystko może działać w środowisku testowym i nadal mieć aplikacja została odrzucona.

Ponadto:

Sieć App Review, podobnie jak sieci wdrażane przez dostawców usług, obsługuje łączność IPv6-IPv6. Tak więc, jeśli twój serwer obsługuje IPv6, twoja aplikacja będzie komunikować się z nim bezpośrednio, bez przechodzenia przez translator NAT64. Jest to ogólnie rzecz biorąc dobra rzecz, ale może się zepsuć, jeśli twój serwer twierdzi, że obsługuje IPv6, ale obsługa IPv6 jest zepsuta. Na przykład, jeśli: nazwa DNS jest nieprawidłowa, DNS jest poprawny, ale serwer nie nasłuchuje na IPv6, serwer nasłuchuje na IPv6, ale kończy się niepowodzeniem, gdy przychodzi żądanie przez IPv6

Więc jeśli twój serwer backendu obsługuje IPv6, sieć testowa Apple będzie go używać i tak właśnie było w tym przypadku.

Dodaję to jako punkt odniesienia i punkt wyjścia dla innych użytkowników, którzy mają ten sam problem

lucianoenrico
źródło
10

Napotkaliśmy ten sam problem i okazało się, że podczas konfigurowania rekordu AAAA dla IPv6, ponieważ tak naprawdę nie mieliśmy obsługi IPv6 (używamy również Route53), wszystko zepsuło. Usunięcie rekordu AAAA rozwiązało problem.

Złożyłem radar dotyczący rozbieżności między dokumentacją do testowania a konfiguracją, z której korzysta przegląd aplikacji - byliśmy w stanie ją zdiagnozować tylko dlatego, że nasz CTO był w WWDC i był w stanie połączyć się z ich siecią, co nie jest dokładnie sytuacją możemy regularnie rozmnażać.

DesignatedNerd
źródło
Ciekawy. Miałem Route53 skonfigurowaną w ten sam sposób, z rekordem AAAA aliasowanym do ELB. Może w następnej pomniejszej wersji spróbuję z powrotem na AWS, ale bez rekordu AAAA. Sekcja wyników twojego radaru dokładnie odzwierciedla moje własne doświadczenia. W pewnym momencie przywróciłem ustawienia fabryczne routera, macbooka i iPhone'a, aby całkowicie upewnić się, że nie jest to jakiś absurdalny problem z pamięcią podręczną. Chciałbym kontynuować dochodzenie, ale jestem po prostu szczęśliwy, że aktualizacja przeszła i mam nadzieję, że nigdy więcej o tym nie pomyślę.
Sean Thielen
Czy dostałeś jakąś odpowiedź od Apple na swój radar?
Kaiserludi
1
@Kaiserludi nieoficjalnie, chociaż widziałem to na forach deweloperów, jeśli szukasz postów od Quinn The Eskimo, aktualizował je o wiele więcej informacji, które pomogą Ci debugować. Ten wydaje się szczególnie pomocny: forums.developer.apple.com/message/147579#147579
DesignatedNerd
Wielkie dzięki. Ten link jest rzeczywiście bardzo pouczający.
Kaiserludi
6

Znaleźliśmy się w podobnej sytuacji. Nasza aplikacja została odrzucona z powodu problemów z łącznością w sieciach IPv6. Również nasze serwery używają AWS.

Wykonałem Test IPv6 DNS64 / NAT64 bez żadnego problemu z mojej strony i postanawiamy złożyć odwołanie od tego odrzucenia.

Wyjaśniliśmy, że test po naszej stronie zakończył się sukcesem i korzystamy z infrastruktury AWS.

Po kolejnych dwóch dniach aplikacja została ponownie sprawdzona i zaakceptowana

MP23
źródło
5

napotkaliśmy ten sam problem。 Nasza aplikacja została odrzucona przez okres serwowania z powodu IPv6. Ale zostaliśmy przetestowani w sieci ipv6 skonfigurowanej jako oficjalny dokument APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition_html uid / TP40010220-CH213-SW1

Ern Zhang
źródło
6
Znalazłeś rozwiązanie tego problemu? Nie mogę uzyskać akceptacji mojej recenzji aplikacji przez Apple i nie mam pomysłów
Jon
5

Nasza aplikacja jest odrzucana za pierwszym razem, konfigurujemy lokalne środowisko testowe na podstawie dokumentu Apple i stwierdzamy, że nasza biblioteka curl jest zbyt stara bez domyślnie włączonego ipv6. Dlatego tworzymy najnowszą bibliotekę curl i działa. Ale znowu jest odrzucony z tego samego powodu. Sprawdzam wiele informacji, stwierdzam, że ktoś miał takie same doświadczenia, wystarczy złożyć skargę do recenzenta Apple, aby powiedzieć, że Twoja aplikacja działa dobrze w środowisku testowym i poprosić o pomoc inżyniera, jeśli nalegają, że wystąpił jakiś błąd. Zespół Apple zatwierdził naszą aplikację w weekend, kiedy zobaczył nasze skargi.

Jak wiem, są 2 problemy, które musisz sprawdzić. Czy zakodujesz na stałe adres IP w swojej aplikacji? Czy konfigurujesz rekord AAAA dla domeny serwera, aby pokazać, że obsługuje IPv6, ale serwer nie nasłuchuje IPv6. Jeśli tak, po prostu usuń ten rekord AAAA w ustawieniach domeny z witryny dostawcy domeny.

ramon.liu
źródło
2

To drugi raz, kiedy napotkałem ten problem po 6 miesiącach. Wcześniej było to w projekcie Objective-C przy użyciu AFNetworking i korzystałem z tego rozwiązania i działało za jednym zamachem. Teraz to samo stało się z Alamofire. Chłopaki, to rozwiązanie działało u mnie 2 razy i stwierdziłem, że to pytanie pojawia się jako pierwsze w Google, więc publikuję odpowiedź.

Wyszukaj w obszarze roboczym hasło AF_INET i zmień je na AF_INET6 w dowolnym miejscu. Myślę, że musi znajdować się w bibliotece AFNetworking lub bibliotece Alamofire, jeśli jej używasz. Znajduje się w klasie NetworkReachabilityManager.

Znalazłem tę odpowiedź z poniższego źródła.

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

EDYCJA: - 24 czerwca -

Pomogło mi to wiele razy, ale jest też dziwne rozwiązanie tego problemu. W naszym ostatnim projekcie zastosowaliśmy to rozwiązanie, ale Apple nadal odrzuciło wniosek. Następnie nakręciliśmy film, który pokazywał, że aplikacja działa poprawnie z połączeniem z siecią NAT64 utworzoną na komputerze Mac z opcją udostępniania Wi-Fi. Zwróciliśmy się o sprawdzenie wraz z filmem, a oni zatwierdzili wniosek. Więc jeśli skończyłeś ze wszystkimi opcjami, wypróbuj również tę.

Mahesh Agrawal
źródło
1

Przeprowadziłem Test IPv6 DNS64/NAT64bez żadnego problemu zgodnie z dokumentacją Apple

jednak nie jesteśmy w stanie odtworzyć problemu (awaria). Pomyślnie zainstalowaliśmy aplikację na naszych urządzeniach bez awarii.

  • Nagraliśmy film przedstawiający cały proces testowania (obejmujący pokazanie łączności, pobieranie z lotu testowego, połączenie sieciowe NAT64, działanie aplikacji)
  • i apeluj o odrzucenie wraz z plikiem wideo

Wreszcie sklep z aplikacjami ZATWIERDZIŁ moją aplikację

Phani Sai
źródło
1
upewnij się, że Twoja aplikacja nie ma zakodowanego adresu IP w aplikacji, w tym wtyczek
Phani Sai
0

Napotkałem to samo odrzucenie aplikacji podczas korzystania z zestawu SDK Facebooka. Jeśli używasz Facebook SDK do logowania, niezwykle ważne jest wylogowanie użytkownika po zakończeniu sesji. W przeciwnym razie w przyszłości wystąpią podobne odrzucenia aplikacji. Poniżej zamieściłem kod, aby pomóc tym, którzy mogą mieć podobne problemy.

let loginManager = FBSDKLoginManager()
loginManager.logOut()
Adam Cooper
źródło
0

Rozwiązałem problem, wysyłając im wideo pokazujące, że moja aplikacja działa na ipv6.

  1. Skonfiguruj IPv6 z systemem macOS
  2. Taśma wideo, że masz połączenie z udostępnioną siecią IPv6 i udowodnij, że Twoja aplikacja działa w tym środowisku.
Steve Ham
źródło
Wypróbowałem trasę wideo. Pokazał im, jak konfiguruję komputer Mac jako Wi-Fi IPV6, podłączam do niego telefon i uruchamiam aplikację bez problemu. Właśnie otrzymałem od nich kolejne odrzucenie, mówiąc: „Dziękujemy za odpowiedź. Podczas naszej oceny odkryliśmy, że Twoja aplikacja nadal wyświetla biały ekran, nawet gdy jest testowana na wielu urządzeniach”. Następnie podano porady dotyczące testowania w sieciach IPV6; są to te same kroki, które pokazałem im w swoim filmie. Ogólnie odpowiedź wyglądała na zautomatyzowaną. Jak radzić sobie z prawdziwą osobą z zespołu Apple Review Team?
ChillyPenguin
Być może [email protected].
Steve Ham
0

moja aplikacja jest odrzucana dwa razy w sklepie z aplikacjami. Dają błąd przy logowaniu do Twittera na iPhonie z systemem operacyjnym 11.4. Główny problem, który mamy z powodu adresu zwrotnego Twittera, który nie jest ustawiony na koncie programisty Twittera. kiedy ustawię URL wywołania zwrotnego na koncie programisty Twittera. To rozwiązuje mój problem. Kiedy nie ustawiamy adresu URL wywołania zwrotnego na koncie programisty na Twitterze, logowanie do Twittera jest pomyślne, gdy urządzenie ma aplikację Twitter. ale w przypadku braku aplikacji twitter na urządzeniu daje zabroniony błąd 403.

Tak więc ustawienie adresu URL wywołania zwrotnego rozwiązuje mój problem i aplikacja jest akceptowana.

Dziękuję Ci

Rahul Phate
źródło