iOS in Swift, Android in Kotlin. Two mobile teams. Six engineers. iOS shipped 2-3 weeks ahead of Android. Bugs lived on one platform and not the other. Hiring a senior iOS and a senior Android engineer was 4 months apiece.
Migration Native to cross-platform migration · Flutter or React Native · UK
Native to cross-platform migration for the team shipping two apps. at half the speed of one.
We move UK mobile teams off two native codebases — Swift and Kotlin — onto Flutter or React Native, with native modules kept where they earn their keep. One codebase, two stores, profiled before launch.
6mobile migrations shipped
1codebase, 2 stores
5-dayfixed-scope audit
(Why founders + CTOs migrate now)
You don’t need to leave native. You need to stop building every feature twice.
One codebase and one team can match the velocity of two native teams. Hiring narrows. Onboarding shortens. Both stores ship together. Native stays where it earns its keep.
0
0%
8–16wk
The product lead this page is for2 codebases · 6 engineers · 8-week backslide
Rachel runs product at a UK field-service SaaS. Every feature was built twice.
A senior iOS engineer left and the team backslid 8 weeks. The roadmap suffered. The CTO had to choose between hiring more native engineers or rebuilding. We ran a 16-week migration to Flutter. Native modules kept for BLE, offline SQLite, biometrics, and Apple Pay.
Cutover one screen at a time behind a feature flag. By week 14, 92% of screens were Flutter and both stores shipped together. This page is for the founder or CTO who has decided the migration is happening, and wants it to land without taking the business down.
Our migration process
Four phases, each one a board deliverable
No mystery box. Each phase is fixed-scope, fixed-price, and ends with a written deliverable. You decide whether to continue at every phase boundary.
Phase 01
Migration audit (5 days, £8K)
Two senior engineers read your Swift + Kotlin estate, data and infra. Output: a 20-30 page audit pack, risk matrix, target architecture, and a fixed quote.
Phase 02
Plan + parallel build (2-4 weeks)
We build the Flutter / RN target in parallel. Your native system keeps running. Data migration dry-runs, integrations rebuilt, shadow-read pattern wired.
Phase 03
Cutover (planned window)
Screens migrate one at a time behind a feature flag. Embedded Flutter / RN view inside the native shell. Rollback per screen, not per app.
Phase 04
Stabilise + decommission (2-6 wk)
We monitor, fix what only production surfaces, hand over to your team, and decommission the old estate on a schedule you sign off.
The risk that sinks migrations. How we close it before cutover.
We don’t pretend migrations are safe. We make the risks legible and mitigated, in writing, before a single line of production code changes.
- 01
“We can’t tell which cross-platform framework is right for our team.”
Flutter default, React Native when you’re React-deep. Flutter for rendering, animation, and design system fidelity with one language (Dart). React Native if your team is already deep in React and the context-switch cost is high.
- 02
“Half our app is BLE, biometrics, and Apple Pay. Can that survive?”
Kept native behind thin platform-channel bridges. BLE, offline-first SQLite, biometrics, Apple Pay / Google Pay SDKs, ARKit / ARCore, screen sharing. We catalogue these at audit and keep them native. We don’t fight the platform.
- 03
“Our product depends on iOS feeling like iOS and Android like Android.”
Material 3 on Android, Cupertino on iOS. Sometimes a custom design system that lives above both. We don’t accept ‘same on both’ if your product depends on platform feel.
- 04
“We heard cross-platform apps are bloated and slow to open.”
Tree-shaken, deferred, under budget. Flutter / RN apps are 8-30MB before code. We profile, tree-shake, and use deferred components. Cold-start budget under 1.5s. Frame budget 16ms at 60fps.
- 05
“Two store releases is already a manual, error-prone mess.”
App Store + Play Store automated from day one. Fastlane + CI, TestFlight + Play Internal Testing for staged rollout, App Bundle for Play, signing and entitlements and provisioning audited.
- 06
“Our offline sync logic is the scariest part of the codebase.”
Riverpod / Bloc or Redux Toolkit / Zustand. Offline-first with SQLite (Drift / Realm) or WatermelonDB. Sync logic explicit and tested, not implicit and hoped-for.
- 07
“We can’t afford a big-bang rewrite that goes dark for months.”
Screen-by-screen behind a feature flag. We don’t big-bang a mobile rewrite. An embedded Flutter / RN view sits inside the native shell. Screens migrate one at a time. Rollback is per screen, not per app.
- 08
“What happens to our iOS and Android engineers after the migration?”
Your native team becomes the Flutter / RN team. We pair, run workshops, and let your team own the cross-platform code by cutover. No knowledge silo, no dependency on us forever.
The Flutter / RN stack we migrate you onto.
Flutter is our default for fully-rewritten cross-platform apps. React Native when your team is React-deep. Native modules stay where they earn it.
T1
Default target stack
Flutter-firstFlutterReact NativeDartTypeScriptRiverpod / BlocRedux Toolkit / ZustandDrift / Realm / SQLiteFirebase / SupabaseFastlaneMixpanel + AmplitudeSentryCodemagic / Bitrise
T2
Migration-specific tooling
kept nativePlatform channelsSwift / Kotlin modulesApple Pay / Google Pay SDKBLE pluginsBiometrics pluginsStorybook for Flutter / RN
T3
Infra, observability, safety net
AWS-defaultApp Store ConnectGoogle Play ConsoleTestFlightPlay Internal TestingFirebase CrashlyticsFirebase App DistributionAWS AmplifyDatadog RUMSentry Mobilek6 / mobile loadCharles / Proxyman
Swift + Kotlin to Flutter · field-service SaaS · UK
Two native apps,
Two native apps,
one Flutter codebase, in numbers
Brief: stop building everything twice. Sixteen-week migration to Flutter. Native modules kept for BLE, offline SQLite, biometrics, and Apple Pay. Material 3 on Android, Cupertino plus custom on iOS. Screen-by-screen cutover behind a feature flag. By week 14, 92% of screens were Flutter.
The migration
16 wk
Migration sprint to Flutter
92%
Screens on Flutter by week 14
The team
64
Engineers (2 redeployed to backend)
21
Codebases, both stores ship together
Kept native
BLE
Plus biometrics + Apple Pay
<1.5s
Cold-start budget held
Two phases. Audit, then migration sprint.
Pick the shape that fits and Mohit will send your real number inside 24 hours.
5-day migration audit
Two senior engineers read your Swift + Kotlin estate, data, and integrations. Map the migration, write the risk matrix, quote the sprint.
- 20-30 page audit pack
- Target architecture + data plan
- Risk matrix + rollback plan
- £8,000 fixed (GBP)
Flutter / RN migration sprint
Parallel build, dry-run data migration, planned cutover, post-cutover stabilisation, decommission. 8-16 weeks by estate size.
- Flutter (default) or React Native
- Native kept where it earns it
- Screen-by-screen behind flags
- From £35,000 fixed (GBP)
Post-migration retainer
One day a week of senior engineering for 3-6 months. New surface area, performance work, integrations. Your team gets unblocked.
- One senior day / week
- Performance + new surfaces
- Your team owns the code
- From £5,000 / month (GBP)
“By week 14, 92% of screens were Flutter and both stores shipped together. The team velocity that needed eight native engineers ran on four.”
— CTO, UK field-service SaaSReal questions from the audit call
Direct answers, no marketing varnish.
Flutter is our default for new and fully-rewritten cross-platform apps: better rendering performance, animation fidelity, design system control, and a single language (Dart). We pick React Native if your team is React-deep and your design fidelity tolerates platform UI components. We’ll recommend at the audit based on your team, product, and UX bar, not a house preference.
Yes. Native modules are kept where they earn it: BLE, offline-first SQLite, biometrics, Apple Pay / Google Pay native SDKs, ARKit / ARCore, screen sharing. We bridge them via platform channels with thin, well-tested wrappers. The native to Flutter migration doesn’t mean throwing away the parts of native that work.
Flutter plus Cupertino plus Material 3 plus a custom design system can match native feel for most apps. We’ll be honest at the audit if your specific UX bar requires native. Sometimes it does: very high-frame-rate games, ARKit-heavy AR, deeply customised camera apps. We tell you that before you commit, not after.
Ten to twenty weeks is typical. Screen count, native dependency depth, offline-first requirements, and design system maturity drive scope. We migrate behind feature flags, screen-by-screen, so you ship value continuously instead of going dark for months on a big-bang rewrite.
Flutter and React Native are both well-understood by Apple and Google review. We’ve seen no additional scrutiny. We hand over Fastlane, signing, entitlements, Play Console, and App Store Connect with documentation so the next release after handover is yours to ship cleanly.
30-day walk-away both ways. Milestone billing. UK VAT registered, listed on Companies House, shipping since 2019. IP assigns on every commit, so the code is in your GitHub org from day one. You’re never more than a few weeks at risk of paying for nothing.
Your native team becomes the Flutter / RN team. We pair, run workshops, and let your engineers own the cross-platform code by cutover. On the field-service migration, two of six engineers were redeployed to backend work because one cross-platform team did what two native teams used to. No knowledge silo, no dependency on us forever.
Yes, with 14 days’ notice. Engineers move to other projects, spend pauses, and you resume with 14 days’ notice. No cancellation fee, no restart fee. Because we migrate screen-by-screen behind flags, a pause leaves you with a shipping app, not a half-finished rewrite.
In context
The surface you hand over.
native to cross platform migration, in context — the dashboards, flows and components your team actually ships, reviews and maintains.
One paragraph. That’s it.
Send a 5-line brief: your current Swift + Kotlin estate (traffic, data size, integrations), why you want to migrate, and the deadline you’re working to. Mohit replies inside 24 hours with availability and the next 5-day audit slot.
What happens after the email lands
- < 24h
A personal reply.
Yes, no, or the deciding question. Straight to your inbox.
- Day 5
Audit pack lands.
Risk matrix, target architecture, data plan, fixed migration quote.
- Cutover
One codebase, two stores.
Screen-by-screen behind flags. Native kept where it earns it.