Two native apps. One Flutter codebase. No freeze.
We move your app to Flutter one flow at a time, inside the app your customers already use, while your roadmap keeps shipping. Your customers shouldn’t notice, until the features start arriving faster.
A 30-minute conversation with someone who’s shipped this before.
Migration stories
In their words
-
“Working with VGV gave us the added confidence we needed to evaluate Flutter, figure out that we love it, and commit to migrating our entire app.”
VP Architecture, Betterment Sam Moore -
“Sometimes to go faster, you have to start by going slower.”
VP of Engineering, Keller Williams Chris Synan -
“Everyone wants to go to the party, but nobody wants to stay and clean up.”
VP Architecture, Betterment, on why the old native code has to go Sam Moore
We moved live apps without their customers noticing.
- 0 downtime while two revenue-critical apps became one codebase, with full feature parity Scooter’s Coffee
- 775K+ accounts on one codebase, after an add-to-app pilot on a single flow Betterment
- 2x revenue year over year, after six native apps became one V1 Sports
- 3.5M+ installs, on Flutter since 2017 Hamilton
Running two native apps
Every feature gets built twice, and every bug gets fixed twice.
Two native apps means two teams, two backlogs and two release trains drifting apart. iOS gets the feature in March, Android in May, and the roadmap meeting turns into a debate about which platform goes first.
-
Features take longer to ship
Every change is estimated, built and tested twice, so each release costs double the effort. -
The apps drift apart
Small differences pile up until customers on one platform get a different product than the other. -
The stack is aging
A modernization is already on the table. That is the cheapest moment to move to one codebase.
You can stay native, rewrite, or move to Flutter flow by flow. We’ll help you pick the right one, even when it isn’t Flutter.
- Stay native
When the app lives on the hardware
Right for apps built on deep hardware integrations, AR, heavy real-time rendering or wearables. We build native too, so we’ll tell you when it’s the better call.
- Big-bang migration
Everything at once, one launch day
Freezes the roadmap for months and bets the business on a single release. We don’t recommend it for a live, revenue-critical app.
- Flutter, flow by flow
Add-to-app, one flow at a time
Flutter goes inside your native apps one flow at a time. Customers keep using the app they know while it moves under them.
What changes when there’s one codebase.
Two native apps
One Flutter app
- Separate iOS and Android teams One team that ships to every platform
- Every feature built and tested twice Every feature built once
- Releases offset between platforms The same release on iOS, Android and the web
- Test coverage that varies by platform One test suite, held to our 100% coverage standard
- Engineers who can only work on one app Engineers who can move to wherever the roadmap needs them
The first step puts a running Flutter slice inside your native app.
You run separate iOS and Android apps, the rewrite keeps slipping, and nobody wants their name on a big-bang migration. This is where to start.
How it runs
-
Pick the flow
We review the codebase with your team and pick the flow.
-
Build the slice
We build the slice in your repo, next to your engineers.
-
Hand it over
We harden it, write the roadmap, and your team presents the readout.
Your native apps keep shipping the whole time.
You leave with
- 01 One real flow running in Flutter inside your live app
- 02 A written consolidation roadmap your engineering lead can estimate against
- 03 A readout your team gives to leadership
If we’re the wrong fit, we’ll say so.
Not ready for a call? Read the migration guide first.The Flutter Migration Curve.
We built the curve on research we ran with Google. Velocity dips while the foundation goes in, then climbs past where you started.
Read the migration guide- 01
Feasibility
Validate the fit and de-risk the move with strategy, scope and a pilot flow. We decide add-to-app or a modular rebuild together.
- 02
Foundation
Training, architecture, CI/CD and a Flutter-ready design system, set up in your repo.
- 03
Integration
Shared components and standards, then the priority flows, one at a time, inside the live app.
- 04
Acceleration
Retire the legacy stacks and ship to every platform from one codebase. This is the phase teams skip, and it’s where the savings are.
- 05
Innovation
Spend the capacity you freed up on new experiences for your customers.
AI reads both native apps. Your team signs off on every feature.
On Scooter’s Coffee, a multi-agent pipeline read both native codebases and wrote the spec. That’s how a 6–8 month estimate came in at 3–4 months, with full feature parity.
- 01
Analysis
A one-time read of the iOS and Android code produces a migration manifest and a brief for every feature. We review them with your team to lock the scope and the order. - 02
Design system
The theme is pulled out once, and every component ships in its own pull request with a Widgetbook use case. - 03
Features
Each feature gets its own packages, so engineers and coding agents migrate in parallel without touching each other’s files.
Scooter’s Coffee’s two native code bases, iOS in Swift and SwiftUI and Android in Kotlin and Jetpack Compose, listing the same seven features. One at a time, agents read a feature in both, merge the two into one, write a Flutter spec, and scaffold it across Figma, Jira, and Flutter, and the feature’s screen lands in one Flutter app. Both native apps stay live throughout. The feature buttons send a feature through next.
iOS Swift · SwiftUI
Live
Teams that made the move.
All success stories
Two native apps into one, with zero downtime
- native apps into one codebase
- 2
- downtime
- 0
- feature parity
- 100%
Betterment: two native codebases into one
- Betterment accounts
- 775K+
- in assets, March 2023
- $32B
- Flutter developers trained
- 20+
V1 Sports doubles revenue with Flutter
- revenue, year over year
- 2x
- user accounts
- 300K+
- codebases unified
- 6 → 1
Before you plan the move.
Short answers from real migrations. Anything else, bring it to the first call.
01 Can we migrate without rewriting everything at once?
Yes. With add-to-app, Flutter runs inside your existing iOS and Android apps. Betterment started with a single account-creation flow, then moved the rest a piece at a time while building everything new in Flutter.
02 Will our customers notice?
Not on Scooter’s. Two revenue-critical apps moved into one Flutter codebase with zero downtime and full feature parity.
03 What happens to our iOS and Android engineers?
They become Flutter engineers. We train them while we migrate. Betterment’s engineers were building production Flutter features a week after training. See Flutter Enablement.
04 Should we set up a dedicated migration team?
For a large app, yes. Headspace tried spreading the migration across every squad, and it stalled. A centralized team of 27 engineers rebuilt the foundation, then went back to their squads as Flutter champions. Pierre Benz told the story on our podcast: how Headspace rebuilt with Flutter.
05 What if we stop halfway?
Then you pay for three stacks instead of two. We plan and resource the removal of the old native code from the start, because that is where the savings are.
06 How long does a migration take?
It depends on the size of the apps and how much you move at once. Scooter’s took 3–4 months for two mature apps. The first step gives you a roadmap your engineering lead can estimate against.
07 Do we have to freeze the roadmap?
No. New features get built in Flutter as the migration goes, so the roadmap keeps moving the whole time.
08 Who owns the code?
You do, along with the IP, from the first commit. It lives in your repo the whole time.
We’ll care about your success as much as you do.
Our unicorns read every message and reply, usually the same day.
Start the conversationA 30-minute call about what you’re building.