One Codebase, Two Platforms: What Kotlin Multiplatform Actually Shares

Cross-platform mobile has a long history of overpromising. The pitch is always the same — write once, ship to iOS and Android, halve the cost — and the result is frequently an application that feels slightly wrong on both platforms and is harder to debug than either would have been alone.

Kotlin Multiplatform makes a smaller claim, and the smaller claim turns out to be the useful one: share the business logic, write the interface natively on each platform.

Having built a fintech application this way, the distinction matters more than it sounds.

The logic is where the duplication hurts

In a typical financial application, the interface is a modest share of the work. The rest is validation rules, transaction state machines, interest and fee calculation, retry and idempotency handling, encryption, session management, and the mapping between API responses and what the screen needs.

Written twice, that logic is not merely double the effort. It is double the surface for the two implementations to disagree — and in a financial application, a rounding difference or a divergent validation rule between iOS and Android is not a cosmetic bug. It is a defect that produces different numbers for different customers.

Sharing that layer removes an entire category of problem. There is one implementation of the rule, one set of tests for it, and no possibility of the platforms drifting apart.

Keeping the UI native is the point

The temptation is to keep going and share the interface too. Resisting that is what makes the approach work.

Platform conventions are not decoration. Navigation, gestures, keyboard behaviour, accessibility integration, biometric prompts and system dialogues all differ, and users notice when an application ignores them — usually without being able to say why it feels off. In finance, where the application is asking for trust before it asks for money, feeling slightly wrong is expensive.

Native interfaces also stay current. When a platform changes its design language or adds a capability, a native layer adopts it immediately, while a shared abstraction waits for someone to expose it.

What it costs

It is not free, and the honest accounting matters.

The build setup is more complex than a single-platform project, and the tooling assumes more knowledge. Expect this to be slower than a native project for the first few weeks.

You need both platforms' expertise anyway. This does not turn an Android team into a team that ships iOS. It removes duplicated logic; it does not remove the need for someone who understands each platform.

Some libraries have no multiplatform equivalent, which means writing the expect/actual layer yourself. Usually straightforward, occasionally the reason a dependency choice changes.

Debugging crosses a boundary. A problem can be in shared code, in the platform layer, or in the interface between them, and the tooling for that boundary is not as mature as within a single platform.

When it is the right choice

The heuristic that has held up: the more logic relative to interface, the better the fit.

A financial application, a synchronisation-heavy product, anything with substantial offline behaviour or complex domain rules — these are strong candidates, because the shared layer is the bulk of the work and the correctness benefit is real.

A largely presentational application with a thin API layer is a weaker case. There the interface is most of the work, that part is not shared, and the added build complexity buys comparatively little.

What we would tell a team starting now

Share the domain and data layers, not the presentation layer. Put the shared code under test properly — it is the part that carries the correctness argument, and it is the easiest layer in a mobile application to test well. Do not use this as a reason to have fewer platform specialists. And decide the fit from the ratio of logic to interface, rather than from the promise of writing something once.

---

iLeaf has shipped Kotlin Multiplatform in production, including for fintech — see the case studies and Financial Services.