Native Releases Uncategorized

Kotlin/Native v0.4 released: Objective-C interop, WebAssembly and more

We’re happy to announce the release of Kotlin/Native v0.4, KotlinConf 2017 edition! This release adds support for accessing Objective-C APIs on iOS and macOS, WebAssembly target platform, as well as introduces major changes making app development in Kotlin/Native way easier.

Platform libraries

To enable access to underlying operating system interfaces, Kotlin/Native provides a set of platform-specific libraries available to any program targeting a particular platform. Previously, you needed to use the cinterop tool to generate the libraries yourself, and now they’re available out of the box.

The following program demonstrates the use of the new platform libraries in the v0.4 release.

It will read the contents of a file into a Kotlin ByteArray and then will print it to standard output. So now the full power of operating system interfaces is at your hands without the need of explicit interop stubs generation.

Note that we can use Kotlin objects for storing a result of platform call fread, see below in ‘Object Pinning’ section.

iOS and macOS framework interoperability

On Apple platforms, unlike most other platforms, access to system frameworks is provided in the form of Objective-C APIs. To support that, the Kotlin/Native team has implemented an Objective-C interoperability layer. For example, the following code, written in pure Kotlin/Native, will read an application’s resource on iOS:

And the following complete program will render a top-level window on macOS. Note that the window title is in Cyrillic, to show that we perform correct character set conversion in the interoperability layer.

See Kotlin/Native fullstack application iOS client for an example of a complete application for iOS. If you own an Apple or Android device, feel free to see this application in action on App Store and on Google Play.

Object pinning

To simplify using Kotlin objects with C APIs we provide new APIs for typed arrays (ByteArray, IntArray, FloatArray etc.), namely refTo(), pin() and unpin(). See Pinning.kt. They allow to ensure an object is locked in memory, and its data has a stable address, thus allowing to use Kotlin object data directly from C APIs and vice versa. For example, in readFileData() function above we pass pointer to data in ByteBuffer to fread() call.

Improved debugging

Debugging with release v0.4 adds improved inspections, so most variables could be inspected in runtime. For example, if we take the program to read a file from the first section, and compile it with the debugging support (note -g switch), we can perform symbolic debugging and variables inspections.

