Hello everyone! We are currently developing a KMP...

# multiplatform

[François-Xavier Beuvry]

Hello everyone!

We are currently developing a KMP library targeting both Android and iOS, with @Aurélien L.M.

Our main challenge is with the data type mapping for iOS.
• When exposing integer types from common Kotlin code to the iOS side, they are mapped to the standard Objective-C types (e.g., Int16, Int32, Int64, etc.).
• However, the iOS developers in my company are primarily using Swift, and they strongly prefer to use the standard Swift Int (which, on modern 64-bit architectures, is effectively a 64-bit integer, Int64).
They are reluctant to deal with the specific Objective-C-derived integer types (Int32, Int64, etc.) as it breaks Swift idiomatic usage and requires constant casting.
I initially suggested exposing the numbers as NSNumber, but this was also rejected for similar reasons (non-idiomatic Swift).

My question is: Is there an established, idiomatic way (a KMP feature, a specific wrapper, a build setting, or a best practice) to make KMP expose Kotlin integer types (especially Int and Long) in a way that maps directly to the standard Swift Int type, or at least something closer to it than the current Obj-C derived types?

I suspect this question has come up before, but I haven't been able to find a clear solution or discussion thread. Any advice or pointer would be greatly appreciated!

Thanks!

[Skash]

Unfortunately, no—there is no build setting to force this.
Kotlin Int is fixed (32-bit), while Swift Int is dynamic (usually 64-bit). Auto-mapping them would risk crashes or data loss if you passed a large Swift integer back into Kotlin. The compiler enforces Int32 for safety.
The standard approach is to add a small Swift extension to reduce the casting noise.

extension Int32 { 
     var int: Int { Int(self) } 
}

Id suggest checking out SKIE if you have other problems on the Swift side. SKIE makes it wayyy better to work with concepts like sealed classes, flows and so on.

[Elijah Semyonov]

Swift Int is not dynamic, it’s the word size of the target architecture, which is Int64 for all supported iOS platforms. Swift indeed will crash if Int is narrowed during the conversion (e.g.: Int32(Int.max)), so this is by design to avoid confusion with <http://Kotlin.Int|Kotlin.Int> which is Swift.Int32

[Elijah Semyonov]

See https://youtrack.jetbrains.com/issue/KT-72371/K-N-Kotlin-Int-converted-to-Int32-in-objc-swift

[ephemient]

which is Int64 for all supported iOS platforms

afaik there are still supported watch devices with 32-bit int and pointers