Kotlin Multiplatform on iOS: Share Logic, Keep Native UI

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%, 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 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 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, and for the AI build loop, see 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, and for an AI app builder, see 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.