Question concerning Kotlin native


I just skimmed through the blog post “Kotlin Night in San Francisco Recordings”. It says on one slide:

New Targets:

  • Native
  • iOS
  • Embedded
  • server-side

In the accompanying talk Andrey says at about position 9:38 that there are plans to run Kotlin without a JVM. That sparked my interest. Does that mean there will be a native executable one day for iOS or Linux or something? Sounds really cool!

Thanks, Oliver


Yes, we are going to start working on a non-JVM native compilation for Kotlin. The possible targets of interest are embedded devices (Linux-based, RTOS-based and no-OS), iOS, Linux and whatnot :slight_smile: What platforms get ready first/get more focus is not clear ATM


Woohoo! This sounds cool :-). Does that mean you are going to develop your own GC and own runtime for the respective OS? LLVM?

Being able to share business logic (in Kotlin) between Android/iOS is going to be HUGE… If done well this could be the holy grail for mobile development.


If you want to write your business logic in kotlin for iOS you can use Multi OS Engine by Intel.

1 Like

Yes, LLVM most likely, own GC and other parts of the runtime as well.


LLVM it’s cool, but it distant future.
What about Intel MOE or BugVM?

Will you cooperate with it for better support Kotlin (like with RoboVM)?

1 Like

This sounds really exciting. You guys are really up for something. Gonna rival Go/Delphi in the end …

From what we know, Kotlin works on MOE and BugVM inherits to RoboVM, so we don’t expect issues there.

I’m excited about Kotlin as “a better Java” (much better), which is my interest in the language. I don’t see it competing nearly as effectively in the native-app space. I think modern C++ already has the features I need to write clear, concise code to model and implement systems of arbitrary complexity. It’s the Java interoperability, with support for Java’s amazing ecosystem, that makes Kotlin a compelling newcomer on the programming-language scene. Ameliorating Java’s weaknesses should continue to be the main focus. Just my 2 cents.


What if my kotlin project use some Java class that rely on JNI, will it still work ?

Being native and having GC doesn’t really cut it. That’s the reason why Swift and Rust are poised to succeed C++. Has there really been any consideration for auto memory management (other than GC)?

Our work on Kotlin Native relying on LLVM is still in progress, and we will try to provide smooth interop with regular native code written in C, along with native-friendly memory management scheme. More details to come later this year.


Man, you are building on your language empire ;-).

Hey, is there any early preview of Kotlin native we can try and play with?

Not yet, however we are very busy to make something for you soon.


I am really excited to think about Kotlin native, that would be wonderful! I cannot wait to try it.

If you port Kotlin to .net (core), I think there will be a LOT of developers jumping from C#. It just feels like what C# wants to be, but able to due to backward compatibility. What I have seen, native developers do not prefer GC and heavy runtime components. But .net devs are used to them. And coreCLR and coreFx are rich as gc and standard libraries. CoreCLR was recently provided as an optional gc for Python. Jetbrains are already in dotnet foundation. I’m not proposing to abandon porting Kotlin to native. But porting to .net will have a greater impact, IMHO.

It seems like Scala just released a first version of there LLVM compiler infrastructure! See this.

Is there anything new from our favorite language on the LLVM front?

To deduce any decent considerations it is better to await the first stable version, this is valid for any technology.

The 0.1 version is an opportunity to learn, test and contribute to a project at the risk to throw away your code in any moment, same for Kotlin’s experimental features.

Kotlin LLVM is actually undisclosed but I hope that this kind of news don’t cause an hasty job.

By the way: we are interested to LLVM 4 release (with experimental coroutine support)?