What is Kotlin and should we be using it for app development?

Kotlin is an object-oriented programming language for making Android apps that uses Java-like syntax with functional programming features. It was created by Jetbrains, the makers of hugely popular IDEs like IntelliJ and PyCharm, and is used by big companies such as Pinterest, Uber, and Atlassian.

At Theodo, React Native is the language of choice for building apps. And for good reason. It has a rich ecosystem of libraries to use, hot reloading out of the box, is very similar to React which is a hugely popular web framework, and vitally it allows you to compile your apps to both Android and iOS from just one codebase. But this doesn’t mean that we should necessarily use React Native in every case. I will talk through some examples of why Kotlin might be a better choice in some cases.

Why use Kotlin/Java over React Native?

There are many reasons why one may choose to write native code for an app rather than React Native. One of the most common I have seen is API support. Many services that have APIs for apps cannot be used fully within React Native. This leads to developers having to write native code to get the functionality they need. This can be tricky to developers who may not have ever written native code. Kotlin, on the other hand, is strongly supported within the Android ecosystem and is interoperable with Java so it has easier access to these APIs. Any API that supports Java 8 can be easily used with Kotlin.

Another big reason to prefer native code over React Native is performance. For advanced functionality or heavy computation, the overhead of using React Native can considerably slow down an app. Kotlin, on the other hand, appears and acts totally natively without lag.

Many of us have suffered through the pain of having to update React or React Native. It can be a long and arduous task. However, with writing Kotlin, each new version is backwards compatible with the last. That means that even legacy code written by previous teams doesn’t have to be rewritten when updating to a new version of Kotlin.

A big problem with large javascript projects is the errors that can come up due to the lack of typing. This is why many developers choose to integrate Flow or TypeScript to help with this. However, this can be a difficult task, especially if the codebase is already large before you start. Kotlin however is statically typed meaning that there is no need for tools like these to check for type errors.

Another benefit of using Kotlin over React Native is that it is fully compatible with Android Studio, and Intellij. This means you can make use of loads of cool features like advanced code completion, the built in debugger, and gradle integration, all while benefitting from a UI that was purpose built for making Android apps.

Why use Kotlin instead of Java?

Kotlin was created by JetBrains as an attempt to be a more concise and feature-rich version of Java, whilst being designed primarily for Android app development. I understand that writing native code can feel intimidating to many people who have only written Javascript or Python before, but I see Kotlin as a good stepping stone; it has the benefits of writing native code but it will feel more familiar in its functional aspects such as spread, deconstruction, and closures.

Kotlin can also be used to write iOS applications. This is a great benefit when writing applications for both iOS and Android as the application logic can be shared between the two. However, the rendering code is platform specific and thus must be rewritten for each.

A great thing about Kotlin is that it’s fully compatible with Java. This means that Java code can be inserted into it, or it can be inserted into a Java codebase. This can be helpful if you have a large codebase of legacy code written in Java which you need to add new features to.

Kotlin has all the features of Java 8, plus more. This means you get lambda functions, static functions, streams and nested classes from Java 8, on top of immutable variables, method references, methods without classes, extension methods to classes, closures, spread and deconstruction. As well as all this, built in @Nullable and @NonNull mean that there are no Null-Pointer Exceptions which comes as a great relief to those who are apprehensive to get started writing native code.

Writing Kotlin, you can use any library that is compatible with Java 8. As well as this, Kotlin has a lot of libraries written for it such as kotlinx-coroutines-android and rxkotlin for writing asynchronous and event-based programs, just to name a few. Whilst still perhaps not as many libraries as React Native might have, there are still a huge number of libraries to take advantage of when writing Kotlin.

Drawbacks of using Kotlin/Java over React Native

Sadly no tool is perfect and there are many reasons why you may choose to go for React Native over native code. The main reason is iOS compatibility. Yes, Kotlin code can be compiled to objective C, and is bi-directionally interoperable with Objective-C and Swift. But you still have to write separate render code for iOS and Android. This could take a long time and is the main reason why one would choose React Native.

Another big reason is that writing React allows hot reloading straight out of the box. While Kotlin does allow for hot reloading, it can be a pain to set up and work unreliably. Hot reloading can really speed up development and if you’re used to having it you may sorely miss it if you can’t get it working for Kotlin development.

Conclusion

If you want to get the best of both worlds, it is possible to use React Native to implement the frontend code and Kotlin to implement the backend of your application. This means that you get the speed improvements and Java-compatible API integration of Kotlin, but only have to write one codebase for both Android and iOS. As well as this, you can make use of the front-end libraries available to React Native.

JetBrains have created a library called kotlin-wrappers which contains wrappers to use Kotlin with React, Redux, styled-components, and React Router DOM, amongst others. There are also a few other libraries online which do similar things.

This is a very new field and there are not many people using it just yet, so there may be some teething issues. One possible problem is that passing the store via props to the component won’t work because the state will become immutable. There may be libraries to help with this, and if not then I’m sure there soon will be, but this could be a big pain point.

This emerging combination of languages looks like a really new, interesting addition to our use of React Native here at Theodo. I hope I will on the next applicable project to test out this exciting new tech.