Мобильное приложение для интернет магазина. Зачем нужно и на чем делать?

Одно из направлений нашей работы - это мобильные приложения для Интернет-магазинов. Мы прошли путь от нативных приложений к кроссплатформенным далее к PWA и попробовали много вариантов и технологий в разных проектах.

В данной статье мы дадим сравнительный анализ разных подходов, основанный на частых вопросах клиентов.

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

Количество аргументов "зачем нужно мобильное приложение" с годами становится меньше, но даже если признать, что большинство аргументов психологические – это всё равно аргументы.

В этом случае пишется отдельно приложение для Android (как правило, на Kotlin) и отдельно для iOS (как правило, на Swift).

При таком подходе можно выжать максимум из технологии, но это сказывается на стоимости и ресурсозатратности в дальнейшем для поддержки.

Нативное приложение дублирует интерфейсы сайта в виде двух независимых приложений: сделать сайт + приложение - это почти как сделать 3 сайта (с точки зрения программирования интерфейсов).

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

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

Экономия на ресурсах и стоимости разработки минимум в 1.5 раза, но это все равно почти как сделать второй сайт.

Получаем также ряд минусов:

Отметим более современные фреймворки, например Ionic framework.

Этот фреймворк для разметки интерфейса ориентируется на стандартный HTML-формат и специальные теги внутри. Таким образом можно переиспользовать часть интерфейсов с сайта, адаптировав их для мобильного приложения – что сократит расходы ещё в 1,5 раза (особенно если Frontend сайта работает на популярном JS-фреймворке).

Существенных минусов по сравнению с React Native у этого подхода не обнаружено.

Принципиально другой подход и немного другой результат.

При этом оно не публикуется в сторах.

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

Плюсы:

Минусы:

Если мобильная версия вашего сайта работает плохо – это передастся и приложению тоже.

Чтобы обойти ряд ограничений обычных PWA, можно собрать полноценное приложение, внутри которого PWA будет зашито (точнее – веб-фрейм с сайтом).

С точки зрения телефона это уже полноценное приложение, а не PWA, и его можно выкладывать в AppStore и GooglePlay.

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

Логично, но мы нашли методы, как обходить ограничения и выкладывать приложения в AppStore, успешно проходя модерацию. Главное требование AppStore – чтобы в приложении был не только один элемент фрейма с сайтом, а какой-то нативный функционал. Делаем для iOS несколько типовых нативных экранов, нижнее меню – и этого достаточно.

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

Для лучшего понимания предлагаем ознакомиться с примером нашего приложения на базе этой технологии.

Такое приложение может работать с полноценными пушами, если встроить ему небольшое “нативное прокси”, которое будет принимать пуш и передавать данные дальше внутрь самого приложения.

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

Ощущения от работы с плавным нативным приложением куда приятнее – но стоят ли они разницы в стоимости разработки и сложности в поддержке, которая может отличаться в 50 (!) раз?

Большинство даже крупных игроков на рынке e-commerce приходят к мнению, что оно того не стоит: видим явный тренд к уменьшению количества таких эффектов в популярных приложениях.

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

Существует отдельный класс сервисов, предлагающие разные варианты сборки приложения для магазина на базе готового решения. Как правило, это какое-то базовое приложение с фиксированным или настраиваемым интерфейсом (или даже конструктором), куда через готовые механизмы подгружается каталог.

Плюсы такого подхода – стоимость еще дешевле. Часто сборка вообще бывает бесплатной и дальше только небольшая абонентскую плату.

Неважно, на каких технологиях собрано само приложение – важно, что доступа к его коду у вас, как правило, нет: вы сильно ограничены в возможностях влиять на это приложение и его функционал (по умолчанию довольно скудный) в целом.

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