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.

WebAssembly

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

Feedback

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

About Nikolay Igotti

Kotlin/Native Tech Lead
This entry was posted in Native, Releases, Uncategorized and tagged . Bookmark the permalink.

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

  1. Shai says:

    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.

  2. jryan128 says:

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

  3. Jonnah says:

    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.

  4. Dud says:

    +1 for full WASM support

  5. Stephen says:

    WASM all the way!!

  6. Perry says:

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

  7. Per Arneng says:

    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.

  8. ligi says:

    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: http://walleth.org/2017/11/09/DevCon3-WALLETH-Recap/

  9. david says:

    How about the memory management on linux ?

    • Nikolay Igotti says:

      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).

  10. The dude says:

    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.

  11. Tim Fiedler says:

    WASM +1

  12. john davis says:

    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!

  13. john davis says:

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

  14. tomschrot says:

    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?

  15. Algor says:

    Absolutely WASM++ for me too!

  16. rad says:

    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!

  17. radxe says:

    kotlin is excellent,
    can
    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”
    ]

    thanks!

  18. Marc Durham says:

    WASM please.

  19. Brian Sletten says:

    Very interested in WASM support.

  20. I'd rather not says:

    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?

  21. 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?

  22. Nikolay Igotti says:

    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.

Leave a Reply to Andrew Bednoff Cancel reply

Your email address will not be published. Required fields are marked *