Dart для Flutter: почему язык подходит для бизнес-приложений

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

4 сентября 2026 Технологии 16 мин чтения

---

Что такое Dart и почему на нём написан Flutter

Dart — язык программирования, который Google выпустил в 2011 году и с выходом Flutter развивает прежде всего как язык мобильной и клиентской разработки. Формулировка для бизнеса короче: когда компания выбирает Flutter, чтобы сделать приложение для iOS и Android из одного кода, она вместе с ним выбирает и Dart. Другого языка у Flutter нет, весь продуктовый код будет написан именно на нём.

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

Выбор языка для Flutter объясняется требованиями, которые сначала выглядят взаимоисключающими. Во время разработки код нужно менять и видеть результат за секунды, без пересборки всего приложения. В выпущенном приложении тот же код должен работать без прослойки-переводчика между ним и системой — иначе страдает отклик, а магазины приложений предъявляют дополнительные требования к загружаемому исполняемому коду. Dart закрывает обе задачи, потому что умеет компилироваться двумя разными способами; сам разбор этого выбора опубликован в разделе вопросов и ответов документации Flutter.

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

Что язык даёт бизнесу: срок, команда, стоимость владения

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

Одна команда вместо двух

При разработке отдельно для iOS и отдельно для Android компания содержит два набора специалистов, две очереди задач и два набора ошибок. Функция «оплата долями» описывается дважды, тестируется дважды и выходит в двух разных выпусках. На Dart тот же экран пишется один раз для обеих систем — кроссплатформенная разработка на Flutter строится именно на этом. Ограничение честное: часть работы всё равно делается отдельно под каждую систему, и об этом ниже в разделе про границы.

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

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

Стоимость владения после запуска

Основные деньги продукт тратит после выпуска, а не до него. Здесь язык влияет двумя способами. Первый — доработка идёт в одном месте: правило «бонусами оплачивается не больше половины заказа» меняется один раз и уезжает на обе системы. Второй — строгая типизация ловит часть ошибок при сборке, до того как их увидит покупатель. Насколько это важно, видно по доле канала: в кейсе Gulliver Family через приложение проходит 80% мобильного трафика, а само приложение даёт 50% дохода ритейлера. Ошибка в таком канале стоит дороже любой экономии на технологии.

Как устроен Dart: две компиляции, типы и изоляты

Три свойства языка объясняют почти все его деловые следствия. Дальше — каждое из них с переводом на язык проекта.

Две компиляции — на лету и заранее

Компиляция — это перевод написанного человеком кода в инструкции, понятные устройству. Dart делает это двумя способами. Во время разработки код переводится на лету, порциями: поэтому изменение появляется на экране почти сразу. При выпуске код переводится заранее и целиком — в машинные инструкции конкретного устройства. Приложение в магазине не содержит переводчика внутри себя и не тратит на него время при запуске. Режимы сборки и различия между ними описаны в документации Flutter.

Практическое следствие: замерять скорость по сборке для разработки бессмысленно — она заведомо медленнее выпускаемой. Подробный разбор темы — в материале про производительность Flutter-приложения.

Типы и защита от пустых значений

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

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

Изоляты: тяжёлая работа вне интерфейса

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

Одна кодовая база: приложение, сайт и четыре магазина

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

Российская специфика делает это свойство дороже, чем оно выглядело пять лет назад. Приложение публикуется не в двух магазинах, а в четырёх: к App Store и Google Play добавились RuStore и AppGallery. Каждая площадка проверяет сборку по своим требованиям — правила App Store и Google Play различаются по разделам о содержании и разрешениях. При двух нативных приложениях каждое обновление готовится дважды, при одной кодовой базе — один раз, а различия закрываются настройками сборки.

Сайт из того же кода — отдельный разговор, где важно не переоценить возможность. Общими становятся правила и данные, а не всё подряд.

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

Где у Dart границы: чего язык не решает

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

Системные возможности требуют платформенного кода

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

Серверная часть пишется не на Dart

