# Kotlin Native -- Using swift, not Objective-C

DevFeed: [Kotlin Native -- Using swift, not Objective-C](<https://devfeed.tech/articles/kotlin-native-using-swift-not-objective-c-24746.md>)

Original publisher: [Read original article](<https://medium.com/yazio-engineering/kotlin-native-using-swift-not-objective-c-d7742c040539?source=rss----65bd178b00af---4>)

Author: Paul Woitaschek

Published: 2021-11-19T08:00:42Z

Content type: tutorial

Language: en

Sources: [YAZIO Engineering - Medium](<https://devfeed.tech/sources/yazio-engineering-medium.md>)

Topics: [kotlin-native](<https://devfeed.tech/topics/kotlin-native.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Objective-C](<https://devfeed.tech/topics/objective-c.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [code-generation](<https://devfeed.tech/tags/code-generation.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [interop](<https://devfeed.tech/tags/interop.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [kotlin-native](<https://devfeed.tech/tags/kotlin-native.md>), [ksp](<https://devfeed.tech/tags/ksp.md>), [library](<https://devfeed.tech/tags/library.md>), [objective-c](<https://devfeed.tech/tags/objective-c.md>), [swift](<https://devfeed.tech/tags/swift.md>)

## AI overview

This tutorial explains how YAZIO uses Kotlin Native for shared business logic while providing a Swift-native iOS API. It describes the limitations of Kotlin-to-Objective-C interoperability and shows how KSP and SwiftPoet can generate Swift mappings for Kotlin types such as enums and sealed classes.

## Source excerpt

Kotlin Native -- Using Swift, not Objective-C At YAZIO we use Kotlin Native Extensively. The business logic of all new app features is exclusively written in Kotlin. In its core, every screen has one ViewModel which exposes a single Flow<ViewState> that the Android App and the iOS can consume to render the state. On Android, rendering the view state is no burden because it's the language we use in the Android App anyways. However this is different for iOS. While Swift does interop with Objective-C, the public API as seen from Swift is bad. A simple data class is exported as a regular class. The properties are not native Swift types. What should be a Bool becomes a KotlinBoolean. What should be come a Double becomes a KotlinDouble. But what we want is most of the times a struct with Swift types. These are the lesser evils, the greater ones are enums and sealed classes. In Objective-C, they both become regular classes. And therefore lose all the advantages they have when used from Swift. But what we want is a Swift enum. To overcome these restrictions for quite some time our iOS team has created mappings. There is a whole target, dedicated to mapping the Objective-C classes to Swift. Basically when developing a new feature, the whole public API is manually mapped to Swift. This is good because the result is a clean Swift-native API. But that's bad because it's extreme boilerplate and a real productivity killer. What if we could directly generate these mappings and use code generation to handle that for us? Turns out: There are two tools available that make it possible. The first one is KSP. It is basically a library that lets you implement a Kotlin compiler plugin and it gives you hooks to analyze the Kotlin Syntax Tree and generate code based on it. The second one is SwiftPoet. SwiftPoet is a library you can use to generate Swift code from Kotlin, similar to what KotlinPoet and JavaPoet do. Okay, let's get our handy dirty. For the basic setup, just follow the tutorial