The Kotlin Multiplatform business case, for the person who signs off

Kotlin Multiplatform (KMP) is worth funding when your Android and iOS apps implement the same business rules twice and the two copies drift apart. It lets you write that logic once in Kotlin and ship it inside both native apps, while each platform keeps its own UI where you want it to. The published results are real but uneven. Bitkey shares about 95% of its app's code, Forbes over 80% of its logic, and OpenSooq between 91% and 98% within the modules it chose to share. None of them rewrote their app to get there. The core technology has been Stable since November 2023. The part still marked Alpha, Swift export, affects how pleasant the iOS side is to work with, not whether you can ship.

This post is for the person who has to approve the spend, not the person who writes the Gradle files. It covers what you are paying for today, what other companies have published, what is still risky, how to spend the money without stopping releases, what to measure, and when not to do it. Every figure links to the company or vendor that published it, and every status was checked against its source on 4 November 2026. The developer-level detail is in the dated status table and in what changes for the iOS team.

What you are paying for twice

Most mobile organisations run two teams that build the same feature in two languages. The screens differ, but much of the work does not: the API client, the data models, the validation rules, the pricing or eligibility logic, the analytics events, the offline cache. Each of those is written, reviewed, tested and fixed twice.

The cost is not only the second implementation. When two teams implement one specification, the copies drift. Booking.com's engineering team described exactly this with their in-house experimentation library, which ran as separate Android and iOS codebases. In their June 2026 write-up, they say the risk "isn't a technical failure like a crash, but rather the erosion of data quality leading to incorrect product decisions": Android and iOS users were assigned to experiments by slightly different rules, so the results could not be compared.

That is the business case in one example. KMP does not make your engineers type faster. It removes a class of work that should only exist once, and a class of bug that only exists because it was done twice.

What companies have published

These are the figures companies have stated themselves, with the date of each statement. They are not a forecast for your app. Each company chose what to share, and the percentages measure different things.

Company	What they shared	Published figure	Source
Bitkey (Block)	Logic, then UI with Compose Multiplatform	"about 95% of our app's codebase"	Block engineering, 12 May 2025
OpenSooq	Analytics, search, filters, chat and statistics modules	91.1% to 98.2% shared within each of those five modules	OpenSooq, 27 Jan 2026
Forbes	Business logic	"over 80% of logic", features released on both platforms at once	JetBrains case studies, summarising Forbes, 13 Nov 2023
Booking.com	One shared library (experimentation)	iOS startup improved after the old library was removed	Booking.com, 5 Jun 2026
Philo	Business logic for mobile, TV and web clients	In production for three years	Philo, 16 Jul 2026

Two details in those posts matter more than the headline percentages.

OpenSooq is careful to say its percentages "refer to KMP module code only, not the entire app codebase". Its Android app is about 1.4 million lines and its iOS app about 362,000. Sharing 95% of a 5,000-line filter module is a different claim from sharing 95% of an app. Ask for that distinction whenever someone quotes you a number, including us.

Bitkey's 95% includes the UI, because it later moved its screens to Compose Multiplatform. Forbes' 80% is logic only. Both are valid. They answer different questions.

The most widely quoted ranges come from Touchlab, a KMP consultancy, in a post on the JetBrains blog from April 2026, Helping Decision-Makers Say Yes to KMP. It lists 40–60% less code, 15–30% faster release cycles and 40–60% fewer bugs, among others. Its own footnote says the figures "were derived from proprietary and public data gathered from Touchlab clients and community case studies" and that "actual results may vary". Treat them as the upper end of what a specialist firm has seen, not a baseline. The same post reports, citing Duolingo, that its Adventures feature took nine months on Android, five engineer-months to adopt KMP and ship on iOS, and one and a half engineer-months to ship on the web from the same code.

What is still risky, dated

The decision depends on which parts are finished. JetBrains publishes stability levels with exact meanings: Stable means "use it even in most conservative scenarios", and Alpha means "use at your own risk, expect migration issues" (stability page, modified 10 September 2025).

Part	Status on 4 Nov 2026	Source
Sharing code on Android and iOS	Stable since 1 Nov 2023	JetBrains blog, stability page
Google support for sharing business logic	Official; "stable and production-ready"	Android Developers
Shared UI with Compose Multiplatform on iOS	Stable	Stability page
Web through Kotlin/Wasm	Beta	Stability page
Swift export, the cleaner way for Swift to call Kotlin	Alpha; "breaking changes are expected"	Swift export docs, modified 28 Aug 2026

The current Kotlin release is 2.4.21, released on 8 October 2026, and the 2.4 line is supported until 3 December 2027 (releases page). Google's KMP page lists Room, DataStore, Lifecycle, ViewModel, Paging and Navigation among the Jetpack libraries that already ship for iOS, so the persistence and state libraries an Android team already uses are available on iOS too.

