Flutter или Ionic: что выбрать, если приложение работает со сканером и 1С

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

flutter и ionic: в чём разница для мобильного приложения бизнеса

Flutter — это Dart-код, который компилируется в нативный ARM-код и рисует интерфейс собственным движком (Skia, в новых версиях — Impeller) прямо поверх экрана, минуя браузерные компоненты. Отсюда плавные списки, анимации без рывков и прямой доступ к оборудованию через platform channels — мост между Dart-кодом и нативным Android/iOS SDK. Ionic собирает веб-приложение на Angular, React или Vue и упаковывает его в нативную оболочку через Capacitor: интерфейс рисует WebView устройства, то есть фактически внутри приложения работает встроенный браузер. Это дешевле и быстрее на старте — веб-разработчик пишет привычный код без Dart и Swift, порог входа ниже, — но каждая анимация, каждый скролл длинного списка и каждое обращение к камере или сканеру идёт через прослойку браузера и отдельные плагины.

что это меняет на практике для мобильных сотрудников

Разница заметна не в демо-версии на новом iPhone, а через полгода эксплуатации на реальных устройствах склада или курьера. Push-уведомления о новом заказе, биометрический вход по отпечатку, работа камеры при плохом освещении на складе — во Flutter это готовые нативные модули, в Ionic — отдельные плагины Capacitor, у части из которых давно не выходило обновлений под новые версии Android. Hot reload у обоих фреймворков ускоряет разработку интерфейса, но во Flutter он не ломает состояние сложных форм, а в Ionic результат зависит от того, как построено веб-приложение внутри.

Есть и разница на выходе из разработки. Приложение на Flutter — обычный нативный бинарник, который проходит модерацию Google Play и App Store так же, как любое другое native-приложение. Приложение на Ionic технически тоже нативное благодаря Capacitor, но если внутри осталось слишком много веб-логики без офлайн-функциональности, модераторы иногда просят доработать — площадки настороженно относятся к оболочкам, которые просто показывают сайт в рамке.

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

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

Летом торговая компания в Москве заказала приложение для 12 торговых представителей на Ionic — быстро и силами штатного веб-разработчика, без найма отдельной мобильной команды. Первый месяц всё шло гладко: каталог товаров, форма заказа, авторизация. Через два месяца выяснилось, что приложение должно печатать накладную на переносном термопринтере и читать штрихкод коробки прямо на складе поставщика, где интернет пропадает на полчаса при каждой смене. WebView не видел Bluetooth-принтер без нативного плагина, а офлайн-режим требовал переписывать хранение данных с нуля — веб-приложение внутри Capacitor изначально проектировалось в расчёте на постоянное соединение.

Плагин для принтера нашёлся на GitHub, но был написан под старую версию Capacitor и падал на Android 13 сразу после печати первого чека. Поэтому разработчик неделями чинил чужой код вместо того, чтобы дорабатывать саму логику заявок и обмен с 1С, ради которого всё затевалось.

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

как исправить ситуацию, если стек уже выбран и мешает разработке

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

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

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

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

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

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

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

как предотвратить ошибку выбора стека на старте следующего проекта

Прежде чем нанимать команду, стоит закрыть на бумаге несколько вопросов:

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

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

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

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

сколько стоит разработка приложения на flutter или ionic

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

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

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

Можно ли начать разработку на Ionic, а потом перейти на Flutter?

Технически да, но переход — это фактически новая разработка интерфейса и логики, а не апгрейд: код на Dart и код на JS/TS не переиспользуются. Компании обычно решаются на такой шаг, когда WebView перестаёт справляться с оборудованием или объёмом данных из 1С. Дешевле сразу спроектировать архитектуру на вырост.

Работает ли Flutter-приложение офлайн со сканером без интернета?

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

Сколько стоит разработка мобильного приложения с интеграцией 1С?

Разработка начинается от 500 000 руб., точная сумма зависит от числа экранов и глубины обмена с 1С. Если обмен идёт в реальном времени, добавляется аренда сервера для 1С от 1 100 ₽/мес за пользователя и сопровождение интеграции от 3800 руб/час — эти статьи считаются отдельно от разработки самого приложения.

Нужно ли отдельное мобильное приложение, если уже есть 1С:Мобильная платформа?

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

Как понять, что бизнесу вообще нужно приложение, а не веб-версия в браузере?

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