«Один язык на весь проект» на практике не получается. Серверную часть на Dart пишут редко: у языка нет сопоставимой экосистемы для этой задачи. В наших проектах серверная часть — это Python и Django, база данных — PostgreSQL, а разработчики серверной части работают отдельно от мобильной команды. Ожидание «наймём Flutter-разработчика, он закроет и сервер» — источник сорванных сроков.

Зависимость от одного поставщика технологии

Dart и Flutter развивает Google, и это осознаваемое условие выбора. Смягчается оно тремя вещами: открытым исходным кодом обоих проектов, большим сообществом сопровождающих и тем, что бизнес-правила продукта в любом случае живут на сервере, а не в мобильном приложении. Полностью такой зависимости не избежать ни на одном стеке: Swift и Kotlin точно так же принадлежат Apple и JetBrains вместе с Google.

Типичные ошибки в проектах на Dart

Ошибки ниже встречаются в проектах, которые приходят к нам на аудит кода. Ни одна из них не связана со свойствами языка — все связаны с тем, как язык применили.

1. Правила бизнеса записаны внутри описания экрана. Расчёт скидки живёт в карточке товара, а не в отдельном слое. Через год такое правило меняется в семи местах, и в одном из них его забывают.
2. Отказ от типизации. Величины объявляются «чем угодно», и преимущество строгой типизации исчезает вместе с ними: ошибки снова находятся у покупателя, а не при сборке.
3. Защита от пустых значений обойдена принудительно. При переносе старого кода разработчик расставляет знаки «здесь точно есть значение», чтобы сборка прошла. Приложение начинает падать там, где значения не оказалось.
4. Тяжёлые вычисления в основном потоке. Разбор большого ответа сервера идёт там же, где рисуется интерфейс — экран замирает на открытии каталога. Лечится выносом в отдельный изолят.
5. Заброшенные сторонние пакеты. Готовые библиотеки экономят недели, но пакет без обновлений полтора года останавливает обновление всего приложения при выходе новой версии системы.
6. Нет автоматических проверок при сборке. Статический анализатор и тесты не встроены в процесс — и правило «код без предупреждений» держится на договорённостях, а не на инструменте.

Все шесть находятся до передачи проекта другой команде и до крупной доработки. Отдельный разбор устройства кода — аудит мобильного приложения, интерфейсной части — аудит UX/UI.

Метрики: по каким числам видно качество кода

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

Пороговые значения по доле медленных кадров и способ их расчёта Google публикует в документации Android для разработчиков; приложение с показателями хуже порога получает предупреждение в консоли разработчика. Как связать эти числа с продуктовыми — в материале про аналитику мобильного приложения.

Чек-лист: как проверить проект на Dart

Список пригодится в двух случаях: когда приложение принимают у подрядчика и когда его передают другой команде. Проходится он вместе с разработчиками и занимает одну встречу.

1. Правила расчёта заказа, скидок и бонусов вынесены в отдельный слой, а не записаны внутри экранов.
2. Строгая типизация и защита от пустых значений включены; принудительных обходов в коде единицы, и каждый объяснён.
3. Статический анализатор запускается при каждой сборке, основная ветка проходит его без предупреждений.
4. Есть автоматические тесты хотя бы на путь к оплате: каталог, корзина, оформление, оплата.
5. Список сторонних пакетов пересматривается; заброшенных зависимостей в критичных местах нет.
6. Тяжёлые операции вынесены из основного потока; замеры плавности снимаются на сборке для выпуска, а не для разработки.
7. Сборки для App Store, Google Play и RuStore собираются одной командой сборки, различия вынесены в настройки.
8. Права на исходный код, доступы к магазинам приложений и порядок передачи проекта зафиксированы в договоре.

Если пункты закрываются устно и без демонстрации, стоит запросить техническое задание и отчёт сборки: оба показывают состояние проекта точнее, чем описание в переписке.

Команда: кто пишет на Dart и как её собирают

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

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

