Native Releases

Kotlin/Native v0.7 released: smoother interop, frozen objects, optimisations and more.

We’re happy to announce the release of Kotlin/Native v0.7, May Day edition! This release provides even smoother interoperability with Objective-C and Swift, memory management improvements, global program analysis and performance optimisations. Also numerous bugfixes and optimizations were implemented in this release.

AppCode and CLion Kotlin/Native plugins were updated to work with v0.7, along with minor performance and usability improvements.

Binaries can be downloaded from the following links: macOS, Linux, Windows

Also Linux Snap package is available.

GitHub release page is here.

Smoother interop.

Imagine the following code on Kotlin side, compiled to the framework and later used from Swift.

Before, calling Objective-C APIs like timeIntervalSinceDate() with an object coming from the Swift world was not possible, now one could call it like this:

let now = Date()
print(Common.isItTimeForKotlin(date: now))

Other popular request was ability to convert objects between Swift and Kotlin world transparently, i.e. now one could do

And in reverse direction, i.e. convert Objective-C NSDictionary to Kotlin like this:

and then it could be used as a regular Kotlin map.

When creating UI, it is typical to use initializers override, while Kotlin’s constructors are not virtual. Following snippet would help:

Note that constructor accepting NSCoder is marked with @OverrideInit and is called virtually. Other nice features are ability to interoperate with checked exceptions thrown by Kotlin on Objective-C/Swift side (if Kotlin method is marked with a @Throws annotation).

Memory model improvements: frozen objects, weak references.

Traditionally, Kotlin/Native was trying to avoid shared data as much as possible. However, in some scenarios there is need for some shared immutable data. Typical example is a configuration data, read from the file on startup and afterwards made available everywhere. To achieve such a goal, concept of object freezing is implemented. Object is either in the mutable state and is owned by a single thread or worker, or is immutable, and could be shared amongst multiple threads or worker, and could be freed once all consumers no longer need it.

This code creates a frozen instance and passes it to 10 workers, and they all share the same instance of the configuration. Frozen objects has nice property of concurrent cycle-safe reference counter-based memory management, as during freezing process object graph is condensed to a DAG, and so could be collected basing on reference counter only. If one tries to mutate a frozen object, a runtime exception is thrown. So freezing allows for safer sharing of objects across multiple threads or workers. See this document for more details on concurrency approaches in Kotlin/Native.

Another requested feature is weak references, including weak reference to Objective-C objects. Weak reference allows to know when a certain object is no longer needed, and was deallocated by the memory manager. This allows to implement data structures like caches, or break reference cycles when interoperating with the Objective-C world.

Performance optimisations: devirtualization, box caching.

Kotlin/Native approach to performance is to do as much ahead of time optimisations as possible (contrary to the JVM approach, which does most optimisations just in time). Major enabler of such optimisations is building global call graph with the resolved polymorphism (that is, computing actual runtime type of the variable, not one explicitly stated in the signature or inferred by the frontend). This is possible in the closed world compilation, where all the pieces are known during the final code generation. Kotlin/Native performs devirtualization analysis based on a call graph and cross-module type propagation. This would allow even more optimisations, such as escape analysis for arena-based memory allocator in the future.

Box values for popular primitive types are now cached during compilation, and so are not allocated in the runtime, thus saving memory management overhead.

Comments below can no longer be edited.

9 Responses to Kotlin/Native v0.7 released: smoother interop, frozen objects, optimisations and more.

  1. Avatar

    Jordan Demeulenaere says:

    April 27, 2018

    Thanks for the release ! Let’s hope we will get a better DOM interop for wasm in 0.8 🙂

  2. Avatar

    Benoit Walter says:

    April 27, 2018

    Impressive changes, many thanks! We have been evaluating Kotlin/Native to share the business logic of our app between Android and iOS and got promising results so far. Creating an iOS framework written in Kotlin/Native and use it from Swift is extremely convenient.

    So far, the only limitation we have is support for arm7 (e.g iPhone 4s/5) and bitcode (required for watch and tvOS). Do you have any plan to support those configurations?

    • Avatar

      Nikolay Igotti says:

      April 30, 2018

      Regarding 32-bit ARM, do you indeed have a significant userbase here? We assume that this market is not significant, especially for new apps, so unless strongly convinced we did not plant adding such support.

      Bitcode embedding is popular request, for example, and we are evaluating possibility to do so.

      • Avatar

        Benoit Walter says:

        April 30, 2018

        While I personally agree that it is not important for new apps, we unfortunately still have a significant userbase (a few thousands) with 32bit iOS devices, especially iPads and cannot (yet) drop support for them.

        Sounds great regarding bitcode, many thanks for the update!

        • Avatar

          David De Bels says:

          May 2, 2018

          Agreed on the armv7 architecture. We are currently experimenting with several code sharing technologies and the missing 32bit support is a major bump in the road.

          What we see in our user base is that sspecially on iPad there are still many 32bit devices in use, since those don’t tend to get replaced as quickly as phones.

          • Avatar

            Nikolay Igotti says:

            May 3, 2018

            What is exact version of iOS and CPU you believe is a reasonable lower threshold?

            • Avatar

              Benoit Walter says:

              May 3, 2018

              iOS 9.0 for armv7 would be in my opinion a reasonable lower threshold.

  3. Avatar

    Alireza Naghizadeh says:

    April 28, 2018

    Hi, now that Swift is adding interop with python (which is extremely important for data science) and Kotlin is interop with Swift, can we see Kotlin interop with Python as well?
    see here

    • Avatar

      Nikolay Igotti says:

      April 30, 2018

      Well, technically K/N interops with Objective-C, not Swift.