Kotlin/Native Tech Preview: Kotlin without a VM

We are happy to announce the first Technology Preview of Kotlin/Native that compiles Kotlin directly to machine code. The Kotlin/Native compiler produces standalone executables that can run without any virtual machine.

It is not a fully functional release yet, but you can already play with the technology and take a look at its source code here. The compiler is available under the Apache 2 OSS license.



Kotlin/Native is another step toward making Kotlin usable throughout a modern application. Eventually, it will be possible to use Kotlin to write every component, from the server back-end to the web or mobile clients. Sharing the skill set is one big motivation for this scenario. Another is sharing actual code.

Our vision for inter-platform code reuse is the following: one can write entire modules in Kotlin in a platform-independent way and compile them for any supported platform (currently these are Kotlin/JVM, Kotlin/JS and the upcoming Kotlin/Native). We call these common modules. Parts of a common module may require a platform-specific implementation, which can be developed individually for each platform. Common modules provide a common API for all clients, but other (platform-specific) modules can extend this API to provide some exclusive capabilities on their platform.

Note that we do not intend to make arbitrary Kotlin/JVM programs runnable on Kotlin/Native or Kotlin/JS. It would be equivalent to implementing another JVM, which is both a lot of work and a lot of limitations for the runtime. We are going another way: providing a common language for all platforms while enabling creation of common libraries through seamless interoperability with platform code.


Kotlin/Native uses the LLVM compiler infrastructure to generate machine code. In this preview, we support the following target platforms:

  • Mac OS X 10.10 and later (x86-64)
  • x86-64 Ubuntu Linux (14.04, 16.04 and later), other Linux flavours may work as well
  • Apple iOS (arm64), cross-compiled on MacOS X host
  • Raspberry Pi, cross-compiled on Linux host

More platforms can be added relatively easily, as long as the LLVM support is available for them. We will probably support a few more platforms out-of-the-box in the future.

As usual, interoperability is among our top priorities, and Kotlin/Native can efficiently call C functions and pass/get data to/from them. You can generate Kotlin bindings from a C header files at build time and get fast type-safe access to any API native to the target platform. See detailed instructions here.

Memory management

Kotlin/Native is designed to potentially enable different memory management solutions for different target platforms. For example, in the future it may make sense to have a tracing GC for server/desktop platforms, while ARC makes a lot more sense on iOS. Some platforms may only need manual memory management, and get an even smaller Kotlin/Native runtime in return.

This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point.

Current limitations

As mentioned above, Kotlin/Native is far from complete, so this Technology Preview has a number of limitations that will be eliminated at later stages:

  • No performance optimization has been done yet, so benchmarking Kotlin/Native makes no sense at this point.
  • The Standard Library and reflection support are far from complete, more APIs will be added later.
  • Read more in the Release Notes.

Future plans

We are currently working on the core technology for Kotlin/Native which is the same for all target platforms (compiler, core runtime and library). As a matter of possible future work, we are considering the following possible use cases:

  • iOS applications (reusing code with Android)
  • Embedded systems/IoT (e.g., Arduino and beyond)
  • Data analysis and Scientific Computing
  • Server-side and Microservices (low-footprint executables, utilizing the power of coroutines)
  • Game Development

How to try

We’ve prepared two archives with compiler, samples and documentation: for Mac and iOS and for Linux and Raspberry Pi.

Check out the Github project and Release Notes for instructions.

Your feedback is very welcome in the #kotlin-native channel on our public Slack (Get your invite here.

About Andrey Breslav

Andrey is the lead language designer of Kotlin at JetBrains.
This entry was posted in Releases, Roadmap and tagged , . Bookmark the permalink.

