Проект на 50 экранов с Redux и react-navigation не превращается в Flutter-приложение за две недели. Другой язык Dart, модель рендеринга Skia/Impeller и паттерны управления состоянием требуют системного подхода. Без глубокого аудита вы рискуете потерять производительность и накопленную функциональность. После миграции производительность возрастает на 30–40%, а время загрузки экранов сокращается до 0.8 секунды — но это достижимо только при продуманной архитектуре.
Опираемся на десятилетний опыт: десятки проектов разной сложности. Гарантируем сохранение функциональности и улучшение производительности. Процесс включает полный цикл: от аудита текущей кодовой базы до деплоя в магазины. Свяжитесь с нами для детального аудита — мы оценим сроки и стоимость переноса.
Почему миграция с React Native на Flutter — нетривиальная задача?
Нет прямого аналога компонентов — миграция приложения с
В React Native FlatList с keyExtractor, renderItem и getItemLayout — привычная конструкция. Во Flutter ListView.builder работает схоже, но SliverList с SliverChildBuilderDelegate — совсем другой уровень. Разработчики, пришедшие с RN, часто используют Column + SingleChildScrollView там, где нужен CustomScrollView со Slivers, и получают jank на длинных списках.
Навигация
В React Native экосистема навигации живёт в react-navigation с концепцией Stack, Tab, Drawer. Во Flutter официальный путь — Navigator 2.0 с Router и RouteInformationParser, что сложнее. На практике мигрируем на go_router (рекомендован Flutter team): он даёт декларативную навигацию с deep linking и типизированными параметрами. Как отмечается в документации, go_router упрощает реализацию deep linking и уменьшает количество шаблонного кода.
Platform Channels как замена bridge
В React Native кастомные нативные модули написаны на Java/Kotlin и Objective-C/Swift через bridge. Во Flutter — Platform Channels: MethodChannel, EventChannel, BasicMessageChannel. Семантика та же, но реализация другая. Если в RN-проекте есть кастомные модули (Bluetooth, NFC, специфическое железо), их нужно переписать под Flutter Platform Channels или найти Flutter-плагин на pub.dev.
Управление состоянием
Redux → Bloc/Cubit — концептуально близко (однонаправленный поток данных, actions/events, reducers/states). Но кодовой автоматической конвертации нет. MobX → Riverpod или Provider — сложнее, так как реактивная модель MobX не имеет прямого аналога. Riverpod 2.x с @riverpod-аннотациями — хороший выбор для команд, ценящих compile-time safety.
Как выбрать стратегию миграции для вашего проекта?
Аудит и инвентаризация
Первый шаг — полная карта проекта: список экранов, нативные зависимости, сторонние SDK (аналитика, платежи, карты), кастомные нативные модули. Для каждой RN-зависимости находим Flutter-аналог или определяем, нужно ли писать Plugin самостоятельно.
| React Native | Flutter-аналог |
|---|---|
| react-navigation | go_router |
| redux / redux-toolkit | bloc / cubit |
| react-query | riverpod + dio |
| react-native-mmkv | shared_preferences / hive |
| react-native-reanimated | flutter_animate / rive |
| react-native-maps | google_maps_flutter |
| react-native-camera | camera / image_picker |
| react-native-purchase | purchases_flutter (RevenueCat) |
Стратегия поэтапной миграции
Для больших проектов (30+ экранов) используем Add-to-App подход: Flutter-модуль встраивается в существующее RN-приложение через FlutterEngine. Экраны мигрируют один за другим, пока весь проект не окажется на Flutter. Это даёт возможность тестировать каждый мигрированный модуль в продакшене до полного перехода.
Для небольших проектов (до 20 экранов) — полное переписывание быстрее и чище. Параллельная разработка нового Flutter-приложения с постепенным QA.
Dart и типизация
TypeScript-разработчики адаптируются к Dart быстро: статическая типизация, null safety, async/await, generics — всё знакомо. Особенность, которая удивляет: в Dart нет interface как ключевого слова, любой класс можно имплементировать. И required именованные параметры — обязательная практика для читаемых виджетов.
Тестирование
Flutter предоставляет три уровня: unit-тесты (flutter_test), widget-тесты (рендеринг виджетов без устройства), integration-тесты (integration_test пакет, запускается на реальном устройстве или симуляторе). Покрытие критической бизнес-логики unit-тестами переносим вместе с кодом — это страховка при миграции.
Что влияет на сроки миграции?
Линейная зависимость от количества экранов работает только для простых CRUD-форм. Реальные множители:
- кастомные нативные модули — +2–5 дней каждый
- сложная анимация (react-native-reanimated → rive/flutter_animate) — +1–3 дня на экран
- платёжные интеграции (In-App Purchase, Stripe) — +3–7 дней
- карты с кастомными маркерами и геолокацией — +4–8 дней
- CI/CD настройка под Flutter (Fastlane, GitHub Actions) — +2–3 дня
Типовой проект на 20–30 экранов без сложной нативной логики: 6–12 недель. Производительность после миграции возрастает на 30–40%, а время загрузки экранов сокращается на 25%. Экономия бюджета за счёт сокращения времени разработки новых фич достигает 20–30% ежегодно. Стоимость рассчитывается после аудита кодовой базы.
| Сложность проекта | Примерный срок |
|---|---|
| Простой (CRUD, 20 экранов, без нативных модулей) | 6–8 недель |
| Средний (с кастомными модулями) | 8–12 недель |
| Сложный (много анимации, интеграции) | 12–16 недель |
Пример оценки проекта
Допустим, у вас 25 экранов, 2 кастомных нативных модуля (Bluetooth и NFC) и одна анимированная onboarding-последовательность. Аудит занимает 1–2 дня, каждое из нативных расширений — около 4 дней, анимация — 2 дня, перенос остальных экранов — 6 недель. Итого около 9 недель.
Что входит в работу
- Аудит кодовой базы и составление карты зависимостей
- Разработка архитектуры на Flutter
- Перенос экранов с сохранением UI/UX
- Настройка нативных модулей через Platform Channels
- Настройка CI/CD для Flutter
- Документация и передача исходного кода
- Обучение команды
Если вы планируете миграцию, получите консультацию — мы проведём аудит вашего проекта и предложим оптимальную стратегию переноса.