Emma Schmidt

Posted on Apr 24

Kotlin Multiplatform vs. Native: Choosing the Right Skillset for Your Team

Introduction

The mobile development landscape has shifted dramatically over the past few years, and engineering leaders are under more pressure than ever to make smart technology decisions. Whether you are building a startup MVP or scaling an enterprise product, the framework you choose shapes not just your codebase but your entire hiring strategy. When businesses decide to **[Hire Android App Developers](https://www.zignuts.com/hire-android-app-developers?utm_source=seo&utm_medium=backlinks&utm_campaign=seo_referral&utm_id=4

)**, one of the first questions that surfaces is whether to go with Kotlin Multiplatform (KMP) or stick with platform-native development. This decision is not just technical. It is deeply tied to team structure, budget, long-term maintainability, and the kind of developer experience you want to cultivate. In this blog, we break down both approaches in detail so you can make a confident, informed decision for your team.

What Is Kotlin Multiplatform?

Kotlin Multiplatform is a technology developed by JetBrains that allows developers to share code across multiple platforms, including Android, iOS, web, and desktop, while still writing platform-specific code where necessary. Unlike Flutter or React Native, KMP does not impose a cross-platform UI framework. Instead, it focuses on sharing business logic, data models, networking layers, and other non-UI code, while allowing each platform to use its own native UI toolkit.

This is a significant distinction. With KMP, your Android team continues writing Jetpack Compose UI and your iOS team continues writing SwiftUI, but both teams share the same underlying logic layer written in Kotlin. The result is a hybrid approach that tries to get the best of both worlds.

As of 2024, Kotlin Multiplatform has reached stable status, and companies like Netflix, VMware, and Cash App have publicly shared their adoption stories. The ecosystem has matured considerably, and JetBrains continues to invest heavily in tooling, IDE support, and library compatibility.

What Is Native Development?

Native development means building separate applications for each platform using the tools and languages that the platform manufacturer recommends. For Android, that means Kotlin with Jetpack libraries. For iOS, that means Swift with UIKit or SwiftUI.

Native development gives you full access to every platform API the moment it is released. There is no waiting for third-party wrappers, no compatibility layers, and no abstraction overhead. Your app behaves exactly as the platform intends, and your developers work in the most well-documented, community-supported environment available for that platform.

Native also means specialization. An Android developer deeply skilled in Kotlin, Coroutines, Jetpack Compose, and Android architecture patterns is a very different hire from an iOS developer skilled in Swift, Combine, and SwiftUI. Both roles exist, both are necessary, and both carry distinct hiring and salary considerations.

The Core Difference: Shared Logic vs. Shared Everything

The most important conceptual difference between KMP and other cross-platform tools is scope. Frameworks like Flutter and React Native attempt to share everything, including the UI. KMP takes a more conservative approach by only sharing what makes sense to share.

Here is a rough breakdown of what typically gets shared in a KMP project:

Business logic (validation, calculations, state management)
Data models (domain entities, DTOs)
Networking (API clients using Ktor)
Database (SQLDelight for local storage)
Repository and use case layers

What stays platform-specific:

UI components (Compose for Android, SwiftUI for iOS)
Platform permissions (camera, location, notifications)
Platform-specific integrations (Google Pay, Apple Pay, push services)

This separation means KMP is not trying to replace your native developers. It is trying to reduce duplicated effort in the parts of your codebase that do not need to be duplicated.

Team Structure: How Each Approach Shapes Your Hiring

Native Team Structure

A native-first team typically looks like this:

2 to 4 Android developers
2 to 4 iOS developers
Shared backend and QA resources

Each sub-team works in parallel, building the same features twice in different languages. Communication overhead exists because both teams need to stay in sync on feature logic, even though they are writing that logic independently. Bug fixes often need to be applied twice. Business logic updates require coordination across two codebases.

The upside is simplicity of hiring. Android developer roles and iOS developer roles are well-defined in the job market. Candidates know what they are applying for, and the skills required are specific and testable.

KMP Team Structure

A KMP team typically looks like this:

1 to 2 Kotlin developers who own the shared module
1 to 2 Android developers who consume the shared module and build Android UI
1 to 2 iOS developers who integrate KMP via Swift and build iOS UI
Shared backend and QA resources

In this model, the Kotlin shared module becomes a product in itself. It has its own architecture, its own test suite, and its own release cadence. The iOS developers need to understand how to integrate a Kotlin framework into their Swift project, which requires some cross-platform fluency.

The challenge here is that finding developers who are comfortable working in this hybrid environment is harder than finding pure native developers. The KMP ecosystem is newer, documentation is less abundant on the iOS integration side, and candidates with real production KMP experience are fewer.

