Отклонение IPv6 App Store

Наше обновление было дважды отклонено сегодня из-за проблем с подключением к сети ipv6. Наш сетевой код не изменился между предыдущим и текущим выпусками.

Приложение отправляет сетевые запросы https только к api.metooapp.io, который правильно настроен для ipv6 [ 0 ] и выполняется за route53 на AWS. В коде нет жестко заданных IP-адресов.

Я не могу воспроизвести эту проблему, даже после выполнения шагов по созданию сети ipv6 в [ 1 ], которая является ссылкой, которая была указана в уведомлении об отказе. Похоже, что я не единственный, у кого возникла эта проблема [ 2 ].

После небольшого стресса я могу подтвердить, что проблема заключалась в том, что наш бэкэнд был неправильно настроен для IPv6. Судя по всему, AWS не поддерживает ни IPv6, ни DNS только для IPv6 через Route53. В итоге я переместил все части серверной части, обращенные к Интернету, на время от AWS.

Я хотел оставить это, потому что думаю, что, вероятно, будут другие, которые столкнутся с аналогичными проблемами, когда люди начнут отправлять обновления после ограничения только IPv6. Лучшим инструментом, который я нашел для тестирования готовности сервера / DNS, был: http://ready.chair6.net/

Обратите внимание, что ссылка « Поддержка сетей только с IPv6» и « IPv6» и «Обзор приложений» может быть очень полезной при определении проблемы с отклонениями Apple. В этом конкретном случае в статьях четко указано, что вы можете настроить тестовую сеть DNS64 / NAT64, но что «Эта тестовая сеть не совсем такая же, как сеть, используемая App Review», поэтому все может работать в тестовой среде и при этом иметь приложение отклонено.

Кроме того:

Сеть App Review, как и сети, развернутые поставщиками услуг, действительно поддерживает подключение IPv6 к IPv6. Таким образом, если ваш сервер поддерживает IPv6, ваше приложение будет обращаться к нему напрямую, без использования транслятора NAT64. В целом это хорошо, но может сбить вас с толку, если ваш сервер утверждает, что поддерживает IPv6, но эта поддержка IPv6 не работает. Например, если: имя DNS неверно, DNS правильный, но сервер не слушает IPv6, сервер слушает IPv6, но терпит неудачу, когда запрос приходит через IPv6

Итак, если ваш внутренний сервер поддерживает IPv6, тестовая сеть Apple будет использовать его, и в данном случае это было не так.

Я добавляю это в качестве справки и отправной точки для других пользователей, которые сталкиваются с той же проблемой.

Мы столкнулись с той же проблемой, и выяснилось, что когда мы настраивали запись AAAA для IPv6, поскольку у нас фактически не было поддержки IPv6 (мы также используем Route53), это все сработало. Удаление записи AAAA устранило проблему.

Я подал радар о несоответствии между документацией для тестирования и настройки App Review использует - мы только были в состоянии диагностировать , потому что наш технический директор был на WWDC и был в состоянии подключиться к своей сети, которая не является точно ситуация мы можем воспроизводить регулярно.

Мы столкнулись с похожей ситуацией. Наше приложение было отклонено из-за проблем с подключением в сетях IPv6. Также наши серверы используют AWS.

Я провел тест для IPv6 DNS64 / NAT64 без каких-либо проблем с моей стороны, и мы решаем подать апелляцию на этот отказ.

Мы объяснили, что тестирование с нашей стороны прошло успешно и что мы используем инфраструктуру AWS.

Еще через два дня приложение было снова рассмотрено и принято.

мы столкнулись с той же проблемой。 Наше приложение было отклонено сервалом по причине ipv6. Но мы прошли тестирование в сети ipv6, которая была настроена как официальный документ APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortitionheIPv6//Trans uid / TP40010220-CH213-SW1

