# 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-26007.md>)

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

Author: Paul Woitaschek

Published: 2021-11-19T07:21:13Z

Content type: tutorial

Language: en

Sources: [Stories by Paul Woitaschek on Medium](<https://devfeed.tech/sources/stories-by-paul-woitaschek-on-medium.md>)

Topics: [kotlin-native](<https://devfeed.tech/topics/kotlin-native.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Objective-C](<https://devfeed.tech/topics/objective-c.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Library](<https://devfeed.tech/topics/library.md>), [Tutorial](<https://devfeed.tech/topics/tutorial.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>), [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>), [tutorial](<https://devfeed.tech/tags/tutorial.md>)

## AI overview

This developer article explains how YAZIO uses Kotlin Native for shared business logic while addressing the limitations of exposing Kotlin types through Objective-C to Swift. It describes manually mapping the generated API to Swift and introduces KSP and SwiftPoet as tools for generating Swift mappings and reducing boilerplate.

## 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