Skills Your Team Needs for KMP

If you decide to go with Kotlin Multiplatform, here are the skills your team should have or build toward:

On the Kotlin/Shared Module Side

Strong Kotlin fundamentals including coroutines, flows, and extension functions
Familiarity with Kotlin's expect/actual mechanism for platform-specific implementations
Experience with Ktor for networking
Experience with SQLDelight for cross-platform database access
Understanding of clean architecture and how to structure shared modules
Ability to write platform-agnostic unit tests using Kotlin Test

On the Android Side

Jetpack Compose
Kotlin coroutines and StateFlow
Dependency injection with Koin or Hilt (Koin is more KMP-friendly)
How to consume shared KMP modules and integrate them into Android ViewModels

On the iOS Side

Swift and SwiftUI fundamentals
How to add KMP as an XCFramework or via CocoaPods
Understanding of Kotlin/Native memory management and threading constraints
How to bridge Kotlin coroutines to Swift's async/await using SKIE or similar tools

The iOS side of KMP is where most teams encounter friction. The tooling has improved significantly, but your iOS developers still need to understand that they are consuming a Kotlin-compiled framework, which behaves slightly differently from a pure Swift library.

Skills Your Team Needs for Native Development

Native development has a clearer skill matrix because roles are more isolated.

Android Developers Need

Kotlin proficiency
Jetpack Compose or XML-based UI
MVVM or MVI architecture patterns
Jetpack libraries: Room, Navigation, WorkManager, DataStore
Dependency injection with Hilt or Koin
Coroutines and Flow for async operations
Unit and instrumentation testing

iOS Developers Need

Swift proficiency
SwiftUI or UIKit
Combine framework or async/await
Core Data or SwiftData for local storage
XCTest for unit and UI testing
App architecture: MVVM, TCA, or VIPER

Both skill sets are well-established, widely taught, and well-documented. The hiring market for these roles is mature, and there is a large pool of candidates with verifiable experience.

Performance Considerations

Performance is often cited as a concern with cross-platform frameworks. For KMP, this concern is largely overstated for the business logic layer.

Shared Kotlin code compiled for Android runs on the JVM, just like regular Android code, so there is no performance difference on that platform. On iOS, Kotlin code compiles to native machine code via Kotlin/Native, which means it does not run on the JVM at all. Instead, it is compiled ahead of time (AOT) into native binaries.

The performance characteristics of Kotlin/Native on iOS are generally good for business logic, but there are some nuances. Memory management in Kotlin/Native has historically been different from Swift, though JetBrains has made significant improvements with the new memory model introduced in Kotlin 1.7.20. Garbage collection behavior can sometimes cause latency spikes in performance-sensitive scenarios, so this is worth profiling if your app has heavy real-time requirements.

For UI performance, both KMP and native development use the same native UI toolkits, so there is no trade-off there. A SwiftUI view consuming a KMP ViewModel performs identically to one consuming a Swift ViewModel, from the rendering perspective.

Code Sharing: Real Numbers

Teams that have adopted KMP in production often report sharing somewhere between 40% and 70% of their codebase. The exact percentage depends heavily on how much of the app is UI versus logic.

For apps that are data-heavy and logic-heavy, such as fintech apps, health tracking apps, or productivity tools, code sharing percentages tend to be higher. For apps that are primarily UI-driven with simple data requirements, the benefit is smaller.

Here is a realistic breakdown for a typical mobile app:

Layer	Shareable with KMP
Domain models	Yes
Use cases / interactors	Yes
Repository interfaces	Yes
Networking (Ktor)	Yes
Local database (SQLDelight)	Yes
ViewModels / Presenters	Partially
UI components	No
Platform integrations	No

This table shows why KMP works well as a logic-sharing solution and why it does not try to compete with Flutter on the UI side.

When to Choose Kotlin Multiplatform

KMP makes the most sense in the following scenarios:

Your team is Android-first. If your Android team is strong and your iOS team is smaller, KMP allows your Android team's Kotlin expertise to contribute directly to iOS code quality through the shared module.

You have significant business logic. Applications with complex domain logic, state machines, or data transformation pipelines benefit the most from KMP. Sharing this logic eliminates the risk of behavioral divergence between platforms.

You want to reduce duplication without sacrificing native UI. If you have had bad experiences with fully cross-platform frameworks but still want some code sharing, KMP is the most pragmatic middle ground available.

You are building for multiple targets. KMP's roadmap includes strong support for web (via Kotlin/Wasm) and desktop. If your product roadmap involves expanding to these platforms, KMP gives you a head start on shared logic that can be reused across all of them.

