<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed" -->

---
title: Gradual Migration from Flutter to Compose Multiplatform
description: A team migrated a production Flutter app to Compose Multiplatform incrementally using the Strangler Fig pattern. Flutter remains the outer shell while selected...
canonical: https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Gradual Migration from Flutter to Compose Multiplatform | daily.dev
og:description: A team migrated a production Flutter app to Compose Multiplatform incrementally using the Strangler Fig pattern. Flutter remains the outer shell while selected...
og:url: https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed
og:image: https://api.daily.dev/og/posts/aks8nTBEd.png
og:image:alt: Gradual Migration from Flutter to Compose Multiplatform
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Gradual Migration from Flutter to Compose Multiplatform

**[Medium](https://daily.dev/sources/medium_js)** · 6 min read · 1 upvotes · 0 comments

## Summary

A team migrated a production Flutter app to Compose Multiplatform incrementally using the Strangler Fig pattern. Flutter remains the outer shell while selected modules are rebuilt in CMP and embedded via platform views (AndroidView/UiKitView). The architecture uses a two-channel bridge: one per-instance method channel for UI events and one global backend channel for app-level state sync. The post covers module structure, contract design using JSON, platform-specific embedding steps for Android and iOS, migration workflow with feature flags, and honest guidance on when this approach is or isn't appropriate.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/@miqdadya/gradual-migration-from-flutter-to-compose-multiplatform-5aba23630011>

## Questions this post answers

### How can I migrate an existing Flutter app to Compose Multiplatform without a full rewrite?

Use the Strangler Fig pattern: keep Flutter as the outer application shell handling navigation, lifecycle, and unmigrated screens, while rebuilding isolated modules in Compose Multiplatform and embedding them via native platform views (AndroidView/UiKitView). Modules communicate through a per-instance method channel for UI events and a single global backend channel for shared state like session, locale, and theme, avoiding cross-language type sharing by using JSON contracts.

_daily.dev surfaces engineering writeups like this for teams weighing a Flutter to Compose Multiplatform migration._

### What is a good architecture for bridging Flutter and Compose Multiplatform in the same app?

A two-channel bridge works well: one method channel per embedded platform view instance (e.g. native_view_channel_{id}) handles bidirectional UI events scoped to that screen, while a single global channel (e.g. backend_method_channel) keeps Flutter and the shared Kotlin code aligned on application-level state such as session, locale, and theme, persisted via Room and DataStore.

_Teams designing Flutter-to-CMP bridges can track patterns like this through daily.dev._

### Which modules are good first candidates when incrementally migrating a Flutter app to Kotlin Multiplatform?

Good first candidates are self-contained UI with clear boundaries, high-churn screens that change frequently, and form- or list-heavy surfaces where the team wants to move fast in Kotlin. Deeply coupled real-time flows, modules with heavy plugin dependencies not yet available in KMP, and low-change stable legacy screens are better left for later or deferred entirely.

_Planning a phased Dart-to-Kotlin migration is easier when following prioritization guidance surfaced on daily.dev._

## Similar posts on daily.dev

- [Medium](https://daily.dev/posts/medium-bgqngssje) · Medium · 0 upvotes · 0 comments
- [Compose Multiplatform Is a Business Decision, Not a Technical One](https://daily.dev/posts/compose-multiplatform-is-a-business-decision-not-a-technical-one-oo4sm9b4f) · Touchlab · 1 upvotes · 0 comments
- [Why Your Compose Multiplatform App Still Needs Native Code](https://daily.dev/posts/why-your-compose-multiplatform-app-still-needs-native-code-vwywn1ts5) · droidcon · 0 upvotes · 0 comments
- [Why we love multiplatform with Kotlin and Compose](https://daily.dev/posts/why-we-love-multiplatform-with-kotlin-and-compose-ygw5twyaa) · Q42 Engineering · 0 upvotes · 0 comments
- [One Tap, Three Machines: How Android Views, Flutter, and Compose Actually Render Your UI](https://daily.dev/posts/one-tap-three-machines-how-android-views-flutter-and-compose-actually-render-your-ui-ruoe8zjtc) · ProAndroidDev · 0 upvotes · 0 comments

---

Tags: [#flutter](https://daily.dev/tags/flutter), [#kotlin](https://daily.dev/tags/kotlin), [#compose-multiplatform](https://daily.dev/tags/compose-multiplatform)

[View this post on daily.dev](https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Gradual Migration from Flutter to Compose Multiplatform","url":"https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed"},"datePublished":"2026-07-12T08:49:49.427Z","dateModified":"2026-09-14T06:00:05.690Z","description":"A team migrated a production Flutter app to Compose Multiplatform incrementally using the Strangler Fig pattern. Flutter remains the outer shell while selected...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5ea54f043d31e6ab6bb5310ff94e5b4e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5ea54f043d31e6ab6bb5310ff94e5b4e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"flutter,kotlin,compose-multiplatform","timeRequired":"PT6M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Gradual Migration from Flutter to Compose Multiplatform"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/gradual-migration-from-flutter-to-compose-multiplatform-aks8ntbed#faq","mainEntity":[{"@type":"Question","name":"How can I migrate an existing Flutter app to Compose Multiplatform without a full rewrite?","acceptedAnswer":{"@type":"Answer","text":"Use the Strangler Fig pattern: keep Flutter as the outer application shell handling navigation, lifecycle, and unmigrated screens, while rebuilding isolated modules in Compose Multiplatform and embedding them via native platform views (AndroidView/UiKitView). Modules communicate through a per-instance method channel for UI events and a single global backend channel for shared state like session, locale, and theme, avoiding cross-language type sharing by using JSON contracts. daily.dev surfaces engineering writeups like this for teams weighing a Flutter to Compose Multiplatform migration."}},{"@type":"Question","name":"What is a good architecture for bridging Flutter and Compose Multiplatform in the same app?","acceptedAnswer":{"@type":"Answer","text":"A two-channel bridge works well: one method channel per embedded platform view instance (e.g. native_view_channel_{id}) handles bidirectional UI events scoped to that screen, while a single global channel (e.g. backend_method_channel) keeps Flutter and the shared Kotlin code aligned on application-level state such as session, locale, and theme, persisted via Room and DataStore. Teams designing Flutter-to-CMP bridges can track patterns like this through daily.dev."}},{"@type":"Question","name":"Which modules are good first candidates when incrementally migrating a Flutter app to Kotlin Multiplatform?","acceptedAnswer":{"@type":"Answer","text":"Good first candidates are self-contained UI with clear boundaries, high-churn screens that change frequently, and form- or list-heavy surfaces where the team wants to move fast in Kotlin. Deeply coupled real-time flows, modules with heavy plugin dependencies not yet available in KMP, and low-change stable legacy screens are better left for later or deferred entirely. Planning a phased Dart-to-Kotlin migration is easier when following prioritization guidance surfaced on daily.dev."}}]}
```

