Где работает Flutter: мобильные, веб и десктоп из одного кода

По данным Stack Overflow Developer Survey 2024, Flutter входит в число наиболее популярных фреймворков: им пользуются около 9% всех опрошенных разработчиков. По данным Statista, Flutter уже несколько лет занимает первое место по доле использования среди кроссплатформенных мобильных фреймворков — порядка 46% разработчиков кроссплатформы выбирают именно его. Главный аргумент — охват платформ: с выходом Flutter 3 в мае 2022 года шесть целевых платформ получили статус stable: iOS, Android, веб, Windows, macOS и Linux. Но «один код на всё» — это маркетинговый тезис, а не техническая гарантия. Разберём, где кроссплатформенная разработка на Flutter даёт переиспользование почти 100%, а где без платформенного кода не обойтись.

Содержание

• Что значит «один код — все платформы» (и где у этого предел)
• Как Flutter запускается на разной платформе
• Мобильные приложения: iOS и Android
• Веб: когда Flutter Web оправдан, а когда нет
• Десктоп: Windows, macOS, Linux
• Embedded и нестандартные среды
• Что реально переиспользуется, а что пишут под платформу
• Когда выбирать Flutter для мультиплатформы, а когда нет
• Часто задаваемые вопросы

Что значит «один код — все платформы» (и где у этого предел)

Идея Flutter — написать бизнес-логику, модели данных и большую часть UI один раз на Dart, а затем скомпилировать под нужные целевые платформы. Это работает благодаря двум ключевым архитектурным решениям: собственному движку рендеринга и слою embedder.

В отличие от React Native, который транслирует компоненты в нативные виджеты ОС, Flutter рисует UI самостоятельно — на canvas с помощью движка Skia (а в новых версиях — Impeller). Это означает, что кнопка во Flutter выглядит одинаково на Android, iOS и Windows, потому что её рисует сам фреймворк, а не операционная система. Пиксельная идентичность между платформами — буквальная.

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

Как Flutter вообще запускается на разной платформе

Движок и рендеринг (Skia → Impeller), Dart AOT/JIT

В основе Flutter — движок C++, работающий поверх графических API конкретной платформы. На iOS и macOS это Metal, на Android — Vulkan или OpenGL ES, на Windows — DirectX, на Linux — OpenGL, в браузере — WebGL/WebAssembly через CanvasKit. Пользовательский код на Dart компилируется в нативный машинный код через AOT (Ahead-of-Time) для продакшен-сборок, или через JIT для разработки с hot reload.

С Flutter 3.10+ используется Impeller — новый рендер, разработанный для устранения «шейдерных подтормаживаний» (shader jank), характерных для Skia. На iOS Impeller работает по умолчанию начиная с Flutter 3.10, на Android переходит в основной режим в Flutter 3.22+. Именно Impeller обеспечивает стабильные 60–120 fps на современных мобильных устройствах.

Embedder — «переходник» под конкретную ОС

Flutter-движок не знает, где он запущен — в браузере, мобильном приложении или десктопном окне. За интеграцию с каждой операционной системой отвечает embedder — платформенный слой, написанный на языке этой ОС: Objective-C/Swift для iOS и macOS, Java/Kotlin для Android, C++ для Windows и Linux. Embedder создаёт поверхность рисования, передаёт ввод (тапы, клавиатуру, мышь), управляет жизненным циклом приложения.

Именно embedder — точка расширения для нестандартных сред. Хотите встроить Flutter-окно в существующее нативное приложение? Это делается через embedder API. Хотите запустить Flutter на автомобильном дисплее под кастомной Linux? Пишете embedder под его графический стек.

Platform channels: как дотянуться до нативных возможностей

Когда нужна функциональность платформы — камера, биометрия, Bluetooth, push-уведомления, система оплаты — Flutter обращается к нативному коду через platform channels (MethodChannel). Это сериализованный RPC поверх бинарного протокола: Dart вызывает метод, Kotlin- или Swift-код исполняет его и возвращает результат.

Большинство распространённых интеграций уже упакованы в pub.dev-плагины: camera, local_auth, firebase_messaging, flutter_stripe и сотни других. Но «нестандартный» API платформы или проприетарный SDK без Flutter-обёртки потребует написания собственного платформенного кода — это отдельная инженерная задача, которую стоит учитывать при планировании.

