KMP Apps Doubled in a Year. Is Kotlin Multiplatform Production Ready for Your Next Enterprise Project?

In my opinion, the "is KMP ready?" debate ended sometime in 2024; the industry just hasn't updated its talking points yet.

Intro

I want to start with something that doesn't get said clearly enough in most KMP content: adoption data is not the same as hype data.

When a framework is overhyped, you see conference talks, LinkedIn and Medium posts, and X threads. You do not see JetBrains' Developer Ecosystem Survey showing usage jumping from 7% to 18% in a single year.

Twice as many KMP apps in the App Store compared to twelve months ago. Compose Multiplatform, the UI layer built on top of KMP, is already serving hundreds of millions of daily users across production apps. Apps that real users open every morning and whose engineering teams get paged if something breaks at 2am.

I've been in mobile development long enough to remember when "cross-platform" carried a negative connotation in serious engineering conversations. The argument was always the same: you sacrifice native quality for development speed, you accumulate hidden debt, and eventually you rewrite everything anyway.

What KMP actually represents, and what those doubling numbers are measuring, is a different kind of adoption. They are teams with existing native codebases, real enterprise clients, and zero appetite for risk who looked at the production evidence and made a deliberate technical decision.

Duolingo didn't adopt KMP because it was exciting, but because it made them faster. McDonald's didn't expand KMP from payments to their entire app because it was fashionable, but because the first module worked.

The growth from 7% to 18% in twelve months is not a small number in the context of professional development tooling. For comparison, most mature frameworks take years to move the needle that much. KMP did it in a single survey cycle, and the teams driving that growth are not early adopters in the startup sense: they are mid-size to large engineering organizations with production obligations and clients who expect stability.

The question is what specifically changed in the technology to make this level of trust possible at this speed, and whether those changes are durable enough to build on.

Kotlin Multiplatform for Enterprise Mobile Apps: why teams are finally committing budget

Below are the milestones that changed how architects, mobile leads, and CTOs evaluated Kotlin Multiplatform as a production investment.

Compose Multiplatform for iOS reaching stable status

Let’s be honest about what “unstable” meant here, because the usual phrasing (rough edges, still maturing) seriously downplays how blocking the situation was for enterprise teams.

Before going deeper, it’s important to separate two things that often get mixed in discussions like this: Kotlin Multiplatform as a shared logic layer, and Compose Multiplatform as a UI approach on top of it. We’ve broken this down in detail here: Kotlin Multiplatform vs Compose Multiplatform

Before stable status, sharing UI across iOS and Android with Compose Multiplatform introduced a category of risk that had nothing to do with missing components or APIs. Rendering on iOS could behave inconsistently in ways that were difficult to reproduce and almost impossible to justify to a client who noticed something felt off but couldn’t articulate why.

Scroll physics didn’t match iOS expectations. Accessibility trees weren’t reliably exposed to iOS tooling, which meant apps failed audits. Layout behavior diverged under certain device or OS conditions. These weren’t bugs you could file and wait out; they were systemic mismatches with iOS-native assumptions.

The rational response for any team shipping to enterprise clients was simple: don’t share UI. Share business logic, keep UI native, and accept the overhead. That wasn’t ideological conservatism; it was responsible engineering given the risk profile.

What changed when JetBrains released Compose Multiplatform 1.8.0 and declared iOS stable was a reclassification of risk. The Skia-on-Metal rendering pipeline reached a level of consistency where behavior became predictable instead of surprising. iOS scroll physics were addressed in ways that aligned with user expectations. UIKit interop boundaries stopped being fuzzy and started being explicit. Accessibility support improved enough that it ceased to be a default blocker for production apps.

Architecturally, this matters because it unlocked a decision that simply didn’t exist before: teams can now choose which screens to share and which to keep native. Serious teams want control and stable CMP made that control possible.

It’s also important to say this without marketing gloss: stable does not mean identical to SwiftUI. Complex animations still behave differently, and Compose on iOS doesn’t magically inherit the full native component ecosystem. For consumer-facing surfaces where iOS feel is non-negotiable, native UI is still the right call. But for dashboards, internal tools, utility flows, and consistency-driven features, CMP is no longer a gamble. It’s a defensible production choice, and that distinction is exactly what enterprises needed.

Swift Export, K2, and why the Objective-C tax

This milestone is less visible from the outside, but it quietly killed more KMP adoption attempts than almost anything else, especially in organizations where iOS engineers had real influence over architectural decisions.

Before Swift Export, Kotlin code reached iOS through an Objective-C translation layer. In practice, generated APIs violated Swift naming conventions, generics didn’t translate cleanly, suspend functions required awkward wrappers, and calling shared Kotlin modules felt like integrating a poorly designed third-party SDK. For iOS engineers with strong intuition for clean Swift APIs, this felt like a regression, not progress.

I’ve heard some version of “this helps Android and hurts iOS” more times than I can count, and at the time it wasn’t an unfair assessment. When senior iOS engineers push back, adoption dies long before it reaches a CTO’s spreadsheet.

Swift Export fundamentally changes that equation. Kotlin code is now surfaced directly as idiomatic Swift, not as Objective-C masquerading as Swift. Suspend functions map to async/await. Naming aligns with platform expectations. Protocols behave like Swift protocols. The iOS engineer doesn’t have to care that the code was written in Kotlin and that’s the real win.

