Відмова від магазину додатків IPv6

Сьогодні наше оновлення було відхилено двічі через проблеми з підключенням до мережі ipv6. Наш мережевий код не змінився між попереднім та поточним випусками.

Додаток робить лише мережеві запити https до api.metooapp.io, який правильно налаштований для ipv6 [ 0 ] і працює позаду route53 на AWS. У коді відсутні жорстко закодовані IP-адреси.

Я не можу відтворити цю проблему, навіть виконавши кроки для створення мережі ipv6 за адресою [ 1 ], що є посиланням, яке було вказане в повідомленні про відмову. Схоже, що я не єдиний стикався з цією проблемою [ 2 ].

Після певного напруження я можу підтвердити, що проблема полягала в тому, що наш сервер не був правильно налаштований для IPv6. Очевидно, AWS не підтримує IPv6, а також лише IPv6 DNS через Route53. Я врешті-решт перемістив усі біти бекенда, що стоять перед Інтернетом, на час від AWS.

Я хотів залишити це, оскільки думаю, що, мабуть, будуть і інші, хто зіткнеться з подібними проблемами, коли люди почнуть надсилати оновлення після обмеження лише на IPv6. Найкращим інструментом, який я знайшов для тестування готовності сервера / dns, був: http://ready.chair6.net/

Зверніть увагу , що з підтримкою тільки IPv6 мереж і IPv6 і App Огляд зв'язок може бути дуже корисним у визначенні того, що проблема з яблуком відмовах. У цьому конкретному випадку в статтях чітко зазначено, що ви можете налаштувати тестову мережу DNS64 / NAT64, але що "ця тестова мережа не зовсім така, як мережа, що використовується App Review", тому все може працювати в тестовому середовищі і все ще мати додаток відхилено.

Більше того:

Мережа App Review, як і мережі, розгорнуті постачальниками послуг, підтримує підключення IPv6 до IPv6. Таким чином, якщо ваш сервер підтримує IPv6, ваш додаток буде спілкуватися з ним безпосередньо, не проходячи через перекладач NAT64. Це, загалом, добре, але це може вас зіткнути, якщо ваш сервер стверджує, що підтримує IPv6, але ця підтримка IPv6 порушена. Наприклад, якщо: ім'я DNS неправильне, то DNS правильне, але сервер не слухає на IPv6, сервер слухає на IPv6, але не вдається, коли надходить запит через IPv6

Отже, якщо ваш серверний сервер має підтримку IPv6, тестова мережа Apple буде використовувати його, і саме це було не так у цьому випадку.

Я додаю це як довідковий та вихідний пункт для інших користувачів, які стикаються з такою ж проблемою

Ми зіткнулися з цією ж проблемою, і це виявилося, коли ми налаштовували запис AAAA для IPv6, оскільки насправді ми не мали підтримки IPv6 (ми також використовуємо Route53), це все зіпсувало. Видалення запису AAAA вирішило проблему.

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

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

Я провів тест на IPv6 DNS64 / NAT64 без жодних проблем зі свого боку, і ми вирішили подати апеляцію на це відхилення.

Ми пояснили, що тест на нашій стороні був успішно завершений і що ми використовуємо інфраструктуру AWS.

Ще через два дні додаток знову переглянули та прийняли

ми зіткнулися з тією ж проблемою。 Нашому додатку було відхилено сервісний час з причини ipv6. Але ми пройшли тестування в мережі ipv6, яка налаштована як офіційний документ APPLE: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparing#cp/prep uid / TP40010220-CH213-SW1

Наш додаток відхилено вперше, ми налаштовуємо локальне тестове середовище на основі документа apple і виявляємо, що наша curl lib занадто стара, не вмикаючи ipv6 за замовчуванням. Тож ми створюємо останню curl lib, і вона працює. Але це знову відхиляється, тому що ця ж причина. Я перевіряю багато інформації, виявляю, що хтось мав такий самий досвід, просто скаржусь рецензенту Apple, щоб сказати, що ваш додаток працює добре в тестовому середовищі, і попросити його надати інженеру допомогу, якщо вони наполягають на помилці. Команда огляду Apple схвалила наш додаток у вихідні, коли побачила наші скарги.

Як я знаю, є 2 проблеми, які потрібно перевірити. Ви жорстко кодуєте ip-адресу у своєму додатку? Чи ви налаштовуєте свій запис AAAA для домену вашого сервера, щоб показати, що він підтримує ipv6, але ваш сервер не слухає ipv6. Якщо так, просто видаліть цей запис AAAA у налаштуваннях домену з веб-сайту постачальника доменів.

Бібліотека доступності повинна підтримувати налаштування мережі IPv6. Тож використовуйте цей клас Досяжності.

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, і підтверджує, що ваш додаток працює в цьому середовищі.

мій додаток відхилено два рази в магазині програм. Вони дають помилку входу в Twitter на iphone, що має OS 11.4 Основна проблема у нас через URL зворотного виклику twitter, який не встановлено в обліковому записі розробника twitter. коли я встановлюю URL зворотного дзвінка на рахунок розробника твіттера. Це вирішує моє питання. Коли ми не встановлюємо URL-адресу зворотного виклику в обліковому записі розробника twitter, час входу в Twitter є успішним, коли пристрій має додаток twitter. але у випадку відсутності програми twitter на пристрої видає заборонену помилку 403.

Отже, встановлення URL-адреси зворотного виклику долає мою проблему, і додаток приймається.

Дякую