Приложение для ресторана на Flutter и WebView: кейс гриль-баров

Зачем ресторану своё приложение, если есть мобильная версия

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

Удержание считают просто: какая доля клиентов, сделавших первый заказ, вернулась через 30, 60 и 90 дней. В приложении эта цифра видна по каждому пользователю, а на сайте без авторизации половина гостей остаётся анонимной. Уже одно это помогает понять, какие акции действительно возвращают людей.

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

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

Нативное, кросс-платформенное или WebView: что выбрать

Стоимость мобильного продукта сильно зависит от подхода. Два отдельных нативных приложения на Swift и Kotlin — это две кодовые базы и две команды. Кросс-платформа и WebView сокращают объём работы, но у каждого варианта свои ограничения.

Flutter для приложения ресторана

Flutter — открытый фреймворк Google на языке Dart. Стабильная версия 1.0 вышла в декабре 2018 года. Из одной кодовой базы собираются сборки для iOS и Android, интерфейс рисуется собственным движком и выглядит одинаково на обеих платформах. Для меню, корзины, профиля и истории заказов этого с запасом хватает.

WebView-приложение: что брать с сайта

WebView встраивает веб-страницу внутрь приложения. Удобно отдать туда то, что часто меняется и уже хорошо работает на сайте: каталог, акции, страницы с текстом. Корзину, авторизацию и пуши лучше делать нативно через API. Тогда приложение ощущается приложением, а не сайтом в рамке.

Этот баланс важен и для модерации. В правилах App Store есть пункт 4.2 о минимальной функциональности: приложение, которое просто показывает сайт, Apple может отклонить. Наш гибрид модерацию прошёл легко.

Как устроены пуш-уведомления

На iOS пуши доставляет сервис Apple Push Notification service, на Android — Firebase Cloud Messaging. Обычно оба канала подключают через Firebase, чтобы отправлять рассылки из одного места. Пользователь даёт разрешение при первом запуске, и от того, как попросить, зависит доля согласившихся.

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

Для общепита лучше всего работают служебные пуши: заказ принят, курьер выехал, заказ у двери. Их ждут, и они приучают открывать уведомления. Рекламные рассылки разумно ограничить одной-двумя в неделю и сегментировать: тем, кто заказывает по пятницам, присылать предложение в пятницу днём, а не в понедельник утром. Сегменты строят по истории заказов, которая в приложении есть с первого дня.

Из чего складываются сроки и бюджет

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

Отдельно стоит учесть обязательные платежи площадкам. Аккаунт разработчика Apple Developer Program стоит 99 долларов в год. В Google Play регистрация разовая, 25 долларов. Ещё нужны время на модерацию, тестовые сборки через TestFlight и бюджет на обновления под новые версии систем.

Наш вариант уложился в 1 млн рублей вместе с пушами. Для сети, которой полноценное приложение казалось неокупаемым, это и решило вопрос.

План запуска по шагам

• проверить, какие разделы сайта можно показать через WebView без переделки;
• выделить нативные экраны: вход, корзина, оформление, профиль;
• подготовить API для этих экранов на стороне сайта;
• собрать приложение на Flutter и подключить пуши;
• пройти модерацию в App Store и Google Play;
• после запуска смотреть установки, повторные заказы и отписки от пушей;
• постепенно переводить WebView-экраны на API.

Типичные ошибки

Чаще всего бюджет съедают не экраны, а решения, принятые до старта.

• сразу заказывать два нативных приложения, не проверив спрос;
• показывать весь сайт через WebView и получить отказ на модерации;
• не продумать, зачем пользователю устанавливать приложение, кроме скидки за установку;
• забыть про поддержку: новые версии iOS и Android выходят каждый год;
• рассылать пуши слишком часто.