Kotlin Multiplatform for iOS: Myths about integration, performance, and workflow
If you've spent years developing iOS apps, you might be wondering: Will performance suffer with Kotlin Multiplatform? Am I giving up Swift's power and elegance? Will the developer experience feel like a second-class workaround? These are the questions most experienced iOS engineers ask when KMP comes into play.
This article breaks down the most common concerns iOS developers have about Kotlin Multiplatform, based on real-world usage, so you get a practical insight into what Kotlin Multiplatform iOS development actually feels like.
What Kotlin Multiplatform means for iOS developers
Kotlin Multiplatform is a technology that allows you to share as much or as little code as it makes sense to do – from a single module to most of your business logic, and even UIs with Compose Multiplatform, when appropriate.
It's not an attempt to replace native development. Instead, KMP lets you share code across platforms while maintaining complete control over what stays native.
At the highest level, KMP enables teams to:
Share business logic seamlessly.
Make Kotlin code callable from Swift.
Use the full power of iOS APIs in Kotlin code.
Use Compose Multiplatform to create screens that can be embedded in SwiftUI, or build the entire user interface in Kotlin.
Use platform-specific frameworks like MapKit or AVFoundation straight from your Kotlin code.
Is KMP merely another cross-platform abstraction layer?
It's not – KMP doesn't replace SwiftUI or UIKit. Instead, it complements native development.
In practice, this means you can:
Create UI in SwiftUI or UIKit, leveraging native Swift code.
Have direct access to iOS APIs without wrappers or indirection.
Integrate shared code wherever it adds value, not everywhere by default.
Is KMP genuinely useful for iOS developers?
While KMP is part of the Kotlin ecosystem, it's not limited to Android – it's a general-purpose approach to sharing functionality across platforms that iOS teams can use on their own terms.
It's especially useful for teams that face duplicated logic, inconsistent behavior across platforms, and escalating maintenance costs. Using a shared layer can eliminate duplication while maintaining complete native control.
The core principle is simple:
Share what makes sense, such as business logic, data, and networking.
Keep native what needs to be, like platform-specific features, and choose per-project whether the UI is shared or native.
Adjust that balance over time as needed.
Kotlin Multiplatform isn't an Android-centric solution; it's a versatile technology that helps development teams increase consistency without losing the native experience.
KMP is often surrounded by myths about performance, complexity, and loss of native control that don't accurately reflect how it works in practice. Let's break them down with experience-based answers.
Myth: Cross-platform frameworks compromise iOS performance and experience
A common concern is that Kotlin Multiplatform will hurt an iOS app's performance or experience. That assumption is often based on prior experience with frameworks that use bridges or proprietary runtimes, such as React Native.
KMP operates differently. It generates shared code for iOS with LLVM, the same toolchain family as Swift. There's no JavaScript bridge, no integrated runtime layer, and no abstraction between your code and iOS. This means your app continues to function as a fully native binary, with performance characteristics consistent with typical iOS development.
Myth: Kotlin Multiplatform is a niche or risky technology
You might still associate Kotlin Multiplatform with its early experimental days. However, Kotlin Multiplatform officially reached Stable status in November 2023 and is production-ready across all supported platforms. KMP is already used in real-world, large-scale iOS applications by well-known companies such as Google, Duolingo, Booking.com, Sony, Philips, and McDonald's.
The ecosystem has continued to mature as well: Compose Multiplatform for iOS reached Stable status in 2025, making it possible to build production-ready shared UIs in addition to shared business logic. According to the Kotlin Multiplatform Survey 2025, KMP is now seen as production-viable, with ~70% of plugin users satisfied or very satisfied, and ~80% using Compose Multiplatform.
Explore real-world KMP use cases
KMP is supported by JetBrains, the developers of Kotlin. It's not a side project but a strategic investment that will continue to evolve with robust tooling, regular updates, and growing ecosystem support.
So, is it safe to adopt KMP?
KMP has been battle-tested in production across a wide range of industries, including fintech, e-commerce, and mobility, as well as sectors like healthcare, media and entertainment, travel, and logistics. It's actively maintained and upgraded. On top of that, it enables progressive adoption, reducing risk.
Most importantly:
You're never locked in, and you can scale usage up or down.
Your iOS app remains fully native even if you stop using shared code.
Kotlin Multiplatform is a mature, production-ready solution that teams are currently using to tackle real-world cross-platform challenges without risking their entire architecture.
Myth: Kotlin Multiplatform is only for Android developers
Kotlin Multiplatform is often perceived as "Android-first", with iOS developers just along for the ride.
Kotlin is a general-purpose language, and shared code in KMP is simply another aspect of the codebase, not something owned by a single platform. iOS developers can read and contribute to it, shape APIs, and impact cross-platform design.
In practice, teams adopt different models. Many iOS developers continue working primarily in Swift, especially on UI-heavy features, while shared business logic is developed collaboratively or by engineers focused on cross-platform code.
This leads to better collaboration: Teams share ownership of logic, reduce inconsistencies, and fix issues once instead of duplicating effort.
Will you be sidelined as an iOS developer?
KMP doesn't demote iOS engineers; it expands their role into a shared layer, where they have equal impact while maintaining ownership of the native experience. iOS UI can remain native if you choose, Swift remains essential, and iOS developers retain control over platform decisions.
Myth: My iOS workflow will become more complicated
One of the main concerns about KMP is that it may disturb an established iOS workflow. If you've already gone through shifts like Objective-C → Swift → SwiftUI and ongoing toolchain changes, the idea of adding "one more thing" can feel exhausting. This concern is valid, which is why Kotlin Multiplatform is designed to be adopted incrementally rather than all at once.
You don't have to embrace a completely new toolchain overnight. For many iOS developers, KMP can start by just consuming a shared module. This means that your day-to-day workflow can remain relatively unaffected as you assess its usefulness.
As you go deeper, the learning curve is gradual – not all-or-nothing:
Begin by using shared Kotlin APIs.
Understand enough Kotlin to read and troubleshoot shared code.
Contribute to shared logic whenever it makes sense.
Will adopting KMP slow you down?
There is some initial overhead in understanding the configuration. But using shared logic and avoiding parallel implementations saves time, and tooling is lighter than you expect:
There's no need to replace Xcode as your primary environment.
There is no required move to foreign UI frameworks.
The complexity of the build sequence is typically managed outside your main iOS workflow.
You can continue to create iOS apps in the same way that you always have. KMP just adds a shared layer to it, providing you with additional freedom without demanding a full reset.
Myth: Kotlin Multiplatform produces non-idiomatic Swift APIs
Swift interoperability in Kotlin Multiplatform remains a relevant concern. For now, Kotlin code is presented to iOS via an Objective-C bridge, which can make Swift APIs feel less natural, particularly in naming, nullability, generics, or async patterns.
Yes, it can feel unlike Swift if not managed properly. However, good Swift APIs are possible when shared code is developed with iOS in mind. Here are a few best practices:
Keep the APIs simple and intentional.
Avoid Kotlin patterns that do not translate properly.
Add thin Swift wrappers as needed.
Validate APIs directly in Xcode.
You can also watch a recording of the talk "Kotlin Multiplatform Alchemy: Making Gold out of Your Swift Interop".
Kotlin's newer tooling – specifically Swift Export – is moving toward a future where Kotlin APIs integrate more directly and idiomatically with Swift, reducing friction even further.
Swift Export aims to remove the Objective-C layer, while Interopedia serves as practical documentation, helping developers understand how Kotlin code is exposed to Swift and what patterns to expect. Libraries like KMP-NativeCoroutines and SKIE go a step further by smoothing over rough edges in the current interop model, improving how coroutines map to Swift's async/await, and making generated APIs more Swift-friendly.
Myth: Sharing UI means losing native iOS experience
A prevalent misperception is that using Kotlin Multiplatform requires giving up a fully native iOS UI. It doesn't.
KMP doesn't require a shared UI at all. You can share only the underlying functionality and keep the rest native:
The UI can be written in SwiftUI or UIKit, leveraging native Swift code.
Animations and interactions can stay completely native.
Platform APIs are accessed directly and without wrappers.
So, will your app no longer feel like an iOS app?
No, because there is no need to abandon the native UI.
Do you have to use a shared UI?
This strategy is fully optional and defined by each team. The main premise is simple: Kotlin Multiplatform doesn't restrict how you design your interface. You can keep a fully native UI with SwiftUI or UIKit, introduce a shared UI with Compose Multiplatform, or combine both approaches depending on your needs.
Your most frequently used screens – like dashboards and core product flows – are often better implemented with fully native UIs, where you can squeeze out maximum performance and platform-specific polish. For lower-impact areas, Compose Multiplatform is a strong fit. Screens such as settings pages or infrequent flows like authentication are ideal candidates for a shared Compose UI, where development speed and code reuse outweigh the need for deep native optimization.
Importantly, there's interoperability between Compose Multiplatform and traditional iOS UIs, meaning you can embed shared components alongside native views or gradually adopt them over time. This allows teams to evolve their UI strategy without committing to a single approach upfront.
Myth: Adopting Kotlin Multiplatform means no more Swift
A common fear is that introducing Kotlin Multiplatform will render Swift obsolete. But KMP isn't here to replace it – Swift remains essential for iOS development.
You continue to code Swift for everything that makes an iOS app feel like iOS:
UI using SwiftUI or UIKit.
Navigation, animations, and user interactions.
Platform-specific features and integrations.
App lifetime and system APIs.
KMP simply adds a shared layer next to it. This means iOS developers continue to own the native experience, shared business logic is often a joint effort across platforms, and some iOS engineers contribute to Kotlin code, while others primarily focus on Swift.
So, will you stop writing Swift?
No, you'll still spend the majority of your time on it. And your role will expand as you gain new insights into cross-platform logic and influence on shared architecture decisions.
Kotlin Multiplatform iOS integration in an existing project
The best way to approach Kotlin Multiplatform iOS integration in an existing app is to start small. You don't have to reinvent the app, restructure everything, or commit to a full cross-platform approach on day one.
In reality, the shared module is usually given to iOS as:
A framework created from the common code.
An XCFramework for deployment among build targets.
Depending on the team's workflow, a dependency may be integrated using the Swift Package Manager, or a bespoke setup.
The key point is that integration is not inherently invasive. You’re not replacing your app's architecture, UI layer, or existing Swift code. You're creating a shared module that your iOS code can use anywhere it makes sense.
That's why a practical beginning point is typically a small, low-risk area such as:
Data models
Validation logic
Networking
Single feature module
This allows the team to see how KMP fits into the codebase while preserving the original iOS experience. Most teams opt for gradual adoption: They introduce common code to tackle a specific problem, and then expand only if the benefits are real. This makes ownership easy to maintain.
How do you start safely with KMP?
Choose one isolated problem, keep the scope restricted, and regard KMP as an addition to the project rather than a reset.
Get started with Kotlin Multiplatform
When Kotlin Multiplatform makes sense (and when it doesn't)
Kotlin Multiplatform makes sense when there is a overlap between iOS and Android logic, and this duplication is beginning to bite. It's especially valuable for teams that want to maintain a native iOS experience while sharing business rules, networking, data processing, or domain logic across platforms.
KMP is usually a good match when:
iOS and Android apps use the same underlying product logic.
Teams solve the same bugs twice.
Platform behavior continues to slip out of sync.
It might be a poor fit when:
The application is highly platform-specific.
The majority of the complexity lives in the UI layer.
There is insufficient logic to justify the additional setup and coordination.
Conclusion
Using KMP, you reduce duplication while adding a shared layer to maintain. You achieve consistency while introducing cross-team coordination and maintain native UI, but accept some interoperability and tooling complexity.
Kotlin Multiplatform works best when the shared code delivers clear value – whether that's a small, focused piece of logic or a larger domain layer – without overreaching into areas better handled by the platform.
Frequently asked questions
- How much code can realistically be shared between Android and iOS?
There is no set percentage; most teams share business logic, networking, and data layers. The exact amount depends on your app and the level of overlap between platforms. In some cases, teams also choose to share parts of the UI using Compose Multiplatform – while still achieving a native look and feel on iOS or combining it seamlessly with SwiftUI or UIKit.
- Does Kotlin Multiplatform affect iOS app performance?
There is no intrinsic impact. Shared code is compiled natively, so performance is comparable to typical iOS code – problems emerge solely from how the code is written, not from KMP itself.
How much code can realistically be shared between Android and iOS?
There is no set percentage; most teams share business logic, networking, and data layers. The exact amount depends on your app and the level of overlap between platforms. Kotlin Multiplatform with Compose Multiplatform allows you to share up to 100% of your app code, including UI, while still integrating with native APIs.
Does Kotlin Multiplatform affect iOS app performance?
There is no intrinsic impact. Shared code is compiled natively, so performance is comparable to typical iOS code.
How does Kotlin Multiplatform work with Swift?
Shared Kotlin code is turned into a native framework that Swift can use. In the current model, interoperability relies on an Objective-C bridge, which can introduce some friction. Looking ahead, this is evolving: JetBrains' Swift Export aims to remove the Objective-C layer entirely, enabling more direct, idiomatic integration with Swift.
Do iOS developers need to learn Kotlin to use KMP?
Not necessarily. You can begin by consuming shared Kotlin code and then gradually learning Kotlin as needed for debugging or contributing.
Do I have to share UI with Kotlin Multiplatform?
No, UI sharing is optional. Many teams keep the iOS UI completely native and simply share underlying functionality. But more and more companies choose to share UI code since the result feels native on iOS.