Why are we building a framework for Flutter add-to-app?
The recurring add-to-app problems that pushed us to build Inlay.
Add-to-app is an officially supported way to work with Flutter, but we kept finding that the official docs, the tooling, and the community knowledge online don't go far enough for adding Flutter to existing, large-scale enterprise apps.
How do you manage navigation routes across the native-Flutter boundary, or share data between the two sides? And once you're past the first screen: how do you use native assets from Flutter, or structure the project so it scales beyond a proof of concept? We built our framework because we hit every one of these questions on real projects.
The framework provides:
- An opinionated, type-safe approach to cross-platform navigation, so that opening Flutter screens from native - and the reverse - is straightforward.
- Cross-platform reactive state management for sharing the same data between native platforms and one or more Flutter instances.
- Automatic engine lifecycle management, so you never have to deal with low-level Flutter engines yourself.
This guide documents both the framework and the broader patterns. Even if you don't use our framework, the architectural decisions and implementation strategies described here apply to any add-to-app project.