Действующие лица: Исполнитель (мы), Заказчик, специалисты AppReview.

Акт 1

Действующие лица: Исполнитель (мы), Заказчик.

В рамках проекта нами было разработано мобильное приложение, работающее с серверным ПО Заказчика (на базе ОС от Microsoft), продаваемым клиентам Заказчика.

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

ПО Заказчика разрабатывается на базе фреймворка .Net. С учетом пожелания Заказчика о возможности изучения кода мобильного приложения его разработчиками, для разработки приложения был выбран фреймворк Xamarin, а именно — Xamarin.Android и Xamarin.iOS.

Мобильное приложение общается с сервером посредствам WCF фреймворка, конечная точка на стороне сервера — постоянно доступный сервис, размещаемый в IIS. Протокол прикладного уровня — HTTPS.

Особенности реализации WCF в фреймворке Xamarin и понадобившиеся доработки остаются за рамками описываемых событий.

Акт 2

Действующие лица: Заказчик, специалисты AppReview.

Заказчиком было принято решение о самостоятельной регистрации учетных записей Google и Apple Developer, публикация приложений также выполнялась силами специалистов Заказчика.

Ожидаемо, с публикацией в Google Play не возникло никаких сложностей.
Ожидаемо, прохождение AppReview затянулось. Об этом процессе и повествует этот и последующие акты.

Первой претензией специалистов AppReview стало отсутствие демонстрационного сервера, в работе с которым Apple мог бы проверить приложение.


Запрос демонстрационной учетной записи, в нашем случае точнее будет сказать — демонстрационного сервера.

Заказчиком был куплен VDS на площадке одного из известных хостеров. По какой-то причине был выбран зарубежный хостер, что в контексте нашей истории примечательно только тем, что для своих серверов он предоставлял не только внешний IPv4 адрес, но и IPv6 подсеть с префиксом /64. Заметим, что, в отличие от IPv4, у данного хостера IPv6 требует отдельной, хоть и не сложной, конфигурации средствами ОС сервера. В связи с этим в AppReview был передан IPv4 адрес сервера (вместе с логином и паролем для доступа к данным серверной части приложения).

Акт 3

Действующие лица: те же.

Приложение было отправлено на повторную проверку, специалистам AppReview была предоставлена информация о доступе к демо серверу.

И снова приложение не прошло проверку. Специалисты AppReview сообщили, что приложение выдало сообщение, что не может получить данные с сервера. Проверка проводилась из сети, в которой используется только IPv6.



Результат первой проверки работы приложения с демонстрационным сервером и ошибка, выдаваемая приложением.

Данный ответ также был ожидаем, так как с 1 июня 2016 года все приложения, отправляемые в AppStore, должны поддерживать работу в сетях, в которых используется только IPv6 (без IPv4).

Заказчик настроил IPv6 адрес, предоставленный хостером, на демонстрационном сервере, передал его специалистам AppReview.

И снова отказано в прохождении проверки, с той же причиной. Начинаем разбираться.

Акт 4

Действующие лица: те же, Исполнитель (мы).

Заказчик не имеет возможность проверить работу с IPv6 из своей сети. У нас такая возможность есть, провайдер предоставляет на IPv6 подсеть с префиксом /64, из которой мы выделяем IPv6 адреса на сервера, рабочие станции и прочие устройства.

Тестируем приложение на разный iOS устройствах с разными версиями iOS. Все подключены в WiFi сеть, получают IPv4 и IPv6 адрес. Получаем полностью корректную работу с демонстрационным сервером Заказчика, что по IPv4, что по IPv6.

Сообщаем об этом специалистам AppReview, их ответ не меняется. Далее следует несколько попыток снова пройти проверку после предоставления специалистам AppReview видео с демонстрацией корректной работы, нескольких просьб проверить доступность сервера из их сети (пинг, телнет, …), изменений настроек файервола, выкручивания логов IIS на максимум (в надежде, что они помогут выявить причину проблемы). Также задавался вопрос о переходе на общение на Русском языке для обсуждения технических подробностей, полностью проигнорированный.

Ответы специалистов каждый раз были идентичны предыдущему, и не содержали никаких технических подробностей.


Именно такой ответ мы получали несколько раз подряд.

Также был выставлен в сеть Интернет сервер, находящийся в нашей локальной сети, использующийся для разработки мобильного приложения. Его адрес был передан специалистам AppReview, результат проверки не изменился. Приложение не могло получить данные с сервера, в логах IIS мы даже не видели попыток запросов.

Нужно заметить, что, в отличие от сервера Заказчика, для нашего сервера мы создали DNS записи. С разными доменными именами для IPv4 (А запись) и IPv6 (АААА запись) адресов, чтобы продолжить проверять работу отдельно по IPv4 и IPv6.


DNS запись для IPv4 адреса


DNS запись для IPv6 адреса

Акт 5, развязка

Действующие лица: те же.

Было принято решение предоставить специалистам AppReview отчет, показывающий, что приложение полностью и успешно проходит все пункты инструкции по тестированию мобильных приложений компании Apple. Мы рассчитывали, что после этого нам предоставят хоть какие-нибудь технические подробности о прохождении проверки.

Приложение было успешно проверено по всем пунктам, кроме одного.
Само собой, мы застопорились на проверке работы приложение в чисто IPv6 сети (раздел “Test in IPv6-only networks” из вышеозначенной инструкции). Т.к. наша локальная сеть использует и IPv4, и IPv6, то результат проверки в ней нельзя использовать в качестве проверки в чисто IPv6 сети.

Системные администраторы были озадачены организации WiFi подсети, использующей только IPv6. Параллельно с этим запустили проверку через схему, предлагаемую инструкцией о поддержке DNS64/NAT64 сетей. Суть схемы заключается в создании на компьютере c MacOS (в нашем случае — Mac Mini) чисто IPv6 WiFi сети, предоставляющей общий доступ к сети Интернет через другой сетевой интерфейс.


Предлагаемая схема от Apple. Наш демонстрационный сервер находится до роутера, в IPv4+IPv6 локальной сети.

Приложение действительно не могло получить данные с сервера. При указании IPv4 адреса (и соответствующего доменного имени) получали ошибку о недоступности сети (логично, т.к. сеть чисто IPv6), при указании IPv6 адреса (и соответствующего доменного имени) — запросы завершались по таймауту.

Изучение сетевого трафика между устройством и Mac Mini, и между Mac Mini и локальной сетью, показало, что запросы приложения на IPv6 адрес доходят до Mac Mini, но в локальную сеть не уходят.

Для проверки работоспособности этой системы в целом, запустили браузер, и по трафику увидели, что

• запросы от устройства к Mac Mini идут по IPv6, что логично;
• запросы от Mac Mini идут по IPv4 независимо от того, есть ли IPv6 на самом Mac Mini.

Стало ясно, что для работы приложения в этой схеме требуется, чтобы:

1. сервер был задан через доменное имя;
2. устройство корректно определяло IPv6 адрес по этому доменному имени;
3. Mac Mini корректно определял IPv4 адрес по этому доменному имени;
4. сервер был доступен одновременно по этим IPv4 и IPv6 адресам.

DNS запись, имеющая IPv4 и IPv6 адреса

Создав А и АААА записи с одним доменным именем и указав его в приложении, мы добились получения данных с сервера.

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

Happy End!