flutter и dart для бизнеса: одна кодовая база вместо ios- и android-команд

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

почему возникают расхождения между ios- и android-версиями приложения

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

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

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

что такое flutter и dart и как они закрывают эту проблему

Flutter — открытый SDK Google, вышедший в стабильную версию в 2018 году. Приложение пишут один раз на языке Dart, а компилятор превращает этот код в нативный ARM-бинарник отдельно для iOS и отдельно для Android — без прослойки-интерпретатора, как в старых гибридных фреймворках. Интерфейс Flutter не берёт готовые кнопки и списки из iOS или Android: он рисует каждый пиксель сам через собственный движок (Impeller, с 2023 года заменивший Skia на новых сборках), поэтому кнопка выглядит и ведёт себя одинаково на обеих платформах, а не «почти одинаково».

Dart компилируется в двух режимах: JIT — для разработки с hot reload, когда правку в коде видно на экране симулятора за секунду, и AOT — для релизной сборки, когда код превращается в машинный код заранее и приложение стартует так же быстро, как нативное на Swift или Kotlin.

Отдельный плюс для проекта с частыми правками — hot reload: разработчик меняет отступ, цвет кнопки или текст экрана и видит результат на экране за секунду, без пересборки всего приложения. На практике это ускоряет согласование интерфейса с заказчиком: правки, которые в нативной разработке ждали следующей сборки, в Flutter показывают на созвоне сразу.

Для владельца бизнеса это одна команда вместо двух, один баг-трекер вместо двух и релиз для iOS и Android в одну дату, а не с разрывом в пару недель, пока вторая платформа доедет.

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

как исправить типичные ошибки при переходе на flutter

Часть проблем с Flutter создают не технология, а сами разработчики. Три ошибки повторяются от проекта к проекту.

Первая — бездумный rebuild всего дерева виджетов при любом изменении состояния: список из тысячи товаров перерисовывается целиком при вводе каждой буквы в поиске, и приложение подвисает на слабых Android-смартфонах склада. Чинится разбивкой состояния на отдельные виджеты через Provider или Riverpod и пометкой статичных частей интерфейса как const — тогда Flutter пропускает их при перерисовке.

Вторая — перенос тяжёлых операций (разбор большого XML-ответа от 1С, шифрование, работа с фото) в основной поток. Интерфейс замирает на несколько секунд, пользователь решает, что приложение зависло, и закрывает его. Исправление — вынести операцию в отдельный isolate: Dart умеет считать в параллельном потоке без общей памяти специально для таких случаев.

Третья — прямой перенос логики нативного приложения без учёта разницы в жизненном цикле. iOS выгружает приложение из памяти иначе, чем Android, и если сессия работы с 1С хранилась только в оперативной памяти, при возврате в приложение пользователь видит пустой экран вместо своей корзины заказов. Решение — сохранять состояние сессии локально (Hive, SQLite) и восстанавливать его при запуске, а не рассчитывать, что процесс не завершится.

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

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

Для бизнеса цена вопроса — не только раздражённые продавцы. Каждый повтор одной и той же ошибки после апдейта — потерянное доверие к приложению: сотрудники возвращаются к заявкам по телефону и в Excel, а разработка, за которую заплатили, простаивает.

Что останавливает цикл: подключить сбор крашей (Firebase Crashlytics или аналог) и смотреть статистику падений по моделям телефонов, а не гадать; завести автоматические UI-тесты хотя бы на ключевые сценарии — оформление заказа, синхронизация с 1С, вход по логину; и, главное, зафиксировать контракт API между приложением и 1С отдельным документом, чтобы обновление структуры обмена на стороне 1С не ломало мобильную часть без предупреждения. Мы настраиваем этот процесс при интеграции приложения с 1С — обмен идёт через версионируемый REST/OData-слой, а не напрямую в базу, поэтому обновление 1С не роняет мобильное приложение в проде.

как предотвратить провал мобильного проекта на старте

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

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

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

Отдельно стоит закрыть вопрос персональных данных: если приложение хранит контакты клиентов или фото документов офлайн на телефоне сотрудника, это персональные данные по 152-ФЗ, и локальное хранилище нужно шифровать, а не полагаться на то, что телефон не потеряют.

сколько стоит flutter-приложение с интеграцией 1С

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

Подробный расчёт под конкретный сценарий — на странице тарифов, а базовый разбор форматов работы — на странице разработки мобильных приложений.

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

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

Чем Flutter отличается от React Native для приложения с 1С?

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

Можно ли переписать нативное приложение на Flutter без остановки бизнеса?

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

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

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

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

Да, если это заложено в архитектуру заранее: приложение хранит данные локально в базе на телефоне (Hive, SQLite), кладовщик продолжает работать без сети, а при появлении интернета очередь операций синхронизируется с 1С автоматически. Без такой логики на старте офлайн-режим потом придётся встраивать отдельным дорогим этапом.

Чем Flutter-приложение отличается от типовой 1С:Мобильной платформы?

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