Что такое миграция на 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 — и переносим экраны по одному через общий роутер. Для этого не нужен одномоментный переход, и приложение не уходит в оффлайн ни на секунду.
Как работает 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 — одна команда, один тулчейн.
Хотите оставить работу внутри команды? Наши инженеры из Team Augmentation могут влиться в вашу команду и провести миграцию под вашим управлением, а не нашим.
Снизить риск до принятия решения
Не обязательно сразу соглашаться на полную миграцию, чтобы понять, что она из себя представляет. Наш сервис аудита AI-кода проводит этап аудита выше как отдельное мероприятие с фиксированным объёмом: полный обзор текущей кодовой базы и письменный отчёт, который становится картой миграции — мины, риски нативных модулей и реалистичная последовательность, — независимо от того, продолжите вы работать с нами после этого или нет.
Начните отсюда, если не уверены
Аудит — самый необязывающий способ узнать, имеет ли смысл миграция для вашего приложения, сколько она реально будет стоить и где настоящий риск, — прежде чем кто-либо напишет хоть строчку на Dart.
Сроки и стоимость
Миграция на Flutter масштабируется как пересборка, потому что это она и есть — кодовая база, которую вы получаете, это полноценное приложение на Flutter, построенное в том же объёме, как если бы вы начинали с нуля. Что меняет поэтапный подход — это риск, а не объём: поставка по экранам растягивает календарь по сравнению с одномоментным переписыванием, но означает, что приложение никогда не гаснет, и вы можете остановиться, поставить на паузу или пересмотреть приоритеты на границе любого экрана.
Мы не называем сроки и стоимость миграции без изучения приложения — диапазон слишком широк, чтобы быть полезным. Чтобы прикинуть масштаб, посмотрите, как мы оцениваем сколько времени занимает разработка Flutter-приложения и что реально влияет на стоимость разработки на Flutter; миграция приложения сопоставимого масштаба обычно укладывается в те же цифры плюс этап аудита и карты миграции в начале.
Часто задаваемые вопросы
Всё, что нужно знать о миграции с React Native или натива на Flutter