92 Responses to Kotlin/Native Tech Preview: Kotlin without a VM

  1. Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | Ace Infoway

  2. Congrats for this promising tech preview!

    Any chance you could consider WebAssembly as a supported target platform since it is supported by LLVM toolchain? IMO that would the best way for Kotlin to really matter for Frontend development in the long run.

    Could you provide any guidance about what would be needed to be able to compile Kotlin code to WebAssembly via Kotlin Native?

  3. exim says:

    What’s the use of Kotlin without Java libraries?

  4. Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | Kotlin Blog/話題/ノマドアンテナ

  5. obaid says:

    For Kotlin Native i just wana say I LOVE YOU Andrey Breslav.

    • Thanks :) But I’d like the due credit to be given to the Kotlin/Native team headed by Nikolay Igotti.

      • Boris Chernukha says:

        I agree with Obaid. Compilation to native code is a big step forward for Kotlin. The rapid growth of the popularity of languages like go, rust, swift experts of the correctness of this approach. I believe that if it is possible to get rid of the VM without any special technical problems, it is desirable to do so. The choice as to the LLVM backend is in my opinion the most reasonable. Congratulations on this event and wish you much success!

  6. Peter Holák says:

    So is gradle going to be the “official” build system?

  7. soywiz says:

    Wow. This is just awesome. Im really interested in this. Thank you very much for releasing it.

    I’m working on some pure kotlin libraries intended for games:

    I would like to support kotlin native in those libraries. There is possible to create jar files published to maven central that works for kotlin/kotlinjs/kotlinnative?

    Also. Are you accepting PRs for that projects?

  8. Yuri Geinish says:

    Any plans for the Windows compiler host/target compiler?

  9. Даниил Водопьян says:

    What advantages will Kotlin-native bring for “Data analysis and Scientific Computing”?

    How is it different from porting popular DA and ML libraries from Python/R/C to JVM? AFAIK Java is already widely used as a “fast Python for servers”

    • Kotlin/Native has a) fast C interop, b) compiled language that can, for example, allow multiple threads :) This makes it possible to provide a viable alternative to Python as a front-end to the same C-libraries that, for example, NumPy and SciPy are using.

      • Даниил Водопьян says:

        Or, I see! So basically, instead of bringing NumPy to JVM (like Jython couldn’t do), Kotlin-native will use their C API directly, thus reusing their GPU-optimized processing, etc. Nice!

      • Даниил Водопьян says:

        What is the plan for porting the DA and ML libraries? Will JB do it or will it be left for the community?

        Also, will those libraries be available for JVM programs via JNI (so that one could choose whether to go full native or slower native + JVM) ?

      • Kyle Kauffman says:

        I’ve been working on a numpy replacement in kotlin that targets js+jvm: https://github.com/kyonifer/golem. Now that native preview is out i’ll start looking into writing a backend with direct blas access. My eventual goal is to enable writing code in kotlin that could then be deployed on all 3 platforms.

  10. exim says:

    Btw, any chance you’ll add strong and weak reference distinction and get rid of [undeterministic] GC?

    • We’ll see, but nothing prevents this

      • Alfie Kirkpatrick says:

        This is quite important for embedded / IoT applications and one of the main USPs of Rust right now in our opinion. It would be great to see Kotlin alongside Rust in this space!

      • exim says:

        This would be a really killer feature… There is a big market of C++ engineers willing to consider alternatives:

        Rust is ugly and unpractical
        Swift is nice but locked in one platform (also on Linux, but it is somewhat half-baked)

        So you have a big opportunity here. And please don’t forget that the most popular OS, including among developers, is Windows…

    • Erik says:

      Reference counting is not deterministic in any way, and I think having a full ownership system (ala rust?) would significantly change the semantics of kotlin (this is an assumption from the fact that it runs on the JVM, I don’t know the language well).

  11. exim says:

    EDIT: i.e. use deterministic ref-counting….

  12. Does this have any implications for Android’s NDK? Will you be able to directly call C/C++ code from Kotlin, then potentially call that Kotlin code from Java?

    • Yes, we can call C code from Kotlin, and it will likely be possible to make Kotlin/Native code callable smoothly from JVM code. See the interop description.

  13. Lei Feng says:

    No love for windows :/

  14. Tevin Jeffrey says:

    Does it produce a single statically compiled binary?

  15. Pingback: Kotlin/Native Tech Preview: Kotlin without a VM | ExtendTree

  16. A new dev says:

    This is fantastic news, THANKS A LOT!

    One question for creating kotlin bindings for Kotlin, should i rely just on your tool to generate kotlin file, or should i do like in C# to make a C lib (OOP) ?

    I’m not really experienced but i would like to learn from this

  17. Any chance you’ll spin out some kind of Custom IDE for Cross Platform Kotlin development, or are you planning on adding iOS/Mac/etc support as a bundled plugin that Android Studio can consume and use to help build cross platform apps?
    For cross platform compilation are you planning on adding compiler directives to the language so we can for example, make a library (say networking library) that calls OKHttp under the hood on Android, while on iOS use Alamofire.

    • Any chance you’ll spin out some kind of Custom IDE for Cross Platform Kotlin development, or are you planning on adding iOS/Mac/etc support as a bundled plugin that Android Studio can consume and use to help build cross platform apps?

      We’ll see, both options are possible

      For cross platform compilation are you planning on adding compiler directives to the language so we can for example, make a library (say networking library) that calls OKHttp under the hood on Android, while on iOS use Alamofire.

      As the blog post mentions, we are going to support this use case, yes. Most likely, it will not be through conditional compilation, but through a more modular mechanism

  18. Pingback: Kotlin compiles directly to native code via LLVM – Miller Trades

  19. Given support for cross platform development, will there be an IDE plugin for supporting cross platform development? Such that people using Android Studio/IntelliJ can consume and begin using iOS/Mac/etc development, or will this become a new IDE?
    Will Kotlin evolve to support compiler directives in this environment, so we can write platform specific code inside cross platform modules?
    Will this cross platform implementation support KAPT, so we can still use it in other environments, AKA iOS development. That would be very interesting.

  20. Sam says:

    Where do debugging tools fit in the roadmap? IMO this is golang’s biggest detraction at the moment.

  21. Pingback: Kotlin/Native, Infragistics Ultimate UI for Xamarin, ActivePython 2.7.13 and 3.5.3, and Progress OpenEdge 11.7 — SD Times news digest: April 4, 2017 - Khabri No 1

  22. Sam C says:

    For now it is not possible to create a Kotlin library that can be called from obj-c/swift on iOS and from Java on Android right?

  23. Pingback: Kotlin compiles directly to native code via LLVM - The Gizmo Effect

  24. Pingback: Kotlin/Native, Infragistics Ultimate UI for Xamarin, ActivePython 2.7.13 and 3.5.3, and Progress OpenEdge 11.7 – SD Times news digest: April 4, 2017 – Ok Huge

  25. Pingback: Kotlin compiles directly to native code via LLVM |

  26. Horácio Filho says:

    Is it already possible to consume Objective-C Runtime using Kotlin? I have not seen code examples for it.

  27. Jakub Błaszczyk says:

    Interesting, but I think you should focus on polishing JavaScript target more, particularly ts2kt converter which is crucial in js based pipeline.

  28. Pingback: Kotlin compiles directly to native code via LLVM | Subremes Codes

  29. I’ve been glancing at kotlin for some time now but as a developer who doesn’t work with the JVM on a regular basis I’ve prioritized testing the grounds with Scala and Groovy.

    If I will definitely keep an eye open and see if kotlin keeps gaining more traction, I’ve been a little bit worried of it being to niche.

  30. Samuel Pastva says:

    Fantastic news! I am really looking forward to this for scientific computing.

    Keep up the good work!

  31. Yindong says:

    Will you plan to support Embedded systems/IoT device runing without OS? or some RTOS?
    may be LLVM is not fit for that.

  32. Sreenath N says:

    So Kotlin/Native is like C++ with a different syntax?

    • Andrew says:

      Besides great syntax sugar which allows you to skip lots of boilerplate code, you still would have all the other cool features of Kotlin like null-safety, in future — reflection, coroutines, and (I hope, that’s planned) great interop with JVM-based Kotlin code for Android. Also Andrey mentioned plans to work without OS — I tackled a bit with libc++-less environment and it’s a real pain — Rust managed to propose great improvements for that, I’m hoping Kotlin would be usable there too.

      I’m eagerly waiting for ability to build Kotlin-based native libraries to start playing with multi-module projects — very excited with what I saw so far!

  33. Simon Baldric says:

    You guys rock!!! I was about to port a PyGTK 2 application to Python/Gtk 3 and was dreaming of using Kotlin instead. Now this dream comes closer to reality. Keep up the good work!

  34. Pingback: From Kotlin to Java: moving back seeing all the flaws – NamekDev

  35. okapies says:

    Is there any plan to collaborate with Scala Native? They also use LLVM and have same issue about memory management.

  36. Dongqing Hu says:

    Great! Yesterday I was thinking about a language as replacement of Go. Now I see yours!

  37. Pingback: Bookmarks for April 5th through April 6th | Chris's Digital Detritus

  38. Pingback: JetBrains Releases Tech Preview of VM-less Kotlin — ADTmag | US-China News

  39. Pingback: Revue de Presse Xebia | Blog Xebia - Cabinet de conseil IT

  40. name says:

    Not a MacOS user. iOS target support from a non-MacOS host would be useful.

  41. Ridekei says:

    Absolutely great job, Mr.Breslav, and the Koitlin/Native team.

    I am very enthustiastic about Koitlin, Koitlin to make Android Apps… and Koitlin/Native.

    I think you guys are on your way to truly make a big impact on the computer world with Koitlin.

    Ummm…I am sure you’re much smarter than me but may I say two things:

    I think the single most important thing that might affect the growth of Koitlin is:

    I know you guys are doing a good job so far, but…I think tutorials and sample code for projects can go a long way….a really long way.

    For example, make tutorials using Java FX… using Koitlin and the Java FX libraries.

    Make Koitlin tutorials so that many newbies can come in to the Koitlin yard, and see starting help for their next projects – Java FX/Koitlin GUI apps, Android apps, Koitlin/JS website bits.

    I don’t mean to give you advice, you guys have already done great great work!

    The only reason I want to say this is because, no language succeeds greatly if you need to be a really good programmer to see the beauty in it.

    Besides other release complexities and delays, I think that’s why some languages fall off eventually. It’s a great language of course, but you have to be a REALLY GOOD programmer to get in and see the ‘beauty’ of it.

    Please try to make tutorials and sample codes available for a variety of applications and uses. This is how you will keep winning over people daily. When they visit the Koitlin language site and see sample code – they’ll be like ‘oh, wow…let me download this and compile it on my computer.’ Soon they tweak and add their code…and then soon, you’ve won over a new believer. It’s critical to make it easy and attractive for people to ‘check out your site’, then get lured in to just try this sample code which is available…

    And please focus your team on great documentation!

    With abundant tutorials and documentation (well formatted, very legible), Koitlin will take over.

    Easy to access and read – attractive documentation is ALWAYS a winner.

    Keep up the good work, and we all want to see Koitlin grow!

    • Ridekei says:

      I want to correct myself…I was talking about a *particular language…that fell off. Because it became complex, and you somehow had to really study hard to even ‘get’ the language as a newbie. That’s the language that only good programmers could see the beauty of.

    • I totally understand your concern. And by the way contributions are welcome!

  42. Fei says:

    Currently I’m using Xamarin to do cross platform app development. One thing I don’t like is its slow startup time. I wish Kotlin/Native can keep this as one of its performance goal.

  43. Amir Abiri says:

    What I love about this is the potential for standalone command-line tools. This is great for devops, as distribution of script-based or VM-based tools is difficult. Having a single binary that anyone can download (or can auto-update itself) is a huge advantage. Until now the only viable option in this area was GO.

  44. Pingback: 不使用虚拟机的 Kotlin | 神刀安全网

Comments are closed.