Как построить разработку мобильного приложения, если уже есть интернет-магазин

Дмитрий Важенин, коммерческий директор Creonit, рассказал, зачем ритейлу нужно мобильное приложение в 2023 году и как создать его не с нуля, если уже есть функционирующий интернет-магазин. В статье — процесс разработки приложения поэтапно.

Зачем ритейлу мобильное приложение в 2023 году

Десктоп теряет популярность, в то время как доля мобильного трафика растёт — пользователи всё чаще сидят в смартфонах. E-commerce нужно аккуратно встраиваться в их «мобильную» жизнь.

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

Почему так происходит? Посмотрим на данные из исследований и статистики.

Мировая статистика

59% мирового интернет-трафика приходится на смартфоны — следует из данных отчёта Global Digital 2023. Сегодня 92,3% пользователей заходят в интернет через мобильные устройства.

Это влияет на длительность сессий в приложениях. В 2021 году пользователи провели в сервисах для покупок более 100 млрд часов. Среднее время шопинга через приложения растёт каждый год (Данные Data AI).

В 2021 году 67% продаж в e-commerce произошло в мобильных приложениях. Это на 14% больше, чем в 2020. Ежегодно этот показатель растёт. Мобильные приложения — самый популярный инструмент электронной коммерции.

Результаты опроса Newstore в 2022 году показывают, что 60% потребителей предпочитают покупать именно в приложениях, а не через браузер в смартфоне. Причина — у сервисов лучший UX. 

Также в приложениях чаще завершают транзакции. 54% всех завершённых платежей в m-commerce приходится именно на приложения, по данным JP Morgan.

Данные по России

Опрос Яндекс Маркета и GfK Rus показывает, что с 2017 года число онлайн-покупателей в России выросло почти вдвое.

Доля покупок с мобильных устройств растёт и уже превысила 67%. Люди почти в четыре раза чаще пользуются приложениями магазинов, чем сайтами.

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

Мобильный трафик растёт, и эта тенденция становится сильнее с каждым годом. Интернета-магазинам нужно встраиваться в «мобильную» жизнь потребителей, чтобы не терять аудиторию.

Разработка мобильного приложения на существующем бэкенде

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

Какие могут быть сложности с бэкендом и API

Мобильное приложение — это клиентская часть, то есть интерфейс. Ему важно работать на «хорошем» бэкенде с хорошо задокументированным API. Через него приложение взаимодействует с базой данных, серверной частью и бизнес-логикой.

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

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

Например, если магазин сделан на коробочном решении («1С-Битрикс» или другом), бэкенд придётся долго переписывать, чтобы и сайт, и мобильное приложение работали через API (можно разработать API к Битриксу, но это весьма специфичная задача. Если у вас такая ситуация — напишите нам, мы посоветуем, что можно сделать). Ещё вариант — написать API отдельно, но это приведёт к рассинхронизации функциональности в цифровых продуктах, так как бэкенд будет разный. Все функции нужно будет писать отдельно для API (мобильного приложения) и сайта — то есть делать в два раза больше работы. 

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

Так у обоих продуктов появится единая точка входа — общее API. Можно переделать бизнес-логику на бэкенде, и изменения одновременно появятся на сайте и в мобильном приложении. Например, если поменять способ сортировки в каталоге или работу с остатками, то информация обновится разом на обеих платформах.

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

Как работать, если нужно оставить коробочное решение

Бывают кейсы, когда бизнес не готов отказаться от условного «1С-Битрикса» по разным причинам. Но мобильное приложение всё равно нужно запустить, чтобы освоить новые каналы продаж. 

В таком случае можно рассмотреть решение: 

1. Разработать новый бэкенд в виде RESTful API, используя «1С-Битрикс». Но во время такой разработки будет много проблем — в CMS недостаточно внутренних инструментов.

2. Интегрировать в RESTful API старый фронтенд интернет-магазина — взять его вёрстку и переписать с помощью реактивного фреймворка.

3. Написать клиентскую часть (фронтенд) мобильного приложения и тоже интегрировать её в API.

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

Как разработать мобильное приложение не с нуля

Итак, у бизнеса уже есть функционирующий интернет-магазин. Встал вопрос о разработке мобильного приложения. Расскажу поэтапно, как построить работу.

Шаг 1: составить документацию

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

Что нужно описать:

1. Все бизнес-процессы.

2. Диаграммы взаимодействия систем друг с другом.