Мобильные приложения: iOS и Android

Мобайл — исторически основная и наиболее зрелая цель Flutter. iOS и Android поддерживаются с первого публичного релиза 2017 года и прошли проверку тысячами продакшен-приложений: Nubank (крупнейший необанк Латинской Америки), BMW App, Google Pay и Alibaba Xianyu строятся именно на Flutter. Это не эксперимент — это устоявшаяся промышленная практика.

Для мобильного проекта Flutter даёт несколько ключевых выигрышей. Во-первых, единую кодовую базу для iOS и Android: один репозиторий, одна команда, одни спринты — без необходимости держать параллельные имплементации. Во-вторых, adaptive UI: Material-виджеты работают на обеих платформах, Cupertino-компоненты имитируют стиль iOS, а при желании можно выстроить собственный дизайн-язык, не зависящий от системного. В-третьих, полный доступ к нативным возможностям через плагины pub.dev: камера, геолокация, пуши, биометрия, App Store/Google Play Billing — всё доступно.

Цена переиспользования на мобайле — адаптация UI под Human Interface Guidelines (Apple) и Material You (Google), если важен «нативный» feel. Магазинные требования обеих платформ — App Store Review Guidelines и Google Play Policy — также требуют внимания: Flutter-приложения проходят тот же ревью, что нативные, и ряд требований (например, App Tracking Transparency на iOS 14.5+) требует специфической нативной реализации.

По нашему опыту разработки на Flutter, единая кодовая база сокращает бюджет мобильного проекта на 30–50% относительно двух параллельных нативных команд — при условии, что UI не требует глубокой платформенной кастомизации под каждую ОС.

Веб: когда Flutter Web оправдан, а когда нет

CanvasKit/WASM vs HTML-рендер, вес бандла, SEO-ограничения

Flutter Web появился в stable в мае 2021 года. У него два режима рендеринга, и выбор между ними существенно влияет на характеристики приложения:

• HTML-рендер — Flutter транслирует виджеты в HTML-элементы и CSS. Более лёгкий начальный бандл (~1,2 МБ gzip), лучше работает на слабых устройствах, поддерживает текстовую селекцию и базовую доступность. По умолчанию используется на мобильных браузерах.
• CanvasKit — Flutter рисует UI через WebAssembly и WebGL, так же как на мобайле. Пиксельное совпадение с мобильной сборкой, плавная анимация, стабильный рендеринг. Вес: CanvasKit-библиотека сама по себе добавляет 2–3 МБ, плюс Dart-код. С Flutter 3.22+ CanvasKit компилируется в WASM, что снижает размер и улучшает скорость запуска.

Главное ограничение Flutter Web для публичных сайтов — SEO. В режиме CanvasKit поисковый бот видит canvas-элемент вместо текстового контента страницы. HTML-рендер лучше, но всё равно значительно уступает обычному HTML по индексируемости. Если продукт зависит от органического трафика — Flutter Web не подходит.

Для чего подходит Flutter Web, для чего — нет

Хороший выбор:

• Внутренние dashboards, CRM, ERP, admin-панели — SEO не нужен, зато нужна единая кодовая база с мобильным приложением.
• App-like SPA: интерактивные продукты без требований к SEO — редакторы, конструкторы, сложные формы.
• PWA как дополнение к мобильному Flutter-приложению: пользователи получают схожий интерфейс в браузере.
• Корпоративные порталы с авторизацией — контент закрыт от поисковиков в любом случае.

Плохой выбор:

• Контентный сайт, лендинг, блог — SEO критичен, вес бандла тоже.
• Сайт с жёсткими требованиями к Time-to-Interactive (TTI): крупный CanvasKit-бандл создаёт проблемы на медленных соединениях.
• Продукт с требованиями к текстовой доступности (a11y): стек браузерной доступности работает хуже с CanvasKit-рендерингом.

Десктоп: Windows, macOS, Linux

Flutter Desktop вышел в stable поэтапно: Windows в марте 2022 (Flutter 2.10), macOS и Linux — в мае 2022 (Flutter 3). Это молодой target по меркам экосистемы, но уже достаточно зрелый для production-развёртывания во внутренних и утилитарных приложениях.

