Frankenstein's Monster: How we migrated two native apps into a single Flutter app
summary
Migrated two messy native apps into one working Flutter app by incrementally embedding Flutter with add-to-app, keeping a single long‑lived Flutter engine to avoid memory leaks and using method channels for bidirectional calls. Web UIs moved into a unified WebView, C Bluetooth stacks accessed via Dart FFI and FFI‑gen, and flutter_reactive_ble handled BLE with platform workarounds for MTU and scan rate limits. Built prototype modules, added CI/CD to legacy apps, and completed a full migration that runs in production.
AI-written summary · about
chapters (14)
- 0:00Introduction to project
- 3:39Migration challenges overview
- 7:31Add-to-app approach explained
- 11:46User-facing migration plan
- 13:52Android integration details
- 14:34iOS integration details
- 17:00Avoiding memory leaks
- 19:28Method channels communication
- 23:43Web view migration tips
- 27:01Debugging cross-platform
- 27:43Working with C libraries
- 31:00Bluetooth implementation
- 32:48Final migration to Flutter
- 34:11Q&A and closing
related talks
30mAdding Flutter to your app - what are they not telling you?
58mBuilding cross-platform mobile apps with Flutter.io
46mAdopting Flutter at Scale
28mHow a Nearly-Naive Flutter Team Replaced a Native App with Flutter in Six Months
01h 13mFlutter and a Million Lines of Native Code
30mThe Struggles of Migrating to Flutter and What We Gained
44mMultimodule Flutter App
37mLessons learned from crafting an in-house framework