What is Flutter add-to-app?
How embedding Flutter in a native app lets you adopt Flutter gradually, without a full rewrite.
Add-to-app is a way to add Flutter to existing native iOS and Android apps. Instead of starting over, you integrate Flutter into the existing app as a module: selected screens or flows render in Flutter, while the rest of the app stays native.
Teams use it to move an app to Flutter gradually, to prove that Flutter works inside their product, or to build a new feature once for both platforms - all without stopping the native app from shipping.
How adding Flutter to an existing app works
For your users, nothing changes. They keep the same app from the same store listing, and a Flutter screen looks and behaves like any other screen in it. Nobody has to install anything new or move their account.
For your team, Flutter becomes one more part of the regular release. Native and Flutter developers work on the same product at the same time, and a single release can ship both kinds of screens. That's what lets you start with one screen or one new feature and grow from there.
The part worth planning for is where the two worlds meet. Building the Flutter screens themselves is the predictable work. Most of the effort goes into making the native and Flutter parts act as one product: moving between screens, sharing data such as the logged-in user, and keeping the integrations the app already relies on, like payments or analytics, working on both sides.
Why not just rewrite the app?
Full rewrites of large enterprise applications carry a lot of risk and take a lot of time. Porting the UI is only part of the job - you also have to re-implement years of edge cases, business logic, platform-specific integrations, and institutional knowledge that lives in the codebase but not in anyone's head. In our experience, that knowledge has to be recovered whichever path you take, but a rewrite forces you to recover all of it before anything ships, and the launch is all-or-nothing. Meanwhile the native app still needs to be maintained and improved - the business can't pause shipping features while the rewrite is going on.
Add-to-app lets you embed Flutter screens directly inside your existing native applications. You can migrate the app gradually, feature by feature, and validate everything in production before moving further. It is not automatically the safer choice, though. When the native code is undocumented and nobody owns it anymore, a rewrite can turn out to be the lower-risk path - see the patterns we've seen for a case where it would have been.
Using add-to-app for a Flutter proof of concept
You can also use it to run a quick prototype - replace one or a few screens in your native app with Flutter ones and see how it holds up. Give your stakeholders two phones, one with the current native app and one with the Flutter add-to-app integration. If the screens are done in a pixel-perfect manner, they shouldn't be able to tell the difference, which usually settles the discussion for stakeholders who are unsure about Flutter.
Key add-to-app terms
Five terms come up on every add-to-app project:
- Host app - the existing native iOS or Android app that Flutter is added to. It keeps owning app startup and, at first, the main navigation.
- Flutter module - a Flutter project built to be embedded rather than run on its own. It holds your Dart code and becomes part of the host app's build.
- Flutter engine - the runtime that executes your Dart code and renders Flutter UI. An add-to-app project often runs several engines at once.
- Native container - the native component that displays Flutter: a
FlutterActivityorFlutterFragmenton Android, aFlutterViewControlleron iOS. - Native-Flutter boundary - every place where native code and Flutter meet: navigation, shared data, calls into native SDKs.