Flutter или нативная разработка под Android: что выбрать?
Практическое сравнение Flutter и нативной разработки: как устроен каждый подход, где выигрывает, во что обходится и что спросить у подрядчика.
«Использовать Flutter или разрабатывать нативно?» — этот вопрос обычно задают слишком рано. Фреймворк — следствие других решений: сколько платформ вы поддерживаете, к чему приложение должно обращаться на устройстве, какие SDK обойти не получится и кто будет сопровождать всё это через три года. Ответьте на них — и фреймворк выберется почти сам. Дальше — чем два подхода отличаются, где каждый выигрывает, во что каждый обходится после запуска и что спросить у подрядчика.
Настоящий вопрос — одна кодовая база или две
Flutter конкурирует не с Kotlin. Он конкурирует с решением вести два отдельных мобильных продукта: два языка, два набора инструментов, два набора тестов, два релизных цикла и на практике двух инженеров, каждый из которых знает только свою половину.
Дополнительная цена — не удвоенный объём кода, а координация. Ошибку исправили на Android, а на iOS она осталась; экран переделали на одной платформе, и он тихо разъехался с другой. Команды, которые действительно держат два нативных приложения в одном темпе, делают это осознанно: с общим техническим заданием, общим контрактом API и тестированием, которое проверяет обе платформы по одним и тем же критериям.
Важно и обратное следствие. Если вы выпускаете только Android и действительно никогда не добавите iOS, самый сильный аргумент в пользу Flutter исчезает, а выбор сводится к инструментам и навыкам команды. Если iOS появится в ближайший год-два, решайте сейчас: перевести готовое нативное приложение на кроссплатформенный подход — это переписывание, а не миграция.
Как каждый подход устроен и почему это важно
Flutter рисует интерфейс сам
Flutter встраивает в приложение собственный движок отрисовки и сам рисует каждый пиксель, вместо того чтобы оборачивать штатные элементы управления платформы. Dart для релизных сборок компилируется заранее в машинный код, поэтому производительность — это не вопрос интерпретатора, а вопрос того, сколько вы заставляете приложение рисовать.
Плюс: интерфейс одинаков на обеих платформах, а сильно кастомный интерфейс обходится дешевле, потому что вы его всё равно рисуете — один раз. Цена: приложение не наследует новое системное поведение автоматически — когда платформа меняет работу пикеров, шторок «Поделиться» или выделения текста, вы получаете это тогда, когда виджеты фреймворка догонят, а не в день выхода ОС. И всё, чем владеет ОС, — пуши, разрешения, биометрия, фоновое выполнение, внутренние покупки, диплинки, доступ к железу — доходит до Dart через платформенный канал, по обе стороны которого нативный код. Проект на Flutter никогда не бывает полностью свободен от Kotlin и Swift.
Натив использует родной инструментарий платформы
Kotlin с Jetpack Compose и Swift с SwiftUI или UIKit дают вам каждый API в момент его выхода, профилирование от самой платформы без прослойки фреймворка, а также доступность, ввод текста и системные жесты прямо из ОС, а не из их повторной реализации. Плата за это — всё строится дважды, включая то, что к платформе не имеет отношения: модели данных, валидация, клиенты API, форматирование, офлайн-кеширование, события аналитики.
Критерии, которые решают большинство случаев
| Если это про вас | Склоняйтесь к | Почему |
|---|---|---|
| iOS и Android к запуску, один бюджет | Flutter | Паритет функций получается бесплатно, а не выторговывается |
| Ключевая функция — это возможность устройства | Нативу | Конвейеры камеры, звук с низкой задержкой, BLE-периферия и датчики находятся ближе всего к железу |
| Только Android, навсегда, с командой на Kotlin | Нативу | Нечего переиспользовать, а инструменты остаются родными для платформы |
| Нужные SDK поставляются только как нативные библиотеки | Нативу или закладывайте обёртки | Каждая обёртка — ваш код, который надо перепроверять при каждом обновлении SDK |
| Холодный старт и размер установки — преимущество продукта | Нативу | Встроенный движок задаёт нижнюю планку размера и времени запуска |
Взвешивайте эти критерии, а не считайте по очкам. Одно жёсткое требование — эксклюзивный нативный SDK, звуковой движок, носимое устройство в центре продукта — перевешивает пять мягких предпочтений.
Где Flutter — правильный выбор
Большинство бизнес-приложений — это списки, формы, экраны с деталями, карты, поиск и push-уведомления: каталоги, бронирование, доставка, программы лояльности, приложения для выездных сотрудников и спутники CRM, внутренние операционные инструменты. Flutter уверенно справляется с этим классом задач, а общая кодовая база даёт отдачу на каждой функции после первой.
Это также прагматичный ответ, когда продукт ещё не проверен — вы хотите понять, будут ли им пользоваться, прежде чем дважды доводить его до совершенства, — и когда команда небольшая: один конвейер CI, одна интеграция с системой отчётов о сбоях, одно место, куда попадает исправление. Наш кейс EatWise именно такой формы: кроссплатформенное приложение о питании на Flutter с приложением-спутником для Wear OS — потому что продукту нужны были одинаковые функции на обеих платформах без двух дорожных карт. Как мы выстраиваем такую работу, смотрите в услуге разработки мобильных приложений.
Где правильный выбор — натив
Натив оправдывает свою дополнительную стоимость, когда основная ценность приложения — это возможность платформы, а не экран: покадровая обработка изображения с камеры, машинное обучение на устройстве с использованием платформенных ускорителей, звук с низкой задержкой, видео в реальном времени, требовательная 3D-графика, нестандартная периферия Bluetooth LE, NFC, Android Auto или CarPlay и сложное фоновое выполнение. То же касается любого продукта, где системные виджеты, приложения для часов или расширения ОС играют первую роль, — их пишут нативно даже внутри проекта на Flutter. Другой случай — SDK поставщика, который существует только в виде нативных библиотек и часто меняется: тогда каждый его релиз превращается в обёртку, которую надо перепроверять с обеих сторон.
Затраты, которые проявляются только после запуска
Часть сопровождения неизбежна в любом случае. Google Play требует, чтобы приложения ориентировались на достаточно свежий уровень API, поэтому мобильное приложение не бывает законченным; каждый релиз ОС меняет разрешения, ограничения фоновой работы или поведение уведомлений; а для сборок под iOS нужен Mac для компиляции и подписи, какой бы фреймворк вы ни выбрали.
Flutter добавляет обновления фреймворка и плагинов. Смена мажорной версии каскадом расходится по зависимостям, а заброшенный плагин на критическом пути — реальный риск: посчитайте нужные плагины до старта, проверьте по каждому активность сопровождения, предпочитайте официальные пакеты и примите, что один из них, возможно, придётся форкнуть. Заложите в бюджет инженера, который читает Kotlin и Swift, — самые сложные ошибки живут на границе между Dart и нативным кодом.
Натив добавляет координацию, которая оплачивается мелкими долями до того момента, когда клиент спросит, почему в приложении для iOS нет фильтра, который на Android есть уже несколько месяцев.
Что меняется, когда ваши пользователи в Узбекистане
Устройства, сети и работа офлайн
Рассчитывайте на широкий парк устройств, а не на нынешние флагманы, и на связь, которая пропадает. Измеряйте холодный старт и размер установки на самом дешёвом телефоне, который найдёте, и сделайте это условием выпуска. Для приложений водителей, доставки и выездных продаж проектируйте офлайн в первую очередь: локальное хранилище, очередь отложенных действий и явные правила разрешения конфликтов. Оба подхода это поддерживают — разница в том, что слой синхронизации во Flutter вы строите один раз, а нативно — дважды.
Локальные интеграции
Платёжные, банковские и идентификационные провайдеры, а также сервисы электронной подписи в регионе часто распространяют нативные SDK для Android и iOS, а не кроссплатформенные пакеты. Прежде чем выбирать, перечислите все сторонние SDK, которые приложению придётся использовать, и проверьте по каждому наличие поддерживаемого пакета для Flutter. Там, где его нет, работа сводится к обёртке через платформенный канал на каждой платформе — это известная и поддающаяся оценке стоимость, но только если вы узнали о ней до оценки. Если приложение к тому же общается с бухгалтерией, складом или диспетчерскими системами, более сложная инженерная задача — это системная интеграция за ним.
Три языка и кадры на четвёртый год
Узбекский, русский и английский в одном продукте меняют работу с вёрсткой: русские подписи длиннее английских эквивалентов, поэтому проверяйте каждый экран на самом длинном языке и проверяйте покрытие латиницы и кириллицы в выбранной гарнитуре. Flutter отрисовывает текст собственным движком, поэтому пользователи видят именно тот шрифт, который вы вложили в приложение; натив наследует системный шрифт, а он различается между сборками Android у разных производителей. Это работа UI/UX-дизайна, которая до разработки стоит намного дешевле, чем после. С кадрами логика та же: двум нативным кодовым базам нужен постоянный специалист с каждой стороны, а продукту на Flutter — одна команда плюс инженер, которому комфортно в нативном коде. Спрашивайте подрядчика, как он укомплектует проект на четвёртый год, а не в первый месяц.
Вопросы, которые стоит задать до подписания
- Какие части этого приложения нельзя написать на Dart и как вы будете их писать?
- Из всех нужных нам сторонних SDK — у каких есть поддерживаемые кроссплатформенные пакеты, а каким нужна нативная обёртка?
- Что произойдёт, если плагин на критическом пути забросят в середине проекта?
- Проведите нас по процессу релиза: подпись, CI, поэтапная раскатка, отчёты о сбоях, откат.
- Если сейчас мы сделаем только Android, а iOS добавим через год, что реально будет переиспользовано?
- Кому принадлежит исходный код и оформлены ли аккаунты App Store и Google Play на нас?
- Что входит в сопровождение при выходе новых версий ОС и повышении целевого уровня API и кто его инициирует?
- Какое минимальное устройство вы поддерживаете и можете ли показать приложение работающим на нём?
Конкретные ответы на эти вопросы скажут о результате больше, чем любое сравнение фреймворков.
Ошибки, которые мы видим чаще всего
- Выбор по предпочтениям разработчиков, названный архитектурой. Предпочтение — законный аргумент: команда работает быстрее в знакомом стеке. Но его стоит проговаривать, а не маскировать под техническое требование.
- Уверенность, что Flutter означает отсутствие нативной работы. Пуши, разрешения, платежи и фоновые задачи — всё это затрагивает платформенный код.
- Проектирование под одну платформу с последующим переносом. Навигация назад, жесты и расположение вкладок различаются; даже попиксельно точный перенос на второй платформе ощущается неправильным.
- Отношение к бэкенду как к второстепенному. Большинство жалоб на медленное приложение упирается в задержку API и размер ответов, а это работа разработки ПО, а не работа с фреймворком.
- Расчёт стоимости только разработки. Два года сопровождения нередко превышают первый релиз — и это та часть, которую большинство предложений опускает.
Итог
Для большинства бизнес-приложений, которым нужны iOS и Android, Flutter — правильный выбор по умолчанию: он снимает целый класс затрат на координацию и позволяет небольшой команде держать обе платформы в одном темпе. Выбирайте натив, когда в центре продукта стоит возможность устройства, эксклюзивный SDK или жёсткое ограничение по времени запуска и размеру, — либо когда вы действительно работаете на одной платформе и у вас есть под это команда.
А дальше перестаньте оптимизировать фреймворк и займитесь тем, что решает судьбу приложения: понятный ключевой сценарий, быстрый и надёжный API, тестирование на реальных устройствах и честная аналитика. Опишите, что должно делать ваше приложение, и свяжитесь с нами — мы скажем, как построили бы его мы и почему.
