Kotlin Multiplatform in Practice: Lessons from Real Projects

In our first article, we looked at when multiplatform makes strategic sense and when it does not, and how to think about the decision before writing a single line of code. 

‍

This one is more concrete. Four projects. Four different contexts. We have been involved as the architect, technology lead, and auditor. The situations differed. The reasons clients chose KMP were consistent.

The common threads in using KMP

• A single source of truth: Platform-specific inconsistencies were the primary pain point for both the e-commerce and automotive teams. One codebase for business logic means one place to change behaviour, one place to test it, one release to ship it.
• Market scalability without duplication: Launching across multiple European countries quickly is not viable if you are maintaining separate Android and iOS logic trees.
• Long-term TCO: Consolidating domain and data layers into a shared codebase reduces maintenance overhead over time. The savings compound rather than arrive immediately.

1. The cost of deferring the right architecture (E-commerce)

A mid-sized e-commerce platform came to us for an architectural review. The two mobile codebases had drifted apart over years of parallel development. Business rules were implemented separately on each platform. 

‍

When they changed, both had to be updated. When bugs appeared, they were often platform-specific, meaning the same problem diagnosed and fixed twice. Meanwhile, the gap between what the two platforms did grew slightly wider with each release cycle.

‍

Approach: We conducted an architectural analysis and outlined the TCO implications. For an app at this scale and stage, introducing a KMP shared layer for domain logic, business rules, and networking was well within reach: achievable incrementally, without a full rewrite, with immediate and compounding maintenance savings.

‍

Outcome: Flow team delivered a structured architectural analysis and a concrete migration roadmap. The client now has a clear understanding of the TCO implications and a defined path forward. The decision on timing is theirs. The preparation is done.

2. Validating KMP before committing to it (Automotive)

A major automotive manufacturer had a large, complex mobile application already in production, used by hundreds of thousands of drivers. The question on the table was whether KMP could be safely introduced into their specific ecosystem, and whether the business case would hold under scrutiny.

‍

Approach: We ran a Proof of Technology over three months. Two engineers rewrote apart of the codebase in KMP, focusing on the most complex shared logic: authentication, session management, vehicle telemetry, and remote command execution via MQTT. The goal was to prove feasibility in this client's actual environment, against their CI/CD constraints and compliance requirements. 

‍

KMP handled the shared logic well. It also surfaced real gaps: encrypted local storage has no off-the-shelf cross-platform solution at this scale, and Gradle module structures compound faster than most teams anticipate. Both solvable. Neither trivial.

‍

Outcome: The conclusion brought back to the client was technology and cost implications and a defensible answer to a board-level question: does KMP make sense for us, and if so, when and how? A well-informed decision reached in three months rather than discovering the same constraints a year into a migration that could stall. The client retained the architectural knowledge and the framework to decide when a full rollout makes sense.

3. Multiple markets, fixed deadline, one codebase (Sports Betting)

Merkur Bets entering the German market had a fixed deadline: live before Euro 2024. The product needed to support rapid rollout to other European countries without rebuilding core logic for each market.

‍

Maintaining separate Android and iOS codebases would have put the deadline at serious risk and created exactly the maintenance overhead the business needed to avoid as it scaled.

‍

Approach: We built the mobile apps using a KMP shared layer covering the business logic both platforms needed to run identically: authentication, registration, and account management. That shared layer represented around one third of the total codebase. The remaining two thirds were native: Jetpack Compose on Android, SwiftUI on iOS.

‍

Neither platform compromised on user experience. To keep multiple international parties aligned through a simultaneous discovery-and-build phase, Flow team introduced a proxy product owner role as a single point of technical and product accountability.

‍

Outcome: On-time launch in Germany and scaling across markets according to plan. Localisation and regulatory adaptation for each new country is now configuration, not lengthy development. That makes European expansion measurably cheaper and faster.

4. Optimising a live KMP app without a rewrite (Sports Betting)

A sports betting app was facing performance challenges under high load. Odds update in real time, users bet during live events. And lag at those moments costs conversions directly. The team had identified that something was wrong but needed targeted expertise to locate the root causes. A full rewrite was not an option with a live product and active users.

‍

Approach: We conducted a structured audit across the frontend, backend interactions, and shared KMP layer.

‍

The architecture was sound. The problems were specific implementation patterns that hold up under normal load and become expensive at scale: 

• unnecessary recompositions from shared state updates
• observable flows emitting more than needed
• heavy computations on the wrong dispatcher
• memory pressure from unmanaged lifecycle boundaries

None visible during development. All findable by engineers who know what to look for in a KMP context specifically.

‍

Outcome: A two-month optimisation roadmap delivered up to 70–80% reduction in CPU usage in high-load scenarios and brought customer satisfaction to 74%, all without a full rewrite or disruption to ongoing releases. The app did not need to be rebuilt. It needed targeted optimisation by engineers who understood the KMP context 

What we have learned across these projects

What works:

• Incremental migration layer by layer. A big-bang approach to introducing KMP into a live product rarely survives contact with a real codebase.
• Proof of Technology before full commitment. Three months of validation is far cheaper than twelve months of discovering the same problems mid-build.
• KMP for business logic, native UI without exception. Shared UI is a separate decision with its own trade-offs. The two should not be conflated.
• Structured audits when performance degrades. Most problems in mature KMP apps are localised and fixable. A rewrite is rarely the answer.

What creates problems:

• Deferring the architectural decision. The cost of introducing KMP into a drifting codebase compounds with every feature added to both platforms separately.
• Implementation patterns that look fine in development. Unnecessary recompositions, flows emitting more than needed, computations on the wrong dispatcher. None are visible until the app is under real load.
• Underestimating the iOS learning curve. KMP is built around the Kotlin ecosystem. iOS engineers need time and deliberate support to become productive contributors. Teams that skip this planning end up with a two-speed delivery model, with Android moving faster and iOS catching up.

What to do before committing:

• Validate KMP in your actual ecosystem. Test it against your CI/CD constraints, your compliance requirements, and your most complex shared logic. Generic benchmarks are not a substitute.
• Design shared APIs with Swift interop in mind from day one. Certain Kotlin patterns translate poorly across the boundary and the friction compounds once they are established across a large codebase.
• Run a TCO analysis before the migration starts. The long-term savings from implementing KMP are real but they do not arrive immediately. The business case for the technology change needs to be modelled, not assumed.

‍

If any of these situations looks familiar, get in touch. We are glad to bring an experienced outside perspective.