Для десктопа Flutter даёт тот же UI, что и на мобайле, плюс адаптации к ПК-взаимодействию: hover-состояния, нативная прокрутка, drag-and-drop, контекстные меню, нативные диалоги. Доступ к файловой системе обеспечивают пакеты file_picker и path_provider. MenuAnchor и PlatformMenuBar позволяют строить системное меню в стиле платформы.

Где потребуется нативный код на десктопе:

• Системные уведомления (особенно Windows toast notifications и macOS notification center).
• Интеграция с реестром, автозапуск при старте системы, системный трей.
• Специфика дистрибуции: подпись кода для Windows (Authenticode), нотаризация для macOS (Apple Notarization), пакетирование для Linux (AppImage, Snap, Flatpak).
• Глубокие интеграции с ОС: сканеры, принтеры, специализированное оборудование через нативные SDK.

Вывод для десктопа: Flutter — разумный выбор для внутренних корпоративных инструментов, утилит и приложений, которые уже работают на мобайле и нужны на Windows/macOS без двойной разработки. Для полнофункциональной замены «тяжёлого» профессионального desktop-приложения (видеоредактор, DAW) — подход всё ещё требует тщательной оценки.

Embedded и нестандартные среды

Flutter — это не только смартфоны и браузеры. Архитектура embedder открывает возможности для нестандартных экранов: автомобильных информационно-развлекательных систем, кассовых терминалов, киосков самообслуживания, промышленных панелей управления и IoT-устройств с дисплеем.

Принцип тот же, что описан выше: движок Flutter не знает, где он запущен. Если инженер напишет embedder под Linux-based DRM/framebuffer или встроенный дисплей с кастомным API, Flutter отрисует UI на любой поверхности. Toyota в своих автомобилях использует модифицированный Flutter-стек для инфотейнмент-систем — один из наиболее известных примеров промышленного развёртывания Flutter вне традиционных платформ.

Для киоскового и встроенного применения Flutter особенно выгоден по ряду причин. Pixel-perfect UI без зависимости от системных виджетов критически важен для кастомных тачскрин-интерфейсов, где «нативный look» платформы вообще не нужен. Единый инструментарий с мобильным продуктом компании снижает когнитивную нагрузку на команду. Hot reload во время разработки удобен при работе с физическими стендами.

Оговорки: эта область требует серьёзной инженерной работы. Стандартного пути «flutter build linux» для произвольного embedded-устройства нет — нужен кастомный embedder, адаптация под конкретный дисплей и операционную систему, тестирование на железе. Это ниша для команд с глубокой системной экспертизой, а не точка старта для среднего проекта.

Что реально переиспользуется, а что пишут под платформу

Честный ответ на вопрос «насколько реален лозунг "один код везде"»: переиспользование высокое, но не абсолютное. Вот практическая разбивка.

Переиспользуется (практически одинаково на всех платформах):

• Бизнес-логика: расчёты, алгоритмы, правила валидации, сценарии использования.
• Модели данных и state management (BLoC, Riverpod, Provider, MobX).
• Сетевой слой: HTTP-клиент, парсинг JSON/XML, кэширование, работа с WebSocket.
• Большая часть UI: экраны, виджеты, навигация (Go Router, Navigator 2.0), анимации.
• Тесты: unit-тесты и большинство widget-тестов не зависят от платформы.
• Конфигурация и локализация: l10n, тема, константы.

Требует платформенного кода:

• UI-адаптация под гайдлайны: Material You для Android, Human Interface Guidelines для iOS, responsive layout для десктопа.
• Нативные интеграции с ОС: платёжные системы (StoreKit для iOS, Google Play Billing для Android), push-уведомления (APNs vs FCM), биометрия (Face ID vs Fingerprint).
• Нативные разрешения: flow запроса разрешений на iOS и Android работает по-разному, особенно в iOS 17+ с расширенным privacy API.
• Магазинные требования: метаданные, иконки, скриншоты, дескрипторы — всё отдельно для App Store и Google Play.
• Глубокие нативные интеграции: проприетарные SDK без Flutter-обёртки требуют написания platform channel на Kotlin/Swift.

На практике переиспользование кода обычно составляет 70–90% в зависимости от сложности нативных интеграций. Для B2B-приложения с CRUD-функциональностью и базовой нотификацией может достигать 95%. Для fintech-продукта с биометрией, платёжным SDK, кастомной клавиатурой и строгими требованиями к платформе — ближе к 70%.

