Shared Logic First

Published April 2026, updated May 2026 by Batteries Included

Short answer

We usually start with Kotlin Multiplatform for shared business logic, not shared UI. Google's Android documentation describes Kotlin Multiplatform as a way to share business logic across Android and iOS, while JetBrains' stable release post marks KMP as stable and production-ready. Compose Multiplatform is a separate decision: useful for some products, but still something we evaluate against team skill, UI risk, and release needs.

The Problem We Keep Seeing

Most mobile teams we talk to are maintaining two codebases that do the same thing. The iOS app has its own networking layer, its own validation, its own data models. The Android app has a parallel set. Every feature ships twice, every feature can have different bugs per platform, and the two versions can slowly drift apart in behavior.

This is expensive, not just in engineering hours, but in the compounding cost of inconsistency. Users notice when the Android version behaves differently from the iOS version. QA catches it late. Product managers learn to scope features smaller because "it takes twice as long to ship." Over time, the maintenance tax eats into the team's ability to build anything new.

Meanwhile, the market for "we build apps" is being compressed by AI tools and low-cost agencies. Simply writing code is no longer a differentiator. What matters now is architecture that reduces the cost of change; because the cost of change is what determines how fast your product can evolve after launch.

Our Principle: Product Outcomes Before Stack Religion

We don't recommend technology because we like it. We recommend it when it moves a measurable needle for the product: time to market, maintenance cost, release cadence, defect rate. If native Swift and Kotlin are the right answer, we say so. If KMP can remove duplicated business logic without sacrificing native quality, we say that too, with specifics about where sharing helps and where it does not.

This is the lens we apply to every architecture decision, and it's why we think in layers rather than picking one framework and applying it everywhere.

Layer 1: KMP Shared Business Logic

Kotlin Multiplatform's core value proposition is sharing business logic: the code that doesn't touch pixels. Authentication flows, API clients, data validation, caching strategies, domain rules, and state management can all live in a shared Kotlin module that compiles to native code on every target platform.

This is the safest starting layer in the KMP ecosystem. Google documents KMP for sharing business logic between Android and iOS, and JetBrains declared Kotlin Multiplatform stable in November 2023. JetBrains also publishes Kotlin Multiplatform case studies; for example, Netflix has written publicly about using KMP for platform-agnostic business logic in its production studio apps.

For most teams we work with, shared business logic is the default starting point. The risk is low, the payoff is immediate (one implementation instead of two for every feature), and the migration path is incremental; you can move one module at a time without rewriting your apps.

This is also what makes KMP migration audits valuable: we look at your existing codebases, identify which layers of logic are duplicated, and build a roadmap for consolidating them without disrupting your release schedule.

Layer 2: Native UI (When It Wins)

KMP's defining difference from Flutter and React Native is that your UI can remain fully native. SwiftUI on iOS, Jetpack Compose on Android; each platform's own toolkit, with all the platform-specific behaviors, animations, and accessibility support that users expect.

We recommend native UI when any of the following apply:

• Brand-critical UX: Your product's user experience is a competitive advantage and you need pixel-perfect control on each platform.
• Heavy platform API usage: Camera, ARKit, HealthKit, platform-specific widgets, deep OS integrations that are easier to build natively.
• Team structure: Your iOS and Android teams have strong platform expertise and prefer to own their UI layer.

Native UI with shared KMP logic underneath gives you the best of both worlds: consistency in behavior, platform-native look and feel. See our Android UI / UX case study for an example of how we build responsive, adaptive interfaces with Jetpack Compose.

Layer 3: Compose Multiplatform (Where It Fits)

Compose Multiplatform (CMP) takes the sharing further: from logic into the UI itself. Instead of writing SwiftUI and Jetpack Compose separately, you write one Compose UI that renders natively on both platforms.

What's Stable

JetBrains shipped Compose Multiplatform 1.8.0 in May 2025, marking Compose for iOS as officially stable and production-ready. JetBrains' release post also discusses accessibility, iOS behavior, startup time, scrolling performance, and additional iOS app size in the context of that release.

That does not mean every app should share UI. We still treat Compose Multiplatform as a product and team decision: it can reduce duplicated UI work, but native SwiftUI and Jetpack Compose remain the better fit when platform-specific interaction detail matters more than shared surface area.

What's Still Maturing

Web (Kotlin/Wasm) for CMP is Beta. It's usable for early adopters, but not at the same stability level as mobile. If your product needs shared UI on web, that's a higher-risk bet today.

The CMP ecosystem is also younger than Flutter's or React Native's. There are fewer third-party libraries, fewer community tutorials, and the tooling, while improving rapidly, is not as mature. Build times with Kotlin/Native can be slower than pure native development. Kotlin's Swift export documentation also labels Swift export as experimental, so we do not plan production architecture around it as if it were stable.

When We Recommend CMP

We suggest Compose Multiplatform when:

• Your team is already comfortable with Kotlin and Jetpack Compose, and adding SwiftUI expertise would be a bottleneck.
• Your product doesn't rely heavily on platform-specific UI patterns that would be difficult to express in shared Compose code.
• You're building a new product and the speed advantage of one UI codebase outweighs the ecosystem trade-offs.
• You're willing to drop into native code (via expect/actual) for specific screens or components where CMP falls short.

We don't recommend CMP for web-primary products today, or for teams that need the deepest possible native fidelity on iOS. For those cases, native UI with KMP shared logic is the better path.

How We Work: Discovery First, Then Architecture

We don't walk into an engagement with a predetermined stack. Every product starts with a discovery and roadmap session where we define features, user flows, and technical constraints before making architecture decisions.

The deliverable of that session is a plan that says specifically: here is what should be shared logic (KMP), here is what should be native UI, here is whether CMP makes sense for your situation, and here is the migration path if you have existing apps. No "big bang" rewrites: incremental adoption, one module at a time, with clear milestones.

This approach works because KMP is designed for incremental adoption. You can start by sharing your networking layer, then your data models, then your domain logic, proving value at each step before committing further.

The Bottom Line

Kotlin Multiplatform itself is stable and production-ready according to JetBrains, and Google documents it as an Android/iOS code-sharing option. The real question is not whether KMP exists as a serious option; it's which layers of your product benefit most from sharing, and how to adopt it without disrupting what already works.

Compose Multiplatform adds shared UI to that story, and it's now stable on mobile. But it's not the only answer, and it's not always the right answer. Native UI with shared logic is a perfectly valid, often preferable architecture. The choice depends on your team, your product, and your timeline.

We help you make that choice with real data, not hype. If you're evaluating KMP for a new product or considering a migration from separate codebases, we'd like to talk.