Differentiator
Flutter Add-to-App Architecture
Add Flutter features to a native app without a rewrite.
How it works
A left-to-right map of the work. Ports stay on fixed sides so the edges do not cross more than they have to. Pan or pinch if you want a closer look.
- Kotlin host
- Swift host
- Session + theme
- Flutter module
The usual problem
- A native app is too large to replace, but new features need Flutter speed.
- Session and theme live in the host, so a bolted-on Flutter screen looks like a second product.
- iOS is promised as “the same later” and then designed from scratch.
How I approach it
- A reusable Flutter module inside the native host, not a second app.
- Native code passes session tokens and theming into Flutter at runtime.
- The Android host is Kotlin. The same contract is architected for Swift iOS.
Process
01
Contract
What the host passes in: session, theme, and the screens Flutter owns.
02
Module
A reusable Flutter module, not a copy-paste of a standalone app.
03
Host
Kotlin Android integration. The same contract documented for Swift.
04
Handover
How to add another Flutter feature without touching the host’s architecture.
Stack and tools
Flutter moduleKotlin hostSwift-ready contractSession tokensRuntime theming
Proof from real work
Add-to-app module
Architecture owner
A reusable Flutter module embedded in a native Kotlin Android host, with session tokens and theming passed in at runtime. The same contract is architected for Swift iOS.
What you get
- The Flutter module
- The host contract for session and theme
- Android integration and a Swift-ready interface
How risk stays down
- The native app is not rewritten.
- Flutter screens inherit the host session and theme, so they do not look bolted on.