Flutter для интернет-магазина: одна кодовая база вместо двух приложений

Flutter собирает одно мобильное приложение интернет-магазина сразу под iOS и Android из общего кода: каталог, корзина, push-уведомления и программа лояльности пишутся один раз вместо двух параллельных проектов. Для бизнеса в Москве это на месяцы короче срок выхода в обе сторы и один бюджет на доработки вместо двух отдельных команд разработчиков.

почему покупатель уходит к конкуренту, пока вы выбираете между iOS и Android

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

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

три способа собрать приложение и чем они отличаются на практике

У решения «своё мобильное приложение» есть три технических пути, и цена ошибки в выборе — не абстрактная, а в сроках выхода на обе платформы и в бюджете на сопровождение после релиза. Выбор редко очевиден заранее: подрядчик, который зарабатывает на человеко-часах, скорее предложит два отдельных native-проекта, чем один Flutter-проект с меньшим объёмом работы.

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

почему интерфейс выглядит одинаково на iPhone и бюджетном Android

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

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

что даёт единая кодовая база продажам, а не только разработчикам

Чёрная пятница или распродажа остатков требует, чтобы баннер, push-рассылка и изменённая цена появились в обоих приложениях одновременно — на Flutter это одна сборка, а не две согласованные по времени версии от разных подрядчиков. Программа лояльности с накопительными баллами, персональной скидкой ко дню рождения и push-напоминанием о брошенной корзине пишется один раз и работает одинаково для владельцев iPhone и Android-телефонов, а не «сначала для одних, потом для других через месяц», пока часть покупателей уже забыла о недособранном заказе.

Разница ощущается и в самой публикации: приложение в Google Play обычно проходит модерацию быстрее, а iOS отправляет сборку на ревью команде Apple, и там счёт идёт на дни. Когда обе версии собираются из одного кода одной командой, вы подаёте обе заявки на модерацию в один день, а не догоняете вторую платформу через несколько недель после первой — и не объясняете покупателям в отзывах, почему «приложение только для айфона».

синхронизация с 1С: где приложение чаще всего врёт покупателю

Если каталог в приложении не связан с остатками в 1С напрямую, а обновляется выгрузкой раз в сутки, покупатель оформляет заказ на товар, который уже продан в рознице этим же утром. Заказ отменяется, деньги возвращаются на карту через несколько дней, а в отзыве магазина появляется жалоба на «нет в наличии после оплаты» — это не единичный случай, а системная дыра в архитектуре, которая повторяется на каждой распродаже с ограниченным остатком.

Рабочая связка выглядит иначе: приложение забирает остатки, цены и статус заказа из 1С через API в момент открытия карточки товара и при оформлении заказа, а не по расписанию. Тот же канал отдаёт push-уведомление, когда заказ собран, передан в доставку или готов к самовывозу — вместо звонка из контакт-центра с тем же вопросом. Для розничного магазина это описано в кейсах интеграции мобильного приложения с 1С; если часть покупателей — оптовые клиенты с персональными ценами, лимитами и историей заказов, им нужен отдельный контур вроде B2B-приложения с 1С, а не витрина розницы с общим прайсом. Отдельно стоит учитывать, что приложение хранит телефоны, адреса и историю покупок клиентов — это персональные данные, и на их обработку распространяется 152-ФЗ: согласие на обработку и место хранения базы нужно продумать на этапе проектирования, а не после первой проверки или жалобы клиента.

сколько стоит Flutter-приложение и когда оно себя окупает

Разработка мобильного приложения с нуля начинается от 500 000 рублей — в эту сумму входит одна кодовая база под iOS и Android, что дешевле суммы двух отдельных native-проектов и минимум одного дополнительного Android-разработчика в штате на постоянное сопровождение. Итоговая цена зависит от количества экранов, глубины интеграции с 1С, наличия отдельного B2B-контура для оптовых клиентов и от того, нужна ли программа лояльности с баллами или достаточно купонов.

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

чек-лист: когда Flutter — точный выбор, а когда нет

Flutter оправдан, если верны минимум три пункта из четырёх:

• ✓обе платформы нужны сразу, а не поэтапно — доля Android в трафике сайта уже сопоставима с iOS;
• ✓каталог и остатки должны обновляться из 1С в реальном времени, иначе бизнес регулярно теряет заказы на отменах;
• ✓команда сопровождения небольшая, и разработку двух отдельных native-приложений тянуть параллельно некому;
• ✓бюджет на первый релиз ограничен, а повторная разработка «под вторую платформу через квартал» в план не заложена.

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

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

❓ Частые вопросы

Сколько стоит разработка Flutter-приложения для интернет-магазина?

Разработка мобильного приложения на Flutter начинается от 500 000 рублей — сумма покрывает одну кодовую базу под iOS и Android вместо двух отдельных native-проектов. Итоговая цена зависит от числа экранов, глубины интеграции с 1С и наличия отдельного B2B-раздела для оптовых клиентов; точный расчёт делают по конкретному списку функций.

Чем Flutter лучше React Native для интернет-магазина?

Flutter рисует интерфейс собственным движком без нативных элементов операционной системы, поэтому анимации каталога и корзины остаются плавными и одинаковыми что на iPhone, что на бюджетном Android-смартфоне. React Native чаще требует нативных модулей под сложную графику, а значит отдельных доработок и более долгого сопровождения под каждую платформу.

Как приложение синхронизируется с остатками в 1С?

Приложение забирает цены, остатки и статус заказа из 1С через API в момент открытия карточки товара и оформления заказа, а не по ночной выгрузке раз в сутки. Это исключает продажу товара, которого уже нет на складе, и рассылает покупателю push о смене статуса заказа вместо звонка из контакт-центра.

Нужно ли отдельное приложение, если у магазина уже есть мобильная версия сайта?

Мобильный сайт теряет корзину между визитами и не умеет присылать push-напоминания о брошенном заказе или персональной скидке ко дню рождения. Приложение хранит данные покупателя на устройстве и открывает прямой канал связи с ним — push вместо email, который часто остаётся непрочитанным, — а это увеличивает долю повторных покупок.

Можно ли добавить оптовый B2B-раздел в то же приложение?

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