Two risks are not on any status page.

• The iOS team's daily tools. In October 2026 JetBrains discontinued Swift language support in the KMP IDE plugin, saying most iOS developers on KMP projects prefer Xcode anyway. Running and debugging Kotlin on iOS stays supported. In practice, your iOS engineers stay in Xcode, and Booking.com notes that Xcode has no native Kotlin syntax highlighting, navigation or autocomplete. Plan for that rather than discovering it.
• A new layer in the organisation. Philo, three years in, writes that its KMP team "adds a layer of engineering operational complexity, sitting between backend server teams and frontend client teams", which can slow delivery if the work runs one step after another. They solved it by agreeing API contracts early and shipping the shared library with fake data, so client teams could start before the backend was finished.

How to spend the money without a rewrite

The companies above did not stop shipping to adopt KMP. Their posts describe the same pattern.

1. Pick one module with real duplication and no UI. Booking.com started with one library. OpenSooq started with analytics. Bolt, according to JetBrains' case-study page, started with a chat reconnect feature before moving the whole chat engine.
2. Write down the exit before you start. Booking.com's iOS team wrote an evaluation covering binary size, startup time, debugging and crash symbolication, with a clear "exit ramp": if KMP failed, the library would be rebuilt in Swift. That removed the sunk-cost argument from the decision, and when KMP passed, the iOS team supported it because they had set the bar.
3. Run old and new side by side. Booking.com shipped both implementations behind experiment flags and compared their output before switching. They measured the cost of doing so: during the overlap, iOS startup was about 140 ms slower at the 90th percentile and the download about 2.5 MB larger. Both were accepted, and startup improved once the old library was removed.
4. Widen only after the first module pays. Bitkey shared logic first and moved its UI to Compose Multiplatform later, once the logic was settled. Each step is a separate decision with its own evidence.

The pilot is small enough to fund from an existing roadmap. That is the main financial difference from the cross-platform rewrites many teams remember.

What changes in the team

The effect on staffing shows up in every account, though no two companies describe it the same way.

• OpenSooq runs six mobile engineers, three on each platform, with two Android engineers and one iOS engineer contributing to the shared code. It says it "recalibrated our hiring plan and reduced the projected mobile hiring ramp".
• Bitkey, which grew from two mobile engineers to about a dozen, writes that "when estimating work, there's no need to consider the capacity or development velocity of each platform, because it's essentially one platform."
• At Booking.com, iOS engineers became contributors to the shared Kotlin code, which they had not been to either native library before.

The Android team usually owns the shared code, because it is written in their language. Decide early who reviews changes to it, how it is versioned, and how the iOS team receives it. Philo had to split its library into independently versioned feature modules after one team's update forced every other team to absorb unrelated breaking changes.

What to measure in the pilot

Agree these before the pilot starts, so the decision to widen is made on numbers and not on enthusiasm.

• Duplicate work removed: the features or fixes in the module that would otherwise have been built twice during the pilot.
• Platform drift: bugs or analytics differences that existed only on one platform. Bitkey reports finding several when it moved its UI to shared code.
• iOS cost: app download size and startup time at the 90th percentile, measured with and without the module, as Booking.com did.
• Release lag: the number of days between a feature shipping on one platform and the other.
• iOS team sentiment: whether the iOS engineers would choose to continue. If they would not, adoption will be resisted at the next stage.

When not to choose KMP

KMP is the wrong choice in some situations, and saying so is part of the business case.

• When there is little logic to share. An app that is mostly screens over a thin API has little to deduplicate. The savings come from shared rules, not from shared buttons.
• When there is no Kotlin skill in the team. The shared code is Kotlin, and in every account above the Android team carries it. A team that is iOS-only today would be adopting a new language as well as a new architecture.
• When the main target is the web. Kotlin/Wasm and Compose for web are Beta. If the browser matters more to you than the phone, the Stable parts of KMP do not yet cover what you need most.
• When the iOS team is against it and nobody owns the conversation. Booking.com's success started with an iOS engineer writing the evaluation. A decision imposed on the iOS team tends to be undone later.
• When you need Swift export to be finished. If your iOS architecture depends on Kotlin coroutines reaching Swift as async without wrapper libraries, wait. That feature is Alpha.

Last checked

Every status, version, date and figure in this post was checked against its linked source on 4 November 2026. Company figures are as each company published them, on the date shown, and describe their apps, not yours. If anything here disagrees with the page it links to, the linked page is correct.

Working with the studio

The decision is easier to make with your own codebase in front of you. The studio offers a fixed-price KMP Readiness Audit: five days for $2,500, ending in a written report and a migration plan for your app. It is the step before any of the above, done by the person who would do the work.

If you have already decided, the studio also takes on the Kotlin Multiplatform work itself, in your repository from the first commit, alongside the native apps you already ship.