Шесть неочевидных причин отказа в публикации приложения в App Store
Этой статьёй мы открываем серию советов и рекомендаций от профессионалов рынка мобильных приложений. Пока одни учатся, другие вот-вот выпустят свой первый продукт в магазин. Какие подводные камни ждут разработчиков?
Любой разработчик с радостью в душе и великим нетерпением ждет, когда же его замечательное приложение появится в App Store. Но если не соблюдать несколько правил, этот радостный момент может быть отсрочен отказом от Apple Review Team — команды Apple, занимающейся проверкой приложений на соответствие стандартам магазина.
Будет вдойне печально, если этот отказ будет вызван досадными недочетами, и его можно было бы легко избежать, запомнив несколько несложных правил. Ниже перечислены пункты, которые нужно трижды проверить перед тем, как отправлять приложение на ревью.
1. Ценность приложения Для начала все же отмечу, что перед сабмитом (отправкой приложения на проверку, жарг. — прим. ред.) следует пройтись по всем пунктам Review Guidelines. Это 10 советов, напоминающих разработчику трезво оценить свой продукт и его шансы на успех среди любителей «яблочных» устройств. Если вы публикуете отличное приложение-фонарик, пожалуйста, убедитесь, что таких фонариков пользователи iOS еще не видывали! Иначе не обижайтесь, если Review Team скажет вам «досвидания». А может и не скажет — как повезёт. Готовы рискнуть? Может, не надо?
2. Мусор в коде Тут примеров может быть масса, но предложу один из собственной практики. Предположим, вы рассматривали различные варианты монетизации приложения, в том числе рекламную, но все же остановились на традиционно платном продукте? В таком случае будьте добры убрать из приложения рекламный идентификатор IDFA. Иначе сразу же после загрузки увидите статус «invalid binary». Еще важно не забыть отключить все использованные non-public API, а также все неиспользованные.
3. Название приложения Один из обязательных, но не всегда очевидных пунктов состоит в том, что название приложения в App Store, а особенно в Mac App Store, должно в точности совпадать с отображаемым после установки. Поскольку подпись под иконкой на iOS имеет ограниченный набор символов, здесь возможны девиации, но в разумных пределах логических ассоциаций.
Пример. Если в App Store ваше приложение называется «Новый фонарик для туристов», то подпись под иконкой на iOS должна быть все же «Фонарик», а не «Пельмени». С приложениями для OS X всё серьёзнее — строго «Новый фонарик для туристов» и никак иначе. Замечу, что Apple в силу своих региональных особенностей с особым трепетом проверяет английскую локализацию UI (интерфейса) и описания продукта. Если вы не уверены в своем знании заморского языка, поручите заняться этими вопросами кому-нибудь компетентному.
4. Возрастной рейтингЗаполнив небольшую анкету с тремя типами ответов («не встречается/встречается редко/встречается часто»), Apple позволяет автоматически определить возрастную группу аудитории вашего приложения. Всего таких возрастных групп четыре:
от 4 до 8 лет; от 9 до 11 лет; от 12 до 16 лет; от 17 лет и старше. Некоторые недобросовестные разработчики или менеджеры поленятся прочитать каждый вопрос и ответить на него должным образом. Но Apple точно не затруднится поставить отказ, если в приложении для детей обнаружит упоминание бранных слов или неприличные картинки, пропагандирующие вредные привычки. Кроме того, вы рискуете нарваться на судебный иск от сердобольных родителей морально обиженного чада. И тогда всем вашим перспективам как разработчика или издателя наступит скоропостижный конец.
5. Ссылки внутри приложения и в iTunes Connect Распространённая ситуация для начинающих разработчиков. Вы уже полностью закончили работу над приложением, но только при загрузке в App Store увидели три поля ввода данных: ссылка на техподдержку (Support URL), маркетинговая информация о приложении (Marketing URL) и политика конфиденциальности (Privacy Policy). Дальше большинство думает следующим образом:
Говорят, приложение рассматривают 5 дней, а то и дольше; еще 83 раза успею заказать и сверстать промо-сайт, а пока поставлю заглушки на места ссылок.
Не тут-то было! Apple довольно часто рассматривает приложения в течение 1 дня — точнее, одной ночи по московскому времени. Обязательным требованием является работоспособность всех внешних ссылок как в приложении, так и в мета-информации на App Store. Пожалуйста, заранее озаботьтесь подготовкой веб-сопровождения своего проекта, либо дождитесь когда сайты будут готовы, иначе отказа не миновать.
6. Политика конфиденциальности Если Ваше приложение:
разработано специально для детей и вы планируете распространять его через соответствующую категорию App Store, запрашивает или собирает персональную информацию о пользователе (в том числе имя, электронную почту, местоположение, фотографии и пр.), позволяет зарегистрироваться или выполнить логин в учетную запись онлайн-сервиса (как, например, Wall Street Journal), — то Вы просто обязаны разработать политику конфиденциальности на английском языке для команды Apple. В противном случае — на все 100 процентов получите отказ. Не будем посвящать эту статью особенностям сложного юридического процесса: о том, как правильно составить эти документы, вам расскажут в Google или в следующих статьях нашего цикла.
Это были шесть причин отказа, которые могут оказаться неожиданными для разработчиков. Ознакомиться с самыми распространёнными причинами «реджекта» в официальной форме можно на специализированном портале Dev.Apple.com в разделе Rejections.
Среди читателей сайта обязательно есть издатели и девелоперы: будет интересно услышать ваши истории отказов и решений проблем с командой Apple Review Team. А пока — до встречи в следующих статьях цикла!
мы тестируем кнопки UpToLike
Любой разработчик с радостью в душе и великим нетерпением ждет, когда же его замечательное приложение появится в App Store. Но если не соблюдать несколько правил, этот радостный момент может быть отсрочен отказом от Apple Review Team — команды Apple, занимающейся проверкой приложений на соответствие стандартам магазина.
Будет вдойне печально, если этот отказ будет вызван досадными недочетами, и его можно было бы легко избежать, запомнив несколько несложных правил. Ниже перечислены пункты, которые нужно трижды проверить перед тем, как отправлять приложение на ревью.
1. Ценность приложения Для начала все же отмечу, что перед сабмитом (отправкой приложения на проверку, жарг. — прим. ред.) следует пройтись по всем пунктам Review Guidelines. Это 10 советов, напоминающих разработчику трезво оценить свой продукт и его шансы на успех среди любителей «яблочных» устройств. Если вы публикуете отличное приложение-фонарик, пожалуйста, убедитесь, что таких фонариков пользователи iOS еще не видывали! Иначе не обижайтесь, если Review Team скажет вам «досвидания». А может и не скажет — как повезёт. Готовы рискнуть? Может, не надо?
2. Мусор в коде Тут примеров может быть масса, но предложу один из собственной практики. Предположим, вы рассматривали различные варианты монетизации приложения, в том числе рекламную, но все же остановились на традиционно платном продукте? В таком случае будьте добры убрать из приложения рекламный идентификатор IDFA. Иначе сразу же после загрузки увидите статус «invalid binary». Еще важно не забыть отключить все использованные non-public API, а также все неиспользованные.
3. Название приложения Один из обязательных, но не всегда очевидных пунктов состоит в том, что название приложения в App Store, а особенно в Mac App Store, должно в точности совпадать с отображаемым после установки. Поскольку подпись под иконкой на iOS имеет ограниченный набор символов, здесь возможны девиации, но в разумных пределах логических ассоциаций.
Пример. Если в App Store ваше приложение называется «Новый фонарик для туристов», то подпись под иконкой на iOS должна быть все же «Фонарик», а не «Пельмени». С приложениями для OS X всё серьёзнее — строго «Новый фонарик для туристов» и никак иначе. Замечу, что Apple в силу своих региональных особенностей с особым трепетом проверяет английскую локализацию UI (интерфейса) и описания продукта. Если вы не уверены в своем знании заморского языка, поручите заняться этими вопросами кому-нибудь компетентному.
4. Возрастной рейтингЗаполнив небольшую анкету с тремя типами ответов («не встречается/встречается редко/встречается часто»), Apple позволяет автоматически определить возрастную группу аудитории вашего приложения. Всего таких возрастных групп четыре:
от 4 до 8 лет; от 9 до 11 лет; от 12 до 16 лет; от 17 лет и старше. Некоторые недобросовестные разработчики или менеджеры поленятся прочитать каждый вопрос и ответить на него должным образом. Но Apple точно не затруднится поставить отказ, если в приложении для детей обнаружит упоминание бранных слов или неприличные картинки, пропагандирующие вредные привычки. Кроме того, вы рискуете нарваться на судебный иск от сердобольных родителей морально обиженного чада. И тогда всем вашим перспективам как разработчика или издателя наступит скоропостижный конец.
5. Ссылки внутри приложения и в iTunes Connect Распространённая ситуация для начинающих разработчиков. Вы уже полностью закончили работу над приложением, но только при загрузке в App Store увидели три поля ввода данных: ссылка на техподдержку (Support URL), маркетинговая информация о приложении (Marketing URL) и политика конфиденциальности (Privacy Policy). Дальше большинство думает следующим образом:
Говорят, приложение рассматривают 5 дней, а то и дольше; еще 83 раза успею заказать и сверстать промо-сайт, а пока поставлю заглушки на места ссылок.
Не тут-то было! Apple довольно часто рассматривает приложения в течение 1 дня — точнее, одной ночи по московскому времени. Обязательным требованием является работоспособность всех внешних ссылок как в приложении, так и в мета-информации на App Store. Пожалуйста, заранее озаботьтесь подготовкой веб-сопровождения своего проекта, либо дождитесь когда сайты будут готовы, иначе отказа не миновать.
6. Политика конфиденциальности Если Ваше приложение:
разработано специально для детей и вы планируете распространять его через соответствующую категорию App Store, запрашивает или собирает персональную информацию о пользователе (в том числе имя, электронную почту, местоположение, фотографии и пр.), позволяет зарегистрироваться или выполнить логин в учетную запись онлайн-сервиса (как, например, Wall Street Journal), — то Вы просто обязаны разработать политику конфиденциальности на английском языке для команды Apple. В противном случае — на все 100 процентов получите отказ. Не будем посвящать эту статью особенностям сложного юридического процесса: о том, как правильно составить эти документы, вам расскажут в Google или в следующих статьях нашего цикла.
Это были шесть причин отказа, которые могут оказаться неожиданными для разработчиков. Ознакомиться с самыми распространёнными причинами «реджекта» в официальной форме можно на специализированном портале Dev.Apple.com в разделе Rejections.
Среди читателей сайта обязательно есть издатели и девелоперы: будет интересно услышать ваши истории отказов и решений проблем с командой Apple Review Team. А пока — до встречи в следующих статьях цикла!
мы тестируем кнопки UpToLike
Ещё новости по теме:
18:20