Kotlin/Native v0.5 released: calling Kotlin from Swift and C, LLVM 5 and more

We’re happy to announce the release of Kotlin/Native v0.5, Christmas edition! This release adds support for using Kotlin/Native code from C, Objective-C and Swift, supports development using iOS simulator, along with LLVM 5 support and creating WebAssembly from Linux and Windows hosts.

Reverse interop from Objective-C and Swift

In the previous release of Kotlin/Native we introduced calling Apple frameworks from Kotlin/Native, assuming they provide Objective-C headers. Now we go another way around, and add support for calling Kotlin code from Swift and Objective-C. For that, a new compiler option, -produce framework, has been implemented. It generates a self-contained framework, which could be used from other parts of your application, as if it was written in Swift. Let’s take a look at the calculator example. It has UI written in Swift along with calculator logic written in Kotlin. Swift code intermixes with Kotlin transparently. For example, this line of Swift code:

Note, that basic types like numbers and strings are transparently mapped between Swift and Kotlin worlds.

To build the project, just open it in XCode and compile it for either a real device or the simulator, see the README.md for details.

And Kotlin code in IntelliJ IDEA:

Reverse interop from C

For other platforms we also support reverse interoperability, allowing to call Kotlin/Native code from the outside world. The lowest common denominator of modern languages is C, so this was the language we interoperate with. Compiler option -produce dynamic produces a dynamic library (such as .dylib on macOS, .so on Linux and .dll on Windows) containing everything needed to work with Kotlin/Native code. To make things fancy we decided to demonstrate this interoperability by creating Python extension. Python calls to C implementations and they call Kotlin implementation like this:

So long as your business logic is not tied to any platform-specific dependencies, for example your entire model layer using Realm and thus subclassing off of iOS/Android-specific subclasses… making the entire promise of shared business logic moot.

The world has tried going down this route before (hello, Xamarin?), little do we seem to learn.

tl;dr How do you deal with kotlin native code being called from different platform threads?

I did read in the comments of v0.4 release that object heaps are not shared between threads and explicit ownership has to be transferred. Now in v0.5 the calculator shows a framework implemented in Kotlin called from objc/swift, but there are no thread jumps involved. In the past I’ve tried to use a language with similar memory characteristics unsuccessfully in the following scenario:

Main UI thread calls framework method to initialise some globals. As such, these globals are attached to the UI thread.
User clicks a button to perform a long operation. iOS side shows a HUD, switches to a background thread and calls a framework method to do calculations. This method requires modifying previously initialised globals.

In this scenario, the global state initialised early is not accessible from the different background thread and the language crashed. How does kotlin/native work in this situation? Will the background thread crash in the kotlin code presuming to access those early globals/state?

Hi, this is very interesting. We are running Swift code on Android and use Kotlin to develop the JVM/Dalvik part. Is it possible to use this interop when the Kotlin code is not running “natively” itself? Or do we need to continue to use the JNI?

Kotlin will run natively in both cases, actually. On Android your Kotlin code will compile to Java bytecode, and then to DEX (https://source.android.com/devices/tech/dalvik/dex-format) and then will be executed by VM. On iOS, your Kotlin code will compile into machine code and as a framework could be used on device directly.

Brandon, I would love to hear of your progress in this direction, as I’m starting to get into Godot and am very impatient for 3.0 to come out. While I’ll probably do some scripting through Nim, I think Kotlin would also be very interesting to experiment with.