Kotlin Multiplatform vs Flutter for Shared Logic
Compare Kotlin Multiplatform vs Flutter to decide which cross-platform mobile approach fits teams with existing native iOS and Android apps.
Teams with mature iOS and Android apps hit a specific frustration: the same business rule (a pricing calculation, a validation function, a sync algorithm) gets written and maintained twice. A bug gets fixed on Android and quietly lives on in the iOS build for another sprint. The question of Kotlin Multiplatform vs Flutter comes up precisely here, not at greenfield project kickoff.
Both technologies target cross-platform mobile, but they answer different problems. Kotlin Multiplatform (KMP) says: keep your native apps, share the logic underneath. Flutter says: replace the native apps entirely with a single codebase that owns its own rendering engine. That distinction matters enormously if you've already shipped native code and have a team that knows Swift and Kotlin.
The wrong choice here costs months. We've seen teams at Laxaar migrate a shared domain layer to KMP, and we've built production Flutter apps from scratch. This post shares what we've learned about which approach fits which situation.
What you'll learn
- What KMP actually shares — and what it doesn't
- How Flutter's rendering model differs from native UI
- A direct comparison across key decision factors
- When KMP wins for existing native apps
- When Flutter is the better call
- How to structure a KMP shared module
- The real trade-offs you should plan for
- Frequently Asked Questions
What KMP actually shares — and what it doesn't
Kotlin Multiplatform is a Kotlin compiler feature that lets you write Kotlin code targeting multiple platforms: JVM (Android), iOS via LLVM, web, and desktop, all from a single source set. It's not a UI framework. It doesn't draw buttons or manage navigation. It compiles your shared Kotlin code into a native iOS framework (via Kotlin/Native) that Swift or Objective-C code can call directly.
What belongs in a KMP shared module: data models, repository implementations, networking (using Ktor), local database logic (using SQLDelight), domain-layer use cases, and any algorithm that must stay consistent across platforms.
What stays native: all UI, platform-specific APIs, push notifications, camera, biometrics, and anything that needs to feel genuinely platform-native. With KMP, it literally is native.
This is the arrangement that makes KMP compelling for teams that already have native apps. You don't throw away the SwiftUI views your iOS team spent months building. You stop duplicating the data layer underneath them.
// shared/src/commonMain/kotlin/com/example/domain/PricingEngine.kt
class PricingEngine(private val config: PricingConfig) {
fun calculate(quantity: Int, unitPrice: Double): PricingResult {
val subtotal = quantity * unitPrice
val discount = config.discountRate(quantity)
return PricingResult(
subtotal = subtotal,
discount = subtotal * discount,
total = subtotal * (1.0 - discount)
)
}
}
This class compiles to both the Android app and a native iOS .framework. No glue code required beyond Gradle configuration.
How Flutter's rendering model differs from native UI
Flutter is a UI toolkit from Google that compiles Dart code to native ARM and draws its own pixels using the Skia (or Impeller, in newer versions) rendering engine. It doesn't use native iOS UIKit views or Android Views at all. The buttons, text fields, and animations you see are Flutter's own implementations, pixel-matched to look like the platform's native controls.
This owned-rendering model has a real advantage: pixel-perfect consistency across platforms with a single codebase, and no dependency on the platform's own widget changes. The trade-off is that "looks native" requires deliberate effort. Flutter's Material and Cupertino widget sets are good, but they lag behind iOS and Android design updates.
For a team starting from zero, Flutter is genuinely productive. One Dart codebase covers iOS, Android, web, and desktop. Dart's hot reload cycle is fast. The widget tree model is learnable in days.
For a team with 50,000 lines of Swift and 60,000 lines of Kotlin, Flutter means rewriting everything. That's not a technology choice; that's a multi-year project.
Direct comparison across key decision factors
| Factor | Kotlin Multiplatform (KMP) | Flutter |
|---|---|---|
| UI layer | Native per-platform | Owned renderer (Skia/Impeller) |
| Language | Kotlin (shared), Swift/Kotlin (UI) | Dart |
| iOS integration | Swift-callable .framework | Full app replacement |
| Greenfield fit | Good | Excellent |
| Brownfield fit | Excellent | Poor (requires full rewrite) |
| Ecosystem maturity | Growing; Ktor, SQLDelight stable | Mature; pub.dev well-populated |
| Performance | Native (shared code compiles to native) | Near-native; renderer overhead minimal |
| Platform-specific feel | Guaranteed (uses real native UI) | Requires deliberate effort |
| Team prerequisite | Kotlin knowledge required | Dart learning curve for native devs |
When KMP wins for existing native apps
The clearest KMP use case is a team that already ships separate iOS and Android apps and keeps finding bugs that exist in one platform but not the other. The source of those bugs is almost always duplicated business logic.
KMP lets you extract that logic into a shared module without touching the UI. The iOS team keeps writing SwiftUI. The Android team keeps writing Compose or XML layouts. Both call into the same compiled Kotlin domain layer. Feature parity between platforms becomes a compile-time guarantee for the shared code rather than a code-review discipline.
This approach also has a lower organisational risk profile. If KMP doesn't work out for a particular module, you remove the dependency and rewrite that module natively. The blast radius is small. You haven't bet your entire product on one framework.
A practical entry point is the data layer. Take your API client and your local persistence layer, port them to a KMP shared module using Ktor and SQLDelight, and wire up both platforms. That migration is achievable in two to four weeks for a medium-sized app and immediately eliminates a whole class of consistency bugs.
When Flutter is the better call
Flutter's case is strongest for new products, internal tools, or apps where visual consistency across platforms matters more than platform-native feel.
Enterprise dashboards, internal ops tools, and B2B applications often fit this profile. Users of these apps care that the tool works, not whether the segmented control follows iOS HIG. A single Flutter codebase cuts delivery time by a genuine 30-40% compared to parallel native development, and the Dart ecosystem has mature packages for most common needs.
Flutter also makes sense for consumer apps where the target audience is primarily on one platform but the team needs a quick port to the other. Building the Android version of an iOS-first app is much faster when you're porting Dart rather than rewriting in Kotlin.
The honest caveat: Flutter's Impeller renderer has improved substantially, but heavily customised platform UI (complex text input, native share sheets, accessibility on older OS versions) still requires platform channels and additional engineering. Budget for it.
How to structure a KMP shared module
A well-structured KMP project separates concerns at the Gradle source set level. The commonMain source set holds pure business logic with no platform dependencies. androidMain and iosMain source sets hold actual implementations of platform-specific expect declarations.
shared/
src/
commonMain/kotlin/
data/
remote/ApiClient.kt # Ktor HttpClient, platform-agnostic
local/AppDatabase.kt # SQLDelight schema
domain/
PricingEngine.kt
SyncScheduler.kt
androidMain/kotlin/
platform/PlatformContext.kt # actual implementation
iosMain/kotlin/
platform/PlatformContext.kt # actual implementation
The expect/actual mechanism handles the cases where platforms genuinely differ:
// commonMain
expect fun currentTimeMillis(): Long
// androidMain
actual fun currentTimeMillis(): Long = System.currentTimeMillis()
// iosMain
actual fun currentTimeMillis(): Long =
NSDate().timeIntervalSince1970.toLong() * 1000
Keep the shared module's public API minimal and focused. The more you try to share, the more expect/actual boilerplate you accumulate. Our rule of thumb: if you're writing more than two platform-specific implementations of the same concept, reconsider whether that code belongs in the shared layer.
The real trade-offs you should plan for
KMP has one friction point that's worth naming directly: the Kotlin/Native memory model. For years, Kotlin/Native's strict object ownership rules made sharing mutable state across threads awkward. The new memory manager (stable since Kotlin 1.9) resolves most of this, but older tutorials and Stack Overflow answers describe the old model. Be careful which documentation you follow.
Flutter's main trade-off is the Dart language itself. Most mobile developers come from Swift or Kotlin, and Dart feels like a step backward in type expressiveness compared to either. Null safety in Dart 3 is genuinely good, but developers accustomed to Swift's value types and protocol extensions find Dart's class-heavy model limiting.
There's a real dependency risk on both sides. KMP is a JetBrains project with strong backing, but the iOS ecosystem runs on Apple's terms. If Apple changes how native frameworks are distributed or loaded, JetBrains has to adapt. Flutter is Google's project, and Google has deprecated developer tools before. Neither scenario is likely, but both are worth pricing into the decision rather than ignoring.
Our take: for teams with existing native apps, KMP is the technically lower-risk choice because the native apps remain the primary asset. For greenfield, Flutter saves real time and the deprecation concern is the same category of risk as any major dependency.
If you're building new mobile app development products or evaluating frameworks for an upcoming project, the Laxaar team is happy to help you think through the architecture. Our custom software development practice has shipped both KMP and Flutter apps, and we can point to production evidence rather than theory.
For teams exploring AI-assisted development workflows alongside mobile choices, our AI development services integrate into mobile product pipelines, including automated testing layers that work with both KMP and Flutter projects.
Frequently Asked Questions
Can KMP and Flutter be used together in the same project?
Technically yes: you can embed a Flutter module inside a native iOS or Android app that also consumes a KMP shared library. In practice, this creates significant complexity: two separate build systems, two separate dependency chains, and a confusing ownership model. We'd only recommend this as a temporary migration path, not a steady-state architecture.
Does KMP replace the need for separate iOS and Android developers?
No. KMP shares the business logic layer, but the UI layers remain platform-specific. You still need iOS developers writing SwiftUI and Android developers writing Compose. The payoff is that those teams stop duplicating domain logic and bug-fixing the same issues twice. For small teams, KMP can reduce the amount of back-and-forth, but it doesn't reduce headcount the way Flutter theoretically can.
How mature is the KMP ecosystem for production apps?
Ktor (networking) and SQLDelight (local persistence) are both stable and production-ready. Kotlin Multiplatform itself graduated from Alpha/Beta to Stable in Kotlin 1.9. Large companies including Netflix, VMware, and Cash App have shipped KMP in production. The ecosystem is meaningfully smaller than Flutter's, but for the layers where KMP is typically used (data and domain), the tooling is solid.
Is Flutter fast enough for performance-sensitive mobile apps?
For most consumer and business applications, Flutter's performance is more than adequate. The Impeller renderer has eliminated most of the jank issues that affected older Flutter apps on iOS. Where Flutter still struggles is with very long scrollable lists of complex items (though ListView.builder lazy loading mitigates this), and with deeply integrated platform features that require heavy use of platform channels. Games and apps with complex 2D/3D graphics should consider Unity or a native approach instead.
What's the recommended migration path from two native apps to KMP?
Start with a bounded, well-understood domain module: the API client or a single feature's data layer. Write the KMP module, integrate it into both native apps, run your existing tests against it, and delete the duplicated code. Prove the pattern works before expanding it. Avoid a big-bang migration where you try to move the entire shared layer at once; the integration surface is too large to validate safely.
How does Laxaar approach framework selection for new mobile projects?
We start by asking whether an existing native app is in scope. If yes, KMP gets serious consideration for the shared logic layer regardless of what the UI framework ends up being. If it's a greenfield project with a tight timeline and the team is open to Dart, Flutter is often the faster path. We document the decision with the trade-offs acknowledged so future teams know why the choice was made, not just what it was.
Choosing between Kotlin Multiplatform and Flutter is a decision about what you're protecting. KMP protects your existing native investment while eliminating duplicated logic. Flutter protects your development velocity on new builds at the cost of platform-native feel.
The Laxaar team has shipped production apps using both approaches. If you're working through this decision for a real project, get in touch with us. We can review your existing codebase, your team's skills, and your timeline to give you a recommendation grounded in evidence rather than framework advocacy.
Working on something like this?
Get a fixed scope, timeline, and price within one business day — no obligation.