Четвёртый вариант устроен иначе, и его стоит описать явно, чтобы не путать с подпиской на готовый сервис. Модульная платформа FITTIN написана на том же Dart, и работа с ней состоит из трёх частей. Первая — единоразовая интеграция под бренд за срок до 30 рабочих дней: настройка модулей, фирменный вид, подключение 1С, эквайринга и маркетплейсов, публикация в магазинах приложений. Вторая — ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности, так что собственная команда разработки для базового сопровождения не требуется. Третья — новый функционал и доработки, они считаются отдельно по фактически затраченным часам с оценкой перед стартом задачи. Состав пакетов и суммы — на странице тарифов, готовый продукт на этом стеке — мобильное приложение для интернет-магазина и Flutter-приложение для e-commerce.

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

Кейсы: где выбор языка дал измеримый результат

Язык редко становится темой отдельного проекта — он проявляется в сроке, охвате площадок и стоимости изменений. Три проекта ниже показывают все три эффекта.

Ещё два среза. В кейсе «Европа Маркет» — 149 839 пользователей и сканер штрихкода как рабочий инструмент покупателя в торговом зале: сценарий, где отклик приложения важнее набора функций. В кейсе Street Beat за пять месяцев после запуска приложение органически привлекло 130 000 пользователей, а команда закрыла 700+ задач и выпустила 7 обновлений — темп изменений, который одна кодовая база поддерживает дешевле двух. Остальные проекты — в разделе кейсов.

Итог: Dart для бизнеса на одной странице

Коротко о том, что стоит забрать из разбора:

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

Что делать дальше:

• Проверить, в каком состоянии код текущего приложения — аудит кода или аудит мобильного приложения.
• Усилить команду профильными инженерами — аутстаффинг Flutter- и Dart-разработчиков; передать выпуски и обновления подрядчику — техническая поддержка приложений.
• Посмотреть, как устроена разработка на этом стеке — кроссплатформенная разработка на Flutter, приложения для iOS, приложения для Android и мини-приложения в Telegram.
• Сравнить подходы до старта — Flutter или нативная разработка и языки программирования для мобильных приложений; описать задачу — контакты.

Вопросы и ответы

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

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

Чем Dart отличается от Kotlin и Swift с точки зрения владельца продукта?

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

Приложение на Dart работает медленнее нативного?

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

Можно ли написать на Dart серверную часть?

Технически можно, на практике так делают редко: у языка нет сопоставимой экосистемы готовых решений для серверных задач, а найти специалистов сложнее. В наших проектах серверная часть — Python и Django с базой данных PostgreSQL, а Dart остаётся в мобильном приложении и веб-версии. Ожидание «один язык закроет и приложение, и сервер» лучше не закладывать в план.

Насколько сложно найти Dart-разработчиков в России?

Пул специалистов меньше, чем у JavaScript и Kotlin, поэтому найм занимает больше времени. Смягчает это порог входа: разработчик с опытом на Kotlin или TypeScript узнаёт синтаксис и правила типизации и обычно выходит на рабочий темп за несколько недель. По нашему опыту дефицитен не язык, а опыт в электронной торговле: работа с большими каталогами, интеграции с 1С, программы лояльности.

Что будет с продуктом, если Google перестанет развивать Dart?

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

Можно ли перевести существующее нативное приложение на Flutter и Dart?

Да, и это делается двумя способами. Первый — перенос целиком, когда функционал собирается заново на новом стеке; так шёл проект Finn Flare, где базовый функционал перенесли за срок менее 30 рабочих дней, а бюджет на развитие продукта стал меньше в 2,5 раза за счёт одной кодовой базы вместо двух. Второй — постепенный, когда новые экраны добавляются в существующее приложение, а старые остаются на месте. Выбор зависит от объёма функционала и от того, насколько понятен код текущего приложения, — это выясняет аудит перед стартом.

Работают ли приложения на Dart в RuStore и AppGallery?

Да, сборки для российских магазинов приложений готовятся из той же кодовой базы, что и для App Store и Google Play, — различия выносятся в настройки сборки. Отдельно проверяются службы, которые в этих магазинах устроены иначе: доставка уведомлений и карты. Обычно это отдельный пункт в объёме работ, а не переписывание приложения: в кейсе «Сатурн» приложение опубликовано сразу в четырёх магазинах приложений, а конверсия в покупку в первый месяц составила 12,4%.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.