Что такое миграция на Flutter на самом деле
Если вы всё ещё выбираете между Flutter и React Native, сначала прочитайте Flutter vs React Native в 2026 году — эта страница исходит из того, что выбор уже сделан, и отвечает на вопросы реализации: как, сколько времени, сколько стоит и насколько рискованно.
Миграция с React Native на Flutter — это переписывание, а не портирование. У Flutter и React Native нет общих артефактов сборки, общей библиотеки компонентов и общего слоя состояния — каждый экран, навигация и нативная интеграция создаются заново на Dart. Что действительно переживает переход — всё, что не является кодом: ваши бизнес-правила, контракты API, модели данных и дизайн-решения, которые уже приняла ваша команда. Всё это становится спецификацией, по которой строится новое приложение, — поэтому миграция быстрее и менее рискованна, чем разработка с чистого листа, но это, честно говоря, всё равно полная пересборка клиента.
Кому стоит мигрировать — а кому нет
Flutter обычно оправдан для команды, уже работающей на React Native или нативе в продакшене, — но не всегда, и мы лучше скажем это прямо, чем продадим переписывание, которое вам не нужно.
Признаки того, что пора мигрировать
- Бесконечные апгрейды React Native (New Architecture, ломающие релизы, разъезжающиеся зависимости) отнимают реальное инженерное время каждый цикл
- Вы упёрлись в потолок производительности — подтормаживания на сложных экранах, медленные списки, рывки анимаций, — который архитектура моста не может исправить
- Нативные модули превратились в обузу: форкнутые пакеты, зависимости, зафиксированные на версии, код, оставленный прежним автором
- Нанимать тяжело, и результат получается неровным, а вам нужна одна команда на одной кодовой базе вместо отдельных специалистов по RN и нативу
- Вы уже пишете новые фичи на Flutter и хотите перевести на него остальное приложение
Когда мигрировать не стоит
- Ваше приложение стабильно, хорошо работает и не тормозит роадмап
- Ваша команда довольна и продуктивна, и у неё нет желания браться за многомесячную пересборку
- Вы много вложили в кастомные нативные модули: они нормально работают, а достойного аналога на Flutter для них нет
- Причина мигрировать — «Flutter выглядит красиво», а не реальная проблема со стоимостью, производительностью или поддержкой
Честный вывод: если ни один из «признаков» выше не описывает ваше приложение — не мигрируйте. Стабильное приложение с довольной командой лучше не трогать. Расскажите, где у вас реально болит, и мы прямо скажем, стоит ли миграция того — включая ответ «пока нет».
Поэтапный подход: add-to-app
Причина мигрировать с нами, а не заказывать переписывание с нуля, — в модели поставки, а не в выборе фреймворка. Мы встраиваем Flutter в ваше существующее приложение на React Native или нативе как модуль — интеграция add-to-app — и переносим экраны по одному через общий роутер. Для этого не нужен одномоментный переход, и приложение не уходит в офлайн ни на секунду. А если вам нужен Flutter внутри нативного приложения, которое остаётся нативным, — внедрение без полного переезда, — это отдельная услуга: смотрите интеграцию add-to-app.
Как работает add-to-app
Существующая оболочка остаётся
Текущее приложение на RN или нативе продолжает работать в продакшене без изменений как оболочка-хост
Встраивается модуль Flutter
Движок Flutter добавляется в оболочку через add-to-app и использует общую навигацию и нативные сервисы
Экраны переносятся по одному
Каждый экран выходит на Flutter за роутером, тестируется и релизится независимо
Экраны на RN выводятся из эксплуатации
Как только Flutter-экран доказал себя в продакшене, его аналог на RN удаляется, а не архивируется
Полный переход
Когда перенесены все экраны, сама оболочка-хост убирается, и приложение становится на 100% Flutter
Даром это не даётся. Всё время миграции у вас работают два тулчейна и два слоя состояния параллельно — а пока дизайн-система не перенесена полностью, ещё и два визуальных языка в разных углах одного приложения. Временно сложности становится больше, а не меньше. Мы заранее составляем карту миграции именно для того, чтобы это окно было как можно короче, но не будем делать вид, что оно исчезает само.
Что переносится, а что пересобирается
Не всё выбрасывается. Вот что реально переживает переход на Flutter, а что пересобирается с нуля.
| Слой | Переносится | Пересобирается на Flutter |
|---|---|---|
| Бизнес-логика и правила | Да | — |
| Контракты API | Да | — |
| Модели данных | Да | — |
| Дизайн-токены и брендбук | Да | — |
| Тест-кейсы (как спецификации) | Да | — |
| Экраны UI | — | Пересобирается |
| Навигация | — | Пересобирается |
| Управление состоянием | — | Пересобирается |
| Нативные интеграции | — | Пересобирается |
| CI/CD | — | Пересобирается |
Как мы проводим миграцию
1. Аудит
Мы изучаем вашу кодовую базу — экраны, навигацию, управление состоянием, нативные модули, поверхность API и покрытие тестами — и отмечаем, что перенести просто, а что будет по-настоящему сложно. Каждая мина — форкнутый нативный модуль, недокументированная машина состояний, контракт с бэкендом, который никто не записал, — находится здесь, а не через три спринта в разгар пересборки.
2. Карта миграции
Аудит превращается в поэкранный план миграции: последовательность, зависимости между экранами, какие нативные модули требуют аналогов на Flutter, и реалистичный порядок, при котором приложение остаётся готовым к релизу на каждом шаге. Именно по этому документу оценивается весь остальной проект.
3. Поэтапная поставка
Мы встраиваем Flutter в существующую оболочку и начинаем выпускать экраны в порядке приоритета — обычно начиная с чего-то низкорискового, чтобы обкатать процесс, а затем переходя к экранам, которые действительно важны. Приложение всё это время продолжает релизиться в обычном режиме; миграция идёт параллельно с обычным роадмапом, а не вместо него.
4. Переход
Когда перенесены все экраны и старый код удалён, мы убираем оболочку-хост и выпускаем сборку полностью на Flutter. С этого момента приложение поддерживается как любая другая кодовая база на Flutter — одна команда, один тулчейн.
Хотите оставить работу внутри команды? Через расширение команды наши инженеры могут влиться в вашу команду и провести миграцию под вашим управлением, а не нашим.
Снизить риск до принятия решения
Не обязательно сразу соглашаться на полную миграцию, чтобы понять, что она собой представляет. Наша услуга аудита AI-кода проводит описанный выше этап аудита как отдельную работу с фиксированным объёмом: полный разбор текущей кодовой базы и письменный отчёт, который становится картой миграции — мины, риски нативных модулей и реалистичная последовательность, — независимо от того, продолжите вы работать с нами после этого или нет.
Начните отсюда, если не уверены
Аудит — самый необязывающий способ узнать, имеет ли смысл миграция для вашего приложения, сколько она реально будет стоить и где настоящий риск, — прежде чем кто-либо напишет хоть строчку на Dart.
Сроки и стоимость
Миграция на Flutter масштабируется как пересборка, потому что это она и есть: кодовая база, которую вы получаете, — полноценное приложение на Flutter, построенное в том же объёме, что и при разработке с нуля. Что меняет поэтапный подход — это риск, а не объём: поставка по экранам растягивает календарь по сравнению с одномоментным переписыванием, но приложение при этом ни разу не уходит в офлайн, и вы можете остановиться, поставить на паузу или пересмотреть приоритеты на границе любого экрана.
Мы не называем сроки и стоимость миграции без изучения приложения — диапазон слишком широк, чтобы быть полезным. Но поскольку миграция оценивается как пересборка, честным ориентиром служат опубликованные тарифы на странице разработки на Flutter: приложение в объёме уровня Business — 2,7–5,4 млн ₽ при разработке с нуля — это то, к чему тяготеет миграция сопоставимого приложения, плюс этап аудита и карты миграции в начале. Как мы оцениваем саму лежащую в основе разработку — в статьях сколько времени занимает разработка Flutter-приложения и что реально влияет на стоимость разработки на Flutter.
Часто задаваемые вопросы
Всё, что нужно знать о миграции с React Native или натива на Flutter