3. С какой периодичностью данные обмениваются между системами.

4. Способы обмена данными.

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

Шаг 2: продумать инфраструктуру, которая будет отвечать бизнес-задачам

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

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

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

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

Ещё сайт обычно интегрирован с разными системами — email-рассылками, CRM-платформами и другими сервисами. Им  нужны данные из сайта и мобильного приложения для работы. Обмен этими данными продумывают в момент проектирования новой инфраструктуры. 

Шаг 3: выбрать подход к разработке бэкенда

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

Вариант 1:  разработать отдельное API для мобильного приложения, но это приведёт к рассинхронизации функциональности, как я говорил выше.

Вариант 2: Использовать текущее API или разработать новый бэкенд + API к нему (затем потребуется фронтенд доработать под API). И можно приступать к разработке мобильного приложения. Так функциональность во всех продуктах будет идти нога в ногу. Не возникнет кейсов, когда в приложении есть «Избранное», а на сайте — нет, потому что логику меняют отдельно на разных платформах. Также не придётся раздувать команду бэкенд-разработчиков.

Шаг 4: выбрать модель разработки мобильного приложения

Существуют две модели — нативная и кроссплатформенная разработка.

В нативной разработке отдельно пишут два приложения под iOS и Android с помощью разных языков программирования. У такой разработки несколько минусов:

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

2. Дольше выход на рынок, потому что сроки разработки больше.

3. Распространено мнение, что у нативных приложений выше производительность в сравнении с кроссплатформенными. На самом деле это не так. Например, приложения на Java работают медленно, и им требуется JIT-компиляция — специальная технология для ускорения работы.

4. Нативные приложения занимают больше памяти и быстрее тратят заряд батареи, чем кроссплатформенные.

Кроссплатформенные приложения делают с помощью общей кодовой базы сразу для iOS и Android. Для этого используют кроссплатформенные фреймворки. Два самых популярных — React Native и Flutter.

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

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

Шаг 5: интегрировать фронтенд веб-сайта и мобильного приложения в API

Если действовать по API-based подходу, то бэкенд и фронтенд мобильного приложения можно разрабатывать практически параллельно. Это уменьшает сроки разработки в 2 раза. Затем фронтенд веб-сайта и приложения интегрируют в API. За счёт этого добиваются синхронизации функциональности в обоих продуктах, как я говорил выше.

Шаг 6: сборка приложения и деплой

Сборка — это получение цифрового продукта из исходного кода для его тестирования и публикации в сторах. Она бывает ручной и автоматической. 

Ручная сборка приложения занимает до 30 минут. В течение дня перед деплоем нужно сделать 3-5 сборок — это может занять почти весь рабочий день. Автоматизированная сборка заменяет ручной труд скриптами — это ускоряет процесс.

Для автоматизированной сборки приложений под Android в Creonit разработали собственный продукт — Creonit Cargo. Для iOS можно использовать FastLane — этот сервис взаимодействует с консолью App Store, подписывает приложения и управляет сертификатами. Также он автоматизирует сборку iOS-приложения и его загрузку в TestFlight — систему для бета-тестирования под разные платформы Apple (macOS, iOS, ipadOS).

Шаг 7: публикация приложения в App Store и Google Play

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

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

Во время обновления приложения тестировщики сторов не заходят в сервис дальше экрана авторизации, поэтому не замечают подмены. Но это «костыльное» решение, которое может не сработать, если попадётся неленивый тестировщик.

Шаг 8: развитие продукта и разработка новой функциональности

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

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

У API-based подхода есть ещё одно преимущество — возможность менять начинку приложения без обновлений и ревью в сторах.  

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

Это позволяет создавать новые страницы в цифровом продукте, запускать А/B-тесты и легко менять элементы навигации. Обновления появляются на всех платформах сразу и без проверки магазинами.

Пример

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

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

Выводы

Если у бизнеса уже есть веб-версия интернет-магазина, мобильное приложение можно разработать на основе существующего бэкенда.

Чтобы синхронизировать обновление функций на сайте и в приложении, используют API-based подход. Делают общий бэкенд в виде API для обеих платформ, а потом интегрируют в него клиентскую часть мобильного и веб-приложения. Это позволяет разрабатывать бэкенд и фронтенд параллельно и релизить приложение в 2 раза быстрее.

Также общее API сокращает стоимость разработки и поддержки мобильного приложения. Не потребуется раздувать команду бэкенд-разработчиков.