Наше приложение отклоняется в первый раз, мы настраиваем локальную тестовую среду на основе документа Apple и обнаруживаем, что наша библиотека curl слишком старая без включения ipv6 по умолчанию. Итак, мы создали последнюю версию curl lib, и она работает. Но он снова отклонен по той же причине. Я проверяю много информации, нахожу, что у кого-то был такой же опыт, просто пожаловаться рецензенту Apple, чтобы он сказал, что ваше приложение хорошо работает в тестовой среде, и прошу его предоставить инженера, который поможет, если они настаивают на какой-то ошибке. Группа проверки Apple одобрила наше приложение на выходных, когда увидела наши жалобы.

Насколько я знаю, вам нужно проверить 2 вопроса. Вы жестко указали IP-адрес в своем приложении? Вы настраиваете запись AAAA для домена вашего сервера, чтобы показать, что он поддерживает ipv6, но ваш сервер не слушает ipv6. Если да, просто удалите эту запись AAAA в настройках своего домена с сайта поставщика домена.

Библиотека достижимости должна поддерживать сетевые настройки IPv6. Так что используйте этот класс Reachability.

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

Это второй раз, когда я столкнулся с этой проблемой через 6 месяцев. Раньше это было в проекте Objective-C с использованием AFNetworking, и я использовал это решение, и оно работало сразу. Теперь то же самое произошло с Alamofire. Ребята, это решение сработало у меня 2 раза, и я обнаружил, что этот вопрос сначала появляется в Google, поэтому я отправляю ответ.

Найдите в рабочей области AF_INET и измените его на AF_INET6 в любом месте, где вы нашли. Я думаю, что он должен быть внутри библиотеки AFNetworking или библиотеки Alamofire, если вы ее используете. Его в классе NetworkReachabilityManager.

Я нашел этот ответ из приведенного ниже источника.

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

РЕДАКТИРОВАТЬ: - 24 июня -

Это помогало мне очень много раз, но есть и странное решение этой проблемы. В нашем недавнем проекте мы применили это решение, но Apple все равно отклонила заявку. Затем мы сделали видео, в котором было показано, что приложение работает нормально при подключении к сети NAT64, созданной на Mac, с помощью опции совместного использования Wi-Fi. Мы обратились за просмотром с видео, и они одобрили заявку. Так что, если вы закончили со всеми вариантами, попробуйте и этот.

Вы можете проверить свой API на веб-сайте ниже, настроен ваш API iPV6 или нет!

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

Я выполнил тест IPv6 DNS64/NAT64без каких-либо проблем, как указано в документации Apple.

однако мы не можем воспроизвести проблему (сбой). Мы успешно устанавливаем приложение на наши устройства без сбоев.

• Мы сняли видео этого общего процесса тестирования (которое включает в себя демонстрацию подключения, загрузку из testflight, сетевое подключение NAT64, операции приложения)
• и обращение об отказе с видео файлом

Наконец , магазин приложений ОДОБРИЛ мое приложение

Я столкнулся с тем же отклонением приложения при использовании Facebook SDK. Если вы используете Facebook SDK для входа в систему, невероятно важно выйти из системы при завершении сеанса. В противном случае вы столкнетесь с подобными отказами приложений в будущем. Я включил приведенный ниже код, чтобы помочь тем, у кого могут возникнуть аналогичные проблемы.

let loginManager = FBSDKLoginManager()
loginManager.logOut()

Я решил проблему, отправив им видео, показывающее, что мое приложение работает на ipv6.

1. Настройте ipv6 с вашей macOS
2. Видеокассета, в которой вы подключены к общей сети ipv6 и подтверждаете, что ваше приложение работает в этой среде.

мое приложение было отклонено два раза в магазине приложений. Они выдают ошибку при входе в твиттер на iphone с ОС 11.4. Основная проблема, с которой мы сталкиваемся, связана с URL-адресом обратного вызова Twitter, который не установлен в учетной записи разработчика Twitter. когда я устанавливаю URL-адрес обратного вызова в учетной записи разработчика Twitter. Это решает мою проблему. Когда мы не устанавливаем URL-адрес обратного вызова в учетной записи разработчика в Twitter, тогда вход в Twitter выполняется успешно, когда на устройстве установлено приложение Twitter. но при отсутствии твиттера на устройстве выдает запрещенную ошибку 403.

Таким образом, установка URL-адреса обратного вызова решает мою проблему, и приложение принимается.

Спасибо