Ready for Sale, или как опубликовать приложение в AppStore с первого раза

Ready for Sale - статус приложения, когда оно одобрено Apple Review Team и доступно для скачивания. Это тот волшебный момент, когда приложение начинает приносить пользу.

Три года назад был в моей практике случай, когда приложение отклоняли трижды, и каждый раз по разным причинам. Казалось бы, в Apple Review Guidelines описаны критерии, по которым принимаются приложения. Следуй им, и проблем не будет. Однако, приложение проверяют живые люди, причем при каждой новой проверке это могут быть разные люди. В моем случае получилось так: первый раз ревьюер углядел в силуэте телефона Android-устройство и отклонил приложение. Во второй — посчитал, что требуемое поле “пол” при регистрации необязательно; в третий — что определение местоположения пользователя спустя 10 минут использования приложения неуместно. Это отсрочило релиз на несколько недель.

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

На что обратить внимание перед публикацией

Пожертвования через Safari

При разработке сервиса для благотворительного фонда мы столкнулись с одним из нюансов оплаты. Мы предполагали принимать пожертвования с помощью карты внутри приложения. Но у Apple есть особое правило для пожертвований — все они должны проходить только через Safari. Не подходит даже использование WebView внутри приложения. После того, как мы доработали логику сервера и механику перевода денег, включив туда Safari, приложение опубликовали.

Выбираем вид и размер пожертвования в приложении. После этого приложение перенаправляет нас на сайт оплаты.

Изображения не Айфона

Apple с особым трепетом относится к изображениям чужих продуктов в AppStore. Как-то мы использовали силуэт смартфона в обучающем блоке одного из приложений, и ревьюер увидел в нем намек на один из флагманских Android-смартфонов. Приложение отклонили. При повторной проверке силуэт заменили на iPhone, и приложение опубликовали.

Необязательные данные для регистрации

В формах регистрации обычно бывают обязательные и необязательные поля. Если вы потребуете у пользователя заполнить поле, значение которого не важно для функциональности, - приложение отклонят. Возьмем приложение-агрегатор новостей. Если при регистрации полей “пол” и “возраст” будут обязательными, вас попросят сделать их необязательными. Когда мы сделали обязательной дату рождения, нас тоже попросили ее убрать.

Здесь для регистрации обязательна только почта.

Обоснование для геолокации

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

Возрастные ограничения

Рейтинг приложению присваивается при публикации: разработчик заполняет анкету, где указывает наличие в приложении сцен насильственного, эротического или сексуального характера. Несмотря на возрастные ограничения внутри приложения, его иконка и скриншоты всегда должны иметь возрастной рейтинг 4+. Если приложение ориентировано на детей, предусмотрите дополнительную проверку на встроенные покупки. Так вы гарантируете, что покупка осуществляется кем-то взрослым, а не любопытным ребенком. Проверкой может выступить какой-то вопрос с ответом в свободной форме.

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

Если приложение для детей постарше, лучше установить родительский контроль с пин-кодом.

Публикация от чужого имени

Если приложение разработано для какого-то бренда, а имя публикатора с ним не совпадает, Apple потребует разрешение на использование торговой марки. Так бывает, когда компания-разработчик публикует приложение от своего имени. Например, заказчик не хочет платить за собственную учетную запись в AppStore.
Чтобы публикацию от другого имени пропустили, заказчик пишет письмо, заверенное подписью и печатью. В нем указывает, что дает разрешение использовать его логотип, название и фирменный стиль в рамках разработки и публикации мобильного приложения. Это письмо прикладываем при отправке на проверку.

Работающий демо доступ

Команда Apple проверяет приложение на соответствие гайдлайнам. Если найдено несоответствие - исправление или аппеляция займут какое-то время. Самые частые отклонения случаются из-за того, что с демо доступа не удалось проверить все функции приложения. Например, при публикации интернет-магазина компания предоставила клиентский доступ и не предоставила доступ администратора магазина. Поэтому перед публикацией готовим учетную запись, у которой есть доступ ко всем функциям приложения. Если приложение связано с сервером, он должен быть доступен, а приложение наполнено хотя бы минимальным количеством данных.

Версия IP

Обратите внимание на версию IP, которую поддерживает ваш хостинг. Недавно мы определялись с хостингом для серверной части и выбрали тот, который поддерживает предпоследнюю версию - IPv4. В России все устройства ее используют. Хостинг работал как надо, тестирование прошло успешно. Пришло время выливаться. И тут пришел отказ — невозможно авторизоваться в приложении, сервер не поддерживает последнюю версию - IPv6. Для Review Team оказалось обязательным использовать только ее. Пришлось экстренно искать хостинг с IPv6, после чего приложение было проверено и опубликовано.

Мне отказали - что делать?

Если вам пришло письмо с отказом, там же будет указана причина.
Первая проверка занимает до пяти дней, повторные обычно быстрее - до двух дней. Вы можете ускорить процесс, если укажете в письме, какие изменения внесли. Это необязательное поле при заливке, но на практике значительно ускоряет публикацию.

Как ускорить публикацию

Все, о чем мы рассказали, отдаляет момент релиза. Но есть возможность его приблизить — отправить в iTunes Connect прошение об ускоренном рассмотрении.

Для этого могут быть две причины:

• Критические проблемы в существующей версии приложения. Например, вы уже опубликовали приложение, и в первые 5 дней работы в систему сбора информации об ошибках пришло несколько падений от разных пользователей. Правим приложение и пишем в техподдержку Apple, что был обнаружен баг с падением, исправлен только он, все остальные функции не трогались;
• Привязка публикации или обновления к конкретному событию. Например, нужно было опубликовать приложение перед выставкой светотехнической продукции к 7 ноября. Выливались 3 ноября и просили рассмотреть быстрее. В итоге приложение было готово к продаже через 18 часов.

Мы отправили команде Apple письмо-прошение, они одобрили его и опубликовали приложение через 18 часов.

Помните, что проверку осуществляют живые люди, которые даже зафиксированные правила могут трактовать субъективно.
Успешных вам ревью!