3 в 1: одно Flutter-приложение вместо мобильного, веб и десктопного

Приложение на Flutter собирается из одной кодовой базы сразу под iOS, Android, веб и десктоп (Windows, macOS, Linux). Компания получает единый интерфейс для склада, менеджеров и руководителя без трёх отдельных команд разработки и без рассинхрона версий между платформами.

Почему бизнес выбирает Flutter вместо трёх отдельных приложений

Отдел продаж просит мобильное приложение для курьеров. Бухгалтерия — веб-кабинет для сверки остатков. Директор хочет десктоп-версию на рабочем компьютере, чтобы не открывать браузер каждый раз. Три требования, три технических стека — Swift для iOS, Kotlin для Android, React для веба — и три счёта от разных подрядчиков.

Flutter решает это иначе: один код на Dart компилируется в нативные бинарники под каждую платформу. Кнопка, форма заказа или карточка товара пишется один раз, а дальше рендерится и на смартфоне курьера, и в браузере бухгалтера, и на десктопе директора. Google использует Flutter в собственных продуктах, а из крупных внедрений известны кейсы BMW и Toyota — обе компании перевели часть корпоративных инструментов на этот фреймворк, чтобы не держать параллельные команды под каждую платформу.

Что теряет бизнес, если делать три приложения отдельно

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

Как исправить рассинхрон версий между платформами

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

Единая кодовая база на Flutter убирает саму причину. Логика расчёта скидки, валидация формы заказа, синхронизация с 1С — это один модуль Dart, который используют все три сборки. Меняется правило расчёта — меняется в одном файле, и оно одинаково работает в приложении курьера, в веб-кабинете и в десктопной версии для склада. Это не ускоряет каждую отдельную правку кардинально, но исключает саму ситуацию, когда одна платформа отстаёт от других на релизный цикл.

Что делать, если приложение уже разрослось на несколько технологий

Часто компания приходит не с нуля, а с историей: мобильное приложение писали на Swift и Kotlin три года назад, потом добавили веб-версию на другом стеке, и теперь три команды поддерживают три разных проекта. Переписывать всё одним махом рискованно — бизнес-процессы завязаны на текущий функционал, и простой на время миграции недопустим.

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

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

Как предотвратить дублирование логики при разработке заново

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

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

Что делать, если ошибка синхронизации с 1С повторяется на разных платформах

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

Единая кодовая база здесь работает в плюс: если баг живёт в общем модуле синхронизации, чинить его нужно один раз, а не гоняться за тремя проявлениями одной проблемы. Но если после исправления кода ошибка на уровне сети или производительности базы повторяется — дело в инфраструктуре. Для 1С, которая обслуживает три канала одновременно (мобильный, веб, десктоп), это означает возросшую нагрузку на сервер, и решается перекладыванием базы на выделенные мощности: аренда сервера для 1С от 1 100 ₽/мес за пользователя с гарантированными ресурсами вместо офисного компьютера, который не рассчитан на постоянный обмен по трём каналам.

Flutter против нативной разработки: что выбрать для B2B-задачи

Сколько стоит разработка приложения 3 в 1 на Flutter

Разработка мобильного приложения с охватом веб- и десктоп-версии на Flutter начинается от 500 000 руб — итоговая цифра зависит от глубины интеграции с 1С, числа ролей пользователей и объёма бизнес-логики. Это не три отдельных бюджета, а один проект с тремя точками выхода: приложение в сторах, веб-версия по ссылке и десктопный клиент для установки на компьютеры сотрудников.

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

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

Чем Flutter отличается от обычной кроссплатформенной разработки?

Flutter компилирует один код Dart в нативные бинарники под каждую платформу — iOS, Android, веб, Windows, macOS, Linux. В отличие от гибридных решений на WebView, интерфейс не грузится в браузерном движке, а рендерится напрямую, поэтому по скорости работы близок к нативным приложениям.

Можно ли перевести уже готовое приложение на Flutter без остановки работы компании?

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

Выдержит ли наша 1С нагрузку от трёх интерфейсов сразу — мобильного, веб и десктопного?

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

Сколько времени занимает разработка приложения 3 в 1 на Flutter под ключ?

Срок зависит от объёма бизнес-логики и глубины интеграции с 1С — от нескольких месяцев на MVP с базовым функционалом до более длительных сроков для полноценной B2B-системы с ролями доступа и полным циклом документооборота.

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

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