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

До момента появления фреймворка Flutter (а это 2017 год), в мобильной разработке было 2 направления нативное и гибридное. Нативная разработка для iOS и Android была без ограничений для операционной системы, которая установлена на смартфоне. У гибридного в свою очередь таких ограничений достаточно (возникают сложности при работе с платформозависимыми задачами).

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

Предположительно, разработка стоит 1 миллион рублей (возьмем несложное приложение, например – функционал небольшого интернет-магазина и интеграция с вашей внутренней системой магазина, чат с продавцом и ответы на вопросы, удобная доставка товара). Все это обойдется вам в 3-4 миллиона для нужных платформ (дизайн и разработка под требования каждой системы). Проблема глобальная, которую необходимо было решать. Пользователи всё больше привязаны к своим смартфонам и покупают онлайн. Бизнесу необходимо быть доступными для пользователей, но не каждому это “под силу”.

И вот на рынке появляется гибридная разработка, цель которой: единая кодовая база, уменьшение трудозатрат и, соответственно, удешевление разработки. Благодаря гибридным приложениям в мобильную разработку могли прийти новые web разработчики, которые упаковывали html верстку в упаковщик (phonegap и Cordova) по принципу как упаковывают фотографии в zip архив.

Казалось бы, заказчик должен быть счастлив получить приложение за 500 т.р вместо 3-4 млн., но на практике всё выходит иначе. Для работы на мобильной платформе гибридному приложению приходилось создавать "прослойку" (виртуальную машину), через которую приложение взаимодействовало с операционной системой телефона и теряло много возможностей (полноценная работа с редактированием видео и звука, например, потеря FPC при проигрывания анимации).

“ВАУ-эффект” вашего клиента уходит сразу же после первого выпуска приложения в свет, то что было сложнее, чем обычная форма для сбора данных (например: “Оставьте ваш номер, и специалист свяжется с вами), начинало сильно тормозить и было пригодно только в качестве прототипа для узкого круга лиц.

Итог.
Клиент теряет деньги и вынужден вернуться к нативной разработке на основе прототипа. В данном случае такой подход может быть выгоден стартапу, т.к. презентовать свою идею инвестору можно (еще раз напомню плюсы: быстро и выгодно для заказчику). Но так как рынком управляет трезвая экономика, где разработка должна стоить ровно столько сколько приносит пользы для бизнеса, стали появляться новые решения в виде фреймворков на основе языка JavaScript.

Новый подход в лице Flutter и близкого родственника React Native, не запускают "прослойку" (виртуальную машину), а компилируются в нативный код для iOS и Android во время разработки. Разработка ведётся с единой кодовой базой, приложения не тормозят и по стоимости становится намного дешевле. Преимуществ новой технологии добавляет интегрированность с material design, что позволяет быстро собирать интерфейс.

Продвижение технологии Flutter в экосистеме Goоgle под предлогом замены Android на новую операционную систему Fuchsia в будущем, интерфейс которого создан с помощью «Flutter», даёт сильный рост в развитии данной технологии (при условии, если это произойдет всё же).

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

Еще раз преимущества:
1) Есть возможность быстро выпускать изменения, что очень удобно на начальных этапах разработки. За счет единой кодовой базы, релизы под обе платформы можно выпускать практически одномоментно.

2) позволяет сократить расходы на содержание сотрудников (или оплаты аутсорсинга) и потери при коммуникации между специалистами.

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

Мы не рекомендуем использовать Flutter, если приложение реализует сложные алгоритмы, которые завязаны на вычислительных мощностях устройства (например: обработка звука, изображений, сжатие данных и т.д.), если приложение по своей логике и архитектуре платформозависимое (когда подходы на iOS и Android ощутимо различаются).

Прямой конкуренции между React Native и Flutter нет, есть круг разработчиков, которые предпочитают простоту фреймворка от Goоgle.

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