It is a strategic decision. Not about tools or frameworks, but about timing, ambition, and risk. Done well, shared architecture can speed things up and make products easier to scale. Done poorly, it can slow teams down and add unnecessary complexity.

‍

Multiplatform development itself is not new. What has changed is how far it has come. Kotlin Multiplatform is already proven in demanding production environments. Compose Multiplatform shows strong momentum, but we approach it selectively, with a clear understanding of its current limits.

‍

To understand when multiplatform makes sense and when it does not, it helps to look at two very different situations. Building a new app from scratch and evolving an existing native app over time.

Three ways to build a mobile app

The way you build your app affects everything. Speed, cost, team setup, and how easy the product will be to change later.

Fast validation with mobile web

The fastest way to get something into users’ hands is often a mobile web, a Progressive Web App (PWA), or a web app wrapped in a native shell. This approach works well for quick validation and early experiments.

‍

The limits are clear. Access to device features is restricted, performance is weaker, and the experience rarely matches that of a full native app. While PWAs have improved significantly, they still struggle to meet expectations for more complex, performance-critical products.

‍

For early-stage products or businesses testing ideas with minimal investment, this can still be a smart first step.

Maximum control with native development

Native development means building separate apps for Android and iOS. Separate codebases. Separate tooling. Often separate teams.

‍

You get top performance and full access to everything the platform offers. For mature products with complex requirements, this is still the gold standard.

‍

The tradeoff is cost and coordination. Development takes longer. Teams grow. Product increments must be carefully aligned across platforms.

Balance and scalability with multiplatform development

Multiplatform development tries to take the best from both worlds. Core logic is shared, which reduces duplication and speeds things up. Platform-specific layers stay native, so the app still feels right to users.

‍

For many companies, this strikes a good balance between speed, quality, and long-term scalability. But it is not a universal answer. The value depends on when and how it is used.

Multiplatform for new applications

When you are starting from scratch, multiplatform is at its strongest.

‍

From day one, teams can build Android and iOS in parallel. Business logic, networking, data handling, and domain models are written once and reused. That alone can save a lot of time and effort over the life of the product.

‍

At the same time, teams keep full control over platform-specific UI and integrations. The result is an app that feels native, but is much easier to maintain under the hood.

‍

For products with clear growth ambitions, this can be a very strong choice. Especially when speed, consistency, and long-term evolution matter. 

‍

Multiplatform is usually a good fit when:

• The product is expected to last for several years
• Android and iOS need to stay closely aligned
• Business logic changes often
• The product needs to scale through new variants, platforms, or regulatory requirements

These were exactly the factors behind the decision to use Kotlin Multiplatform as the foundation for the Merkur Bets application. The product needed to launch quickly, stay consistent across platforms, and remain flexible enough to evolve through frequent business changes and future scaling, without rebuilding core logic.

‍

There are also cases where multiplatform is usually the wrong choice:

• Very short-lived MVPs where speed matters more than maintainability
• Apps deeply tied to platform-specific UI or low-level system features
• Teams with no experience in shared architecture and no time to learn
• Products where one platform clearly dominates, and the other is secondary

Multiplatform in existing applications is a different story

Things change once you already have a native app in production.

‍

A common question we hear is whether it is possible to introduce Kotlin Multiplatform gradually, without rewriting everything. The short answer is yes. The real question is whether it is worth it.

‍

What matters most is not technical feasibility, but expected product lifetime. If the app continues to evolve for years, the investment often pays off. If not, it may not.

‍

In practice, teams usually start with the Android codebase, which is often already in Kotlin. Shared modules are extracted step by step. Most teams begin with lower layers like networking, storage, or domain logic. Sometimes, isolated features can be moved as well. We typically recommend the best strategy after reviewing the app and its codebase.

‍

At some point, iOS must join the picture. For iOS teams, this transition is rarely smooth. The mental model is different. Tooling changes. Refactoring is unavoidable.

It is also important to be honest about the early phase. Multiplatform often slows teams down at first. Developers may feel they would move faster without shared code. That feeling is normal.

‍

Over time, the picture changes. Shared data models mean changes happen once, not twice. Business logic lives in one place. New features behave more consistently across platforms.

‍

In many cases, evolving an existing app is safer than building a brand new version alongside the old one. It reduces the risk of feature gaps and keeps business functionality aligned.

Beyond technology: people, process, and cost

Technology is only part of the story. Team structure and development processes matter just as much, and in practice they are the most common reasons multiplatform initiatives fail.

‍

Android and iOS teams are often used to working independently. They use different terminology and slightly different architectural approaches. Shared code forces closer collaboration and some changes in how teams plan and deliver work.

‍

In the early phase, teams often feel slower than before. This is usually the moment when multiplatform is questioned the most. In our experience, this is also when good architectural decisions start paying off, if the foundation is solid.

‍

Planning needs to be clearer. Teams need to agree on what belongs in shared modules and what stays platform-specific. Communication becomes more important. Over time, friction decreases.

‍

We have seen this work well in long-running products, where multiplatform becomes a natural part of delivery rather than a limitation.

‍

One thing that is often underestimated is the long-term cost of change. In most mature products, the biggest expense is not building the first version. It is changing the app again and again.

‍

Regulatory updates, API changes, shifting business rules, and new markets all put constant pressure on development teams. With a well-designed multiplatform setup, many of these changes are implemented once instead of twice. This reduces inconsistencies, speeds up reaction time, and makes the system easier to evolve.

‍

In industries like BFSI, sports-betting, or other regulated environments, where change is constant, this ability often matters more than initial delivery speed.

From compromise to competitive advantage

Not long ago, multiplatform frameworks were seen as compromises. Today, tools like Kotlin Multiplatform, Compose Multiplatform and Flutter are mature enough to support complex, high-quality products.

‍

Multiplatform is not right for every project. But when applied with clear intent and realistic expectations, it can become a real competitive advantage.

‍

Whether you are starting fresh or evolving an existing app, the key is to step back and look at your goals, your architecture, and your teams before deciding.

‍

If you want an honest discussion about the tradeoffs for your specific situation, we are happy to help you think it through.