As iOS developers at Aetherius who now build production KMP systems, we focus heavily on making Kotlin modules feel native to Swift teams.

Read more on KMP from an iOS developer's perspective.

The K2 compiler compounds this improvement in a way that matters commercially, not just technically. Large KMP codebases used to suffer from slow build times that quietly drained team velocity over weeks and months. K2 roughly doubling compilation speed in large projects shifts the daily feedback loop from frustrating to workable. In enterprise environments with hundreds of modules, that difference directly affects delivery timelines and morale.

How Duolingo, McDonald’s, and Bitkey by Block changed their architecture after these milestones

These improvements matter most when you look at how real teams adjusted their architecture once the blockers were gone.

Duolingo is the clearest example of compounding returns. Their CTO’s comment: “the more we use it, the more we find ourselves speeding up” and it describes what happens when shared logic meaningfully reduces the surface area for platform-specific bugs.

The 2024-2025 tooling improvements, particularly around build performance, are what made it possible for Duolingo to expand their shared surface without drowning in build-time debt.

McDonald's tells a more enterprise-relevant story. They introduced KMP through a single feature, payments, inside an existing production app, validated it, and only then expanded usage. Post-launch, they saw fewer crashes and better performance across both platforms. The eventual move toward a unified mobile team was a practical outcome of shared architecture creating shared context. Improved UIKit interop and clearer module boundaries made that expansion possible without triggering a risky rewrite.

Block, through their Bitkey wallet, represents the extreme end of adoption: roughly 95% shared code with Compose Multiplatform handling unified UI. That level of sharing would be a bad target for most enterprises, because the last few percent of platform-specific behavior tends to carry disproportionate complexity.

As an open-source Bitcoin wallet, consistency and auditability across platforms are product requirements, not preferences. CMP reaching stable status on iOS is what made that architecture viable without endless platform-specific exceptions.

Three teams, three adoption depths, three different reasons the milestones mattered, but the pattern is consistent. These technical improvements didn’t create the desire to adopt Kotlin Multiplatform. They removed the specific risks that prevented teams who already wanted its benefits from committing to it responsibly, with real budgets and real delivery expectations.

Production-ready KMP foundation used by Aetherius engineers

At Aetherius, we were early Kotlin Multiplatform adopters, building production apps with KMP at a time when most teams were still debating whether it was stable enough for real use. That meant we didn’t just experiment with it; we went through the actual failures, edge cases, and scaling problems in real client projects.

Over the years, working on enterprise-grade KMP systems, especially alongside iOS teams, we refined a structure that consistently holds up under production pressure: build times, modular scaling, platform differences, CI complexity, and long-term maintainability.

We’re sharing here the same production foundation our engineers use when we build and scale real Kotlin Multiplatform applications for clients.

It includes:

• Clean architecture for shared + platform layers
• Preconfigured KMP module structure designed for scale
• Ktor networking setup used in production apps
• Firebase integration patterns tested in real systems
• Architectural decisions shaped by real enterprise constraints (not simplified examples)

This structure exists because KMP adoption only works smoothly when the foundation is already solved. Without it, teams usually spend months rediscovering the same problems: how to split modules properly, how to avoid over-sharing logic, and how to keep iOS and Android teams aligned without friction.

Why Most Teams Stall Mid-Migration and How to Avoid It

Even in organizations that are fully convinced by Kotlin Multiplatform production apps and have already made the strategic decision to adopt it, the real failure point rarely happens at the level of technology selection.

Most enterprise teams don’t start with full adoption, but begin with incremental integration patterns that reduce risk before scaling. We’ve done Kotlin Multiplatform Integration Without Full Migration many times so far.

The most common bottleneck for teams is not Kotlin itself, but the lack of experienced engineers who have actually worked through Kotlin Multiplatform enterprise adoption at production level, especially in environments where iOS constraints, CI complexity, and modular architecture decisions all intersect.

Teams often start strong with a proof of concept, but as soon as they try to expand beyond a single module, they run into structural questions that don’t have obvious answers: how much logic should actually be shared, where platform divergence is justified, how to design module boundaries that won’t collapse under future features, and how to avoid creating a “shared monolith” that becomes harder to maintain than the original duplication it replaced.

Without senior-level guidance, these decisions tend to accumulate technical debt faster than they remove it.

Conclusion

If you step back, the fact that KMP apps doubled in a year is about a set of real engineering constraints finally being resolved.

So, from my perspective as someone who’s had to make actual architectural calls in production environments, the answer is yes. Kotlin Multiplatform is production-ready for enterprise use, but only if you stop thinking about it as a replacement for native development. That’s not what it is, and that’s not where it creates value.

Where it does work, consistently, is in the parts of the system where duplication is already becoming a liability: shared business logic, networking layers, state management, and selectively UI through Compose Multiplatform when the product constraints allow it.

The real decision point is execution, since most failed migrations fail because teams underestimate the architectural discipline and senior-level experience required to apply it correctly across iOS and Android without slowing delivery down.

If a team doesn’t already have people who’ve done this at scale, they often decide to hire KMP developers who have already solved these patterns in real production systems.

So, in case you read this blog and are evaluating Kotlin Multiplatform for an existing system or planning a migration, our KMP developers are experts there. Contact us and we can discuss it in more detail.

If you don’t need engineers right now, that’s completely fine. We can always stay in touch on LinkedIn for future needs and tech conversations.