Блог онлайн-университета Code breakers

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

В 2020 году App Store отклонил миллион приложений, публикуемых впервые. И ещё столько же обновлений старых приложений. Причины тому — ошибки, которые допускаются при публикации. Они практически не связаны с содержимым приложений, а чаще всего — с его упаковкой при релизе. Рассказываем про самые частые ошибки разработчиков, которые не дают пройти проверку, и про то, как их избежать.

Этот текст нам помог подготовить преподаватель нашего курса Мобильной разработки без кода, эксперт Adalo, практикующий ноукодер и ведущий подкаста «АнтиКод» Андрей Козицин. Вы также можете послушать выпуск подкаста на эту тему.

Строка «Публикация в маркеты» несколько лет назад стала фактически обязательной в сметах к приложениям. Так произошло потому, что после выполнения требований заказчика, впереди ещё ждёт хитрый квест по релизу приложения в сторах. Нужно выполнить десятки требований от маркетов, чтобы ваше создание смогли увидеть пользователи. И здесь встречаются подводные камни — и разработчики при публикации в маркеты своих проектов нередко допускают одинаковые ошибки. О них сейчас и расскажем.

Ошибки в данных о приложении на его странице в маркете 


Данные о приложении на его странице в маркете — это описание приложения и скриншоты того, как выглядит приложение. За эту часть отвечает заказчик — ведь именно ему, владельцу приложения, нужно показать своё приложение с наилучшей стороны. А вам, как разработчику, критически важно донести до заказчика степень ответственности за подготовку описаний и скриншотов.

Скриншоты


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

Причём для разных операционных систем нужно делать свои скриншоты. Если приложение публикуется в App Store, то по изображениям должно быть отчётливо понятно, что скриншоты созданы на iOS. Схитрить и выложить одинаковые изображения во все сторы разом не получится.

Описание приложения


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

В описании нельзя допускать различных толкований функциональности. Нельзя обещать то, чего в приложении ещё нет. Всё, что пользователь представил себе, читая текст, он должен получить в приложении. Если вы планируете новые функции в будущих релизах, то тогда и измените описание.

Ошибки в работе с политикой конфиденциальности


В описаниях «Политики конфиденциальности» чётко сказано, какие данные о пользователе и его активностях собирает приложение, как они хранятся, используются и кому передаются.

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

Ошибки в подготовке самого приложения


Здесь важно всё: дизайн, скорость работы и функциональность. 

Внешний вид приложения


Для дизайна на каждой платформе существуют специальные гайдлайны, которые направляют и ограничивают полёт фантазии. Подбор цветов, теней, шрифтов, анимаций, лучшие практики и частые ошибки — всё это прописано в гайдлайнах, и разработчик обязан ознакомиться с ними. 

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

У iOS и Android разные гайдлайны. У первого iOS гайдлайн называется Human Interface Guidelines, ознакомиться с ним можно здесь. У Android гайдлайн обширнее и разностороннее, он называется Material Design, познакомиться с ним можно здесь.

И самой очевидное — приложение должно быть полностью доработано. Нельзя оставлять неработающие затычки в виде картинок с элементами пользовательского интерфейса и «рыбные тексты» типа Lorem inpsum.

Функции и баги


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

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

Ссылки на инструкции маркетов по загрузке и релизу приложений


App Store менее лояльный к разработчикам — так что требований и гайдлайнов релизов много.


С Google Play всё как будто попроще — но требований всё равно очень много.

  • Отправиться в путешествие по изучению требований к публикуемым приложениям можно с главной странице маркета.
  • Обязательно отдельно надо изучить правила публикаций — требования к контенту и содержанию приложений в Центре правил Google Play. Из-за несоблюдения этих правил сборку точно отклонят  
  • И обязательно прочитайте соглашение пользователя — вот здесь. 
Мечтаете собрать собственное приложение и потом легко научиться публиковать приложения в маркетах? Этому мы учим на нашем курсе мобильной разработке без кода! Преподаватели за руку проведут вас через все тонкости мобильной разработки и процесса его релиза - осталось только освоить No-code! 
2022-11-11 12:53 Как делать