Перенесення застосунку на Flutter: ціна і ризик
Павло Рубановський
August 28, 2026 · 8 хв читання
Питання не в тому, чи Flutter хороший
У вас уже є застосунок. Цікаве питання не в тому, який фреймворк кращий абстрактно, а в тому, скільки коштує переїзд, що ви зберігаєте і чи той біль, який ви маєте, взагалі лікується міграцією.
Частина — ні. Саме цю частину пропускають більшість статей про міграцію.
Три форми, яких може набути міграція
Екран за екраном (add-to-app). Flutter працює всередині наявного застосунку як модуль. Ви переносите один флоу за раз, релізите безперервно, старий код продовжує працювати. Найповільніше за сумарними зусиллями, найменш ризиковано, і єдиний варіант, якщо не можна зупинити роботу над функціями на квартал. Ціна — жити з двома тулчейнами, двома збірками й мостом між ними всю дорогу.
Тільки нові поверхні. Наявні екрани лишаються нативними назавжди, усе нове — на Flutter. Розумно, коли легасі стабільне, а дорожня карта переважно про додавання. Це навіть не міграція — це рішення перестати нарощувати стару кодову базу.
Повне переписування. Найшвидше до чистого результату і найризикованіше, бо список для паритету функцій завжди довший, ніж памʼять про нього. Виправдано, коли застосунок невеликий або коли він і так уже настільки старий, що переписування станеться в будь-якому разі.
Для всього, що має реальне користування, ми б за замовчуванням обрали перший варіант, а третій — лише коли поточна база справді під списання.
Що переїжджає, а що ні
| Переноситься | Треба переписувати |
|---|---|
| Бекенд, API, база даних | Кожен екран і флоу навігації |
| Дизайни й дизайн-система | Код platform channel для нативних SDK |
| Лістинги в сторах, відгуки, позиції | Усе, що спирається на RN-бібліотеку без аналога у Flutter |
| Історія та події аналітики | Віджети, розширення екрана блокування, застосунки для годинника |
| Ключі підпису й акаунти в сторах | Глибокі інтеграції: конвеєр камери, фонове аудіо, кастомний Bluetooth |
Права колонка — це те, де ламаються оцінки. Екрани — передбачувана робота. Нативний SDK без Flutter-пакета, або обгорнутий плагіном, який ніхто не оновлював два роки, — саме там міграція знаходить свій справжній термін.
Аудит, що перелічує кожну сторонню залежність і її стан у Flutter, — це перший результат, ще до того, як хтось назве цифру.
Коли мігрувати варто
- Дві кодові бази розійшлись. На iOS є функції, яких немає на Android, виправлення робляться двічі, платформи щокварталу віддаляються. Це найсильніша причина, і вона накопичується.
- Немає кого найняти. Тримати дві нативні команди на один продукт дорого і крихко. Одна Flutter-команда покриває обидві платформи.
- Темп релізів обмежений дубльованою роботою. Якщо кожна функція робиться двічі, ви платите податок, який спільна кодова база скасовує.
Коли не варто
- «Застосунок гальмує». Спершу профілюйте. Фризи зазвичай у шарі даних, обробці зображень або списку, що перебудовується щокадру — нічого з цього зміна фреймворку не лікує. Ви відтворите ті самі помилки іншою мовою.
- Одна платформа важлива, друга майже ні. Якщо 95% доходу з iOS, кросплатформність дає мало і забирає нативну ергономіку.
- Застосунок сильно спирається на можливості платформи. Глибокий доступ до заліза, складна фонова робота чи великий нативний SDK означають, що більшість коду однаково лишиться нативною, і ви отримаєте міст замість спрощення.
З чого почали б ми
Не з переписування. З аудиту: інвентар залежностей із їхніми відповідниками у Flutter, карта того, які екрани дешеві, а які несучі, і один показовий флоу, переписаний на Flutter і запущений усередині наявного застосунку.
Оце останнє і є справжньою оцінкою. Усе до нього — арифметика на припущеннях.