You are willing to invest in tooling and integration. KMP requires initial setup effort, especially for iOS integration. Teams that are willing to invest in that setup and establish clear module boundaries early will see compounding returns over time.

When to Choose Native Development

Native development remains the better choice in the following scenarios:

Your teams are siloed by platform. If your Android and iOS teams operate independently with separate backlogs and roadmaps, the shared module ownership model of KMP may create coordination overhead rather than reduce it.

You need cutting-edge platform features immediately. Native development gives you day-zero access to new APIs. With KMP, you sometimes need to write platform-specific code and expose it through the expect/actual mechanism, which adds a layer of abstraction that can slow down adoption of new platform features.

Your hiring market is limited. In regions or company stages where hiring is difficult, it is easier to find a strong Android developer or a strong iOS developer than it is to find someone comfortable with KMP's iOS integration model. Choosing native lets you hire from a larger candidate pool.

Your app is heavily UI-driven. If most of your development time goes into building custom animations, complex gesture interactions, or highly platform-specific UI patterns, the benefits of KMP shrink because UI code is not shareable anyway.

Your team is iOS-first. KMP's tooling is significantly more mature on the Android/Kotlin side. iOS-first teams often find the integration story more painful than the benefit justifies, at least at this stage of the ecosystem's maturity.

Hiring Implications: What to Look for

Regardless of which approach you choose, hiring the right developers is what makes or breaks your technical decisions.

Hiring for a KMP Team

Look for candidates who demonstrate:

Curiosity about cross-platform tooling, not just platform expertise
Understanding of how to structure shared Kotlin modules
Exposure to Ktor, SQLDelight, or Koin in a real project
Willingness to work across Android and iOS integration concerns
Strong fundamentals in Kotlin, since the shared module is the heart of the app

On the iOS side, look for developers who are comfortable integrating third-party native frameworks and who understand the XCFramework and CocoaPods integration models.

Hiring for a Native Team

Look for deep platform expertise. Android candidates should demonstrate mastery of the Jetpack ecosystem, clean architecture patterns, and modern Kotlin idioms. iOS candidates should demonstrate fluency in Swift concurrency, SwiftUI, and Apple's Human Interface Guidelines.

In both cases, prioritize developers who write testable code and understand separation of concerns. These qualities matter more than any specific framework preference because frameworks change, but good architecture principles do not.

The Future of KMP

The trajectory of Kotlin Multiplatform is strongly positive. JetBrains released Compose Multiplatform as a separate project that extends Jetpack Compose to iOS, desktop, and web. This means teams that want to share UI code can now do so using Compose, while teams that prefer native UI can continue using KMP for logic sharing only.

Google has officially endorsed KMP as a recommended approach for sharing logic between Android and other platforms. This is a significant signal. Historically, Google's endorsement of a technology on Android has been followed by deep ecosystem investment, improved tooling, and accelerated library support.

The library ecosystem is also catching up. Major libraries like Ktor, SQLDelight, Kotlinx.serialization, and Koin are already fully KMP-compatible. Firebase recently added KMP support, which removes one of the biggest blockers for teams relying on the Firebase ecosystem. As more libraries add KMP support, the friction of adopting KMP continues to decrease.

Making the Decision: A Practical Framework

Use these questions to guide your team's decision:

What percentage of your app is business logic vs. UI? More logic means more KMP benefit.
How strong is your existing Kotlin expertise? If your Android team is senior and your iOS team is junior, KMP lets the Kotlin expertise lift both platforms.
What is your hiring plan for the next 12 months? If you plan to grow your iOS team significantly, native development keeps hiring simpler.
How mature is your testing culture? KMP's shared module is easier to maintain when it has strong unit test coverage. Teams that do not yet have a strong testing culture may struggle with shared module ownership.
What is your platform release cadence? Teams that need to ship platform-specific features on tight timelines may find native development simpler to manage.

Conclusion

Both Kotlin Multiplatform and native development are excellent choices, but they are excellent in different contexts. Native development offers simplicity, specialization, and immediate platform access. KMP offers efficiency, reduced duplication, and a pragmatic path toward sharing logic without sacrificing the native experience your users expect.

The right choice comes down to your team's existing skills, your product's logic complexity, and the kind of developer culture you want to build. Neither approach is universally superior. The teams that succeed with KMP are those that approach it thoughtfully, invest in tooling and module structure early, and hire for curiosity alongside platform expertise. The teams that succeed with native development are those that invest in strong communication between platform teams and build shared conventions that keep both codebases architecturally aligned.

Evaluate your context, be honest about your team's current capabilities, and choose the approach that sets you up for sustainable growth rather than the one that looks most impressive on a tech radar.

DEV Community