# Kotlin Multiplatform on iOS: Share Logic, Keep Native UI

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-05-31, updated 2026-06-02. 4 min read.
> Source: https://vp0.com/blogs/kmp-ios-native-navigation-ui-clone

The KMP promise is share the brain, not the face: write your UI in SwiftUI so iOS feels native, and let Kotlin handle the logic underneath.

**TL;DR.** Kotlin Multiplatform (KMP) lets you share business logic across iOS and Android, but the right approach on iOS is to keep the UI native: build SwiftUI screens and navigation that call into the shared Kotlin code. Build the native navigation from a free VP0 design, follow iOS conventions (stacks, tabs, swipe-back), and call shared KMP logic underneath. Do not share the UI layer; that is what makes iOS feel like iOS.

Kotlin Multiplatform's real promise is sharing the brain, not the face: write your business logic once in Kotlin, and build the UI natively on each platform. The short answer: on iOS, build native SwiftUI screens and navigation from a free VP0 design that call into your shared Kotlin code, following iOS conventions (navigation stacks, tab bars, swipe-back), rather than sharing the UI. That is what makes an iOS app feel like iOS. Teams adopt KMP because it lets them share a large share of code, often more than [50%](https://kotlinlang.org/docs/multiplatform.html), while keeping platform-native interfaces.

## Share the logic, keep the navigation native

The temptation is to share UI too, but that is where cross-platform apps start feeling foreign. iOS users expect specific behavior: a navigation stack that pushes and pops with the swipe-back gesture, native tab bars, sheets and large titles, and platform animations. So build that navigation in SwiftUI, honoring the conventions, and have your screens call the shared Kotlin logic (networking, business rules, data) underneath. The shared layer does not know or care about the UI; it just provides the logic. The result is a genuinely native iOS feel with most of the code reused. The [Kotlin Multiplatform docs](https://kotlinlang.org/docs/multiplatform.html) describe this share-logic-not-UI approach.

## Build it from a free design

VP0 is a free iOS design library for AI builders. Pick navigation, list, and detail designs, copy their links, and have Cursor or Claude Code rebuild them in SwiftUI, using [NavigationStack](https://developer.apple.com/documentation/swiftui/navigationstack) and TabView so you inherit correct iOS behavior, then wire each screen to call your shared KMP module. Keep the boundary clean: SwiftUI for everything the user sees and touches, Kotlin for the logic behind it. Do not try to render a shared UI on iOS, it breaks the conventions users expect. Test the swipe-back gesture, deep links, and state restoration. Done well, the user never senses that any code is shared with another platform at all. Use your own brand. For the Android-flavored equivalent, see [Compose Multiplatform iOS UI look and feel](/blogs/compose-multiplatform-ios-ui-look-and-feel/), and for the AI build loop, see [how to build an iOS app with AI](/blogs/how-to-build-an-ios-app-with-ai/).

## KMP-on-iOS building blocks

Native UI over shared logic.

| Layer | Build it in | Why |
|---|---|---|
| Navigation | SwiftUI (NavigationStack, TabView) | Native conventions and gestures |
| Screens | SwiftUI | Look and feel like iOS |
| Business logic | Shared Kotlin (KMP) | Write once, reuse |
| Networking and data | Shared Kotlin | Consistent across platforms |
| Platform features | Native (Swift) | Camera, notifications, etc. |

## Common mistakes

The first mistake is sharing the UI layer, which makes iOS feel foreign and breaks conventions. The second is ignoring the swipe-back gesture and native navigation behavior. The third is leaking platform assumptions into the shared logic. The fourth is a messy boundary between SwiftUI and Kotlin. The fifth is treating KMP like a write-the-whole-app-once tool, when its strength is sharing logic. Keep the UI native and the logic shared.

## A worked example

Say you build a cross-platform app with KMP. On iOS, from VP0 designs, you build SwiftUI navigation with NavigationStack and a TabView, so push, pop, swipe-back, and tabs all behave natively. Each screen calls your shared Kotlin module for networking and business rules. The user gets a fully native iOS experience, with the swipe-back gesture and platform animations intact, while most of the logic is reused with Android. Your brand is your own. For a trendy layout style next, see [bento box UI mobile app inspiration](/blogs/bento-box-ui-mobile-app-inspiration/), and for an AI app builder, see [Rork UI library](/blogs/rork-ui-library/).

## Key takeaways

- KMP shares business logic across platforms; keep the UI native on iOS.
- Build SwiftUI navigation from a free VP0 design and call shared Kotlin underneath.
- Follow iOS conventions: NavigationStack, TabView, swipe-back, sheets.
- Keep a clean boundary, SwiftUI for the UI, Kotlin for the logic.
- Do not share the UI layer; that is what makes iOS feel native.

## Frequently asked questions

How do I use Kotlin Multiplatform on iOS? Share business logic in a Kotlin module, but build the UI natively: SwiftUI screens and navigation (NavigationStack, TabView) from a free VP0 design that call into the shared Kotlin code.

Should I share the UI with KMP? No. Sharing UI tends to break iOS conventions and feel foreign. Share the logic and build native SwiftUI on iOS so the app feels like iOS, with the swipe-back gesture and native behavior.

What should the shared Kotlin layer contain? Business logic, networking, data models, and rules, anything platform-agnostic. Keep platform-specific UI and features (camera, notifications) in the native layer.

Is it okay to learn from KMP example apps? Yes. Learn the share-logic-keep-UI-native pattern, but build your own SwiftUI navigation and brand. The pattern, not a specific app's code, is what matters.

## Frequently asked questions

### How do I use Kotlin Multiplatform on iOS?

Share business logic in a Kotlin module, but build the UI natively: SwiftUI screens and navigation (NavigationStack, TabView) from a free VP0 design that call into the shared Kotlin code.

### Should I share the UI with KMP?

No. Sharing UI tends to break iOS conventions and feel foreign. Share the logic and build native SwiftUI on iOS so the app feels like iOS, with the swipe-back gesture and native behavior.

### What should the shared Kotlin layer contain?

Business logic, networking, data models, and rules, anything platform-agnostic. Keep platform-specific UI and features (camera, notifications) in the native layer.

### Is it okay to learn from KMP example apps?

Yes. Learn the share-logic-keep-UI-native pattern, but build your own SwiftUI navigation and brand. The pattern, not a specific app's code, is what matters.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*