In Flutter's add-to-app, what is a Flutter module, and how does an existing Android or iOS app show one Flutter screen from it?

## What add-to-app is Rewriting a large native app is rarely practical. **Add-to-app** lets a team render part of an existing Android or iOS app with Flutter — for example a new loyalty-points screen inside a native airline app — while everything else stays native. On mobile, Flutter runs as **multi-engine** add-to-app: each Flutter instance is a separate Dart program in its own `FlutterEngine`. ## The Flutter side: a module A **Flutter module** is a Flutter project whose purpose is to be embedded: ```bash flutter create -t module --org com.example loyalty_module ``` - It has the usual `lib/main.dart` and `pubspec.yaml`, and can depend on plugins. - Its Android and iOS host projects live in hidden `.android/` and `.ios/` folders that the tool generates; the real host is your existing app. - You can still `flutter run` it on its own for fast iteration, and attach to it from the host with `flutter attach` for hot reload. For iOS on Flutter 3.44 and later, the docs recommend starting a first integration from a normal Flutter **application**, and integrating either kind through Swift Package Manager. ## Wiring it into the host | Step | Android | iOS | |---|---|---| | Build integration | Gradle source dependency, or an AAR from `flutter build aar` | Swift packages from `flutter build swift-package --platform ios` | | UI container | `FlutterActivity` (full screen) or `FlutterFragment` (part of a screen) | `FlutterViewController` | | Registration | Declare `io.flutter.embedding.android.FlutterActivity` in `AndroidManifest.xml` | Add the generated Swift packages to the app target | | Launch | `startActivity(FlutterActivity.createDefaultIntent(this))` | `present(FlutterViewController(project: nil, nibName: nil, bundle: nil), animated: true)` | On Android, the intent builder also sets the initial route: ```kotlin startActivity( FlutterActivity .withNewEngine() .initialRoute("/loyalty") .build(this) ) ``` (The Gradle wiring and Podfile-based integration have their own topics; the older CocoaPods and `flutter build ios-framework` integrations are legacy paths in 3.47.) ## What happens at launch 1. The container creates a **`FlutterEngine`** implicitly, because none was provided. 2. The engine finds and loads Flutter's libraries, starts the Dart VM on first use, creates an isolate and runs `main()` (or a named entrypoint). 3. The container gives the engine a rendering surface, and the first frame appears. This implicit engine is the simplest setup, but it has a **non-trivial warm-up time**, so users see a brief blank delay each time. The fix — pre-warming and caching an engine — is the next step most teams take. ## Things interviewers check - The Flutter screen keeps its **own navigation stack**; the host's back stack and Flutter's `Navigator` are separate. - Data crosses between the native app and Flutter through **platform channels** (or Pigeon), not shared memory. - Plugins work in a module, but plugins that assume a Flutter `Activity` is always present can misbehave. - On Android, the module requires an **AndroidX** host app. - Packing **multiple Flutter modules** (libraries) into one app is not supported; one module can serve many screens. ## Common misconceptions - A module is not a plugin: plugins add native code to Flutter apps, a module adds Flutter to a native app. - Add-to-app does not require converting the host's navigation or build system wholesale. - Showing Flutter does not need a pre-warmed engine; pre-warming is an optimisation, not a requirement.