# bin/konanc kat.kt  -o kat -g
# lldb kat.kexe
(lldb) target create "kat.kexe"
Current executable set to 'kat.kexe' (x86_64).
(lldb) command script import tools/
(lldb) b kfun:main(kotlin.Array<kotlin.String>)
Breakpoint 1: where = kat.kexe`kfun:main(kotlin.Array<kotlin.String>) + 26 at kat.kt:25, address = 0x00000001000023ba
(lldb) print args
(ObjHeader *) $1 = [/etc/groups]


Kotlin/Native v0.4  have an experimental support of WebAssembly (-target wasm32). WebAssembly target is mostly intended to showcase the technology, as it is still not fully production ready due to browser support limitations (mainly around more seamless DOM/HTML5 APIs access and performance of virtual machines executing WASM). However, we’re very interested in feedback from our users, to know how much interest in WASM support is there.

IDE Support

Last, but not the least, we have recently announced an experimental CLion plugin supporting Kotlin/Native, see this post for more details.

Getting the bits

Binaries could be downloaded below:
* x86-64 Linux hosts
* x86-64 MacOS hosts
* x86-64 Windows hosts


Please report bugs and issues in the Kotlin bug tracker. Questions are welcome on #kotlin-native channel on Slack.

Comments below can no longer be edited.

32 Responses to Kotlin/Native v0.4 released: Objective-C interop, WebAssembly and more

  1. Avatar

    Jan Vladimir Mostert says:

    November 16, 2017

    Yay for WASM!

    • Avatar

      Daniel Ferreira Monteiro Alves says:

      November 25, 2017


  2. Avatar

    Shai says:

    November 16, 2017

    How does your GC interact with ARC and workaround the native/Java dependency loop problem?

    At Codename One we solved most of this by avoiding ARC altogether and using a lightweight architecture but historically this has been a really tough problem once you open up the native access to 3rd party developers.

  3. Avatar

    jryan128 says:

    November 16, 2017

    Very interested in WASM. I’d probably start using Kotlin if it fully supported.

  4. Avatar

    Jonnah says:

    November 16, 2017

    My main interest in Kotlin/Native is definitely WASM – I hope you guys get it production ready sooner rather than later. The world is fed up with JS.

  5. Avatar

    Dud says:

    November 16, 2017

    +1 for full WASM support

  6. Avatar

    Stephen says:

    November 16, 2017

    WASM all the way!!

  7. Avatar

    Perry says:

    November 17, 2017

    Will check out the wasm support, but the idea definitely interests me.

  8. Avatar

    jice says:

    November 17, 2017


  9. Avatar

    Per Arneng says:

    November 17, 2017

    WASM is the future and its going to be THE thing on the web for the forseable future. Its great that you are starting support now even though as you say the browsers are missing some important features. But they will come and then its good to be ready.

  10. Avatar

    ligi says:

    November 17, 2017

    Great to hear about Kotlin+WASM – might become really interesting for Ethereum – and Kotlin+Ethereum is already a match made in heaven – was recently talking at DevCon3 about it in the WALLETH deep dive – unfortunately the video is not yet released – but you can find the slides here:

  11. Avatar

    david says:

    November 17, 2017

    How about the memory management on linux ?

    • Avatar

      Nikolay Igotti says:

      November 17, 2017

      Kotlin/Native has same memory mgmt on all platforms – currently it’s reference counting + cycle collector on top of the memory provided by system allocator (malloc).

  12. Avatar

    The dude says:

    November 18, 2017

    If you are serious with Kotlin native then the focus should be webassembly. You are not going to be able to take much marketshare from C++ if you plan to focus on that.

    Think instead of having to learn java, javascript, angular/react, html, CSS, you would need to know Kotlin, html, CSS. This makes it simpler for development.

    This would also reduce code and testing since a lot of code is shared between client and server.

    To make story short, of course you should go for WASM.

  13. Avatar

    Tim Fiedler says:

    November 19, 2017

    WASM +1

  14. Avatar

    john davis says:

    November 19, 2017

    WASM has enormous potential when combined w/ Kotlin. Given C++ coroutines only recently got added to clang, and clang llvm is still a work in progress for webassembly, I would LOVE to use Kotlin/WebAssembly now!

  15. Avatar

    john davis says:

    November 19, 2017

    For ios w/ ARKit, where are the kotlin stubs?

  16. Avatar

    tomschrot says:

    November 19, 2017

    I go for WASM. Unfortunately the compiler crashes with an error… (WIN 10/64 cmd)
    Are there any infos on the environment to use, e.g. JDK Version etc?

    • Avatar

      Nikolay Igotti says:

      November 20, 2017

      Windows hosts not yet supported, please use OSX for now.

  17. Avatar

    Algor says:

    November 20, 2017

    Absolutely WASM++ for me too!

  18. Avatar

    Jasoet says:

    November 20, 2017

    YAY FOR WASM!!!!

  19. Avatar

    rad says:

    November 21, 2017

    wasm is very important!

    native is also very important!!! so many applications can be written by kotlin which need to be written using c++ before. server, client, browser, pc and mobile, iot etc, will all use same excellent language, share same code.

    support kotlin/native!

  20. Avatar

    radxe says:

    November 21, 2017

    kotlin is excellent,
    val shoppingList = arrayOf(“catfish”, “water”, “tulips”, “blue paint”)
    be written
    val shoppingList = [“catfish”, “water”, “tulips”, “blue paint”]

    val occupations = mutableMapOf(
    “Malcolm” to “Captain”,
    “Kaylee” to “Mechanic”

    val occupations = [
    “Malcolm”: “Captain”,
    “Kaylee”: “Mechanic”


  21. Avatar

    Marc Durham says:

    November 29, 2017

    WASM please.

  22. Avatar

    Brian Sletten says:

    December 3, 2017

    Very interested in WASM support.

  23. Avatar

    I'd rather not says:

    December 3, 2017

    Hey! Posted an issue on github as well, but perhaps the writer or some readers have input. I cannot get the uikit sample to run, using xcode 9 beta 2 – I get the error message “A problem occurred evaluating root project ‘uikit’.

    Plugin with id ‘konan’ not found.”

    Any clues?

  24. Avatar

    Andrew Bednoff says:

    December 7, 2017

    Is there planning something like borrow and ownership checking mechanism (uniqueness/linear typing maybe), control of scopes/namespaces lifetimes (also suitable for RAII), as in Rust, for example, for static checking and control of pointers/references for memory and thread safety in Kotlin/Native?

  25. Avatar

    Nikolay Igotti says:

    December 11, 2017

    We’re actively discussing those features since inception of the Kotlin/Native project, and fully aware of importance of proper ownership mechanism. However, our current plan is to offload this analysis from programmers, and use compiler for global lifetime analysis. Thread safety story is already pretty good in current Kotlin/Native, as we do not share object heap between threads, and explicitly transfer object subgraphs ownership, so no concurrent mutation is ever possible.