Платформа	Статус	Когда брать	Оговорки
Android / iOS	Production, основная цель	Почти любое клиентское приложение	UI-адаптация под гайдлайны, магазинные правила
Веб	Стабилен, с оговорками	App-like SPA, внутренние панели и dashboard	SEO/индексация ограничены, вес бандла
Windows / macOS / Linux	Production	Утилиты, внутренние desktop-инструменты	Подпись/дистрибуция, часть нативных фич — свой код
Embedded (авто / киоски / IoT)	Нишево, зрело в кейсах	Кастомные экраны и панели управления	Требует кастомного embedder и инженерной поддержки

Когда выбирать Flutter для мультиплатформы, а когда нет

Flutter — мощный инструмент, но не серебряная пуля. Разберём сценарии, где он выигрывает, и где лучше выбрать альтернативу.

Выбирайте Flutter, если:

• Нужен MVP одновременно на iOS и Android — это исторически самый сильный use case для кроссплатформенной разработки на Flutter.
• Нужен внутренний инструмент на мобайле и десктопе с единой командой и кодовой базой: бизнес-логика, дизайн-система и тесты пишутся один раз.
• Продукт строится на собственной дизайн-системе — не под нативный look, а под бренд: Flutter рендерит её идентично на всех платформах без дополнительной работы.
• Хотите web-версию продукта как SPA, admin-панель или dashboard без требований к SEO.
• Команда уже владеет Flutter/Dart, или задача позволяет нанять Flutter-специалистов.

Flutter — не лучший выбор, если:

• Контентный сайт, лендинг, блог: нужна SEO-индексация и быстрая загрузка — здесь выигрывают SSR-фреймворки (Next.js, Nuxt, SvelteKit).
• Нужна глубокая платформенная интеграция: сложный AR/VR, работа с 3D-игровым движком, тяжёлый CoreML/ML Kit — нативная разработка даёт больше возможностей и производительности на уровне системных API.
• Команда сильна только в нативной iOS или Android разработке, а дедлайн жёсткий: переучивание на Dart и экосистему Flutter может съесть весь выигрыш от единой кодовой базы.
• Нужен «по-настоящему нативный» feel на каждой ОС с точностью до системных шрифтов, анимаций переходов и поведения компонентов — здесь ReactNative (использующий нативные компоненты) или чистый нативный путь ближе к цели.

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

Часто задаваемые вопросы

На каких платформах работает Flutter?

Flutter работает на iOS, Android, веб (Chrome, Safari, Firefox), Windows, macOS, Linux и embedded-устройствах (автомобильные панели, киоски, IoT) — всё из одной кодовой базы на Dart. Flutter 3, вышедший в мае 2022 года, стабилизировал все шесть основных платформ одновременно.

Правда ли, что Flutter — это «один код на всё»?

Бизнес-логика, сетевой слой, state management и большая часть UI переиспользуются на всех платформах. Но UI-адаптация под гайдлайны iOS и Android, нативные интеграции (платёжки, биометрия, push-уведомления) и магазинные требования требуют платформенного кода. На практике переиспользование составляет 70–90% в зависимости от сложности интеграций.

Стоит ли делать сайт на Flutter Web?

Для app-like интерфейсов, внутренних панелей и dashboard — да: Flutter Web даёт единый технологический стек с мобильным приложением. Для контентного сайта, лендинга или блога с SEO-целями — обычно нет: индексация через CanvasKit ограничена, а вес бандла высок для первой загрузки на медленных соединениях.

Можно ли одним приложением на Flutter закрыть и мобайл, и десктоп?

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

Даёт ли Flutter нативную производительность?

За счёт AOT-компиляции Dart и собственного движка рендеринга Impeller производительность Flutter близка к нативной для подавляющего большинства бизнес-приложений. Для тяжёлой 3D-графики, работы с AR/VR-движками или специфических системных вычислений нативная разработка всё ещё открывает больше возможностей.

Когда Flutter — НЕ лучший выбор?

Flutter менее эффективен для: SEO-контентного веба (лендинги, блоги, сайты с органическим трафиком), тяжёлого платформо-специфичного функционала (3D-игры, AR/VR), и ситуаций, когда у команды нет опыта во Flutter/Dart, а дедлайн не позволяет переучиться с нативной разработки.