Image for post
Image for post

Fewer crashes and more stability with Kotlin

Florina Muntenescu
Oct 29 · 4 min read

Users expect to have a seamless experience with your app. Crashes can lead to an increase in poor reviews, uninstalls and even damaging your brand perception. From talking to the community we know that one of the main reasons to adopt Kotlin is safer code. In this post I’ll share a couple of the ways Kotlin improved the stability of a few of our partners’ code but we’ll also look at the results of some Google Play store stats and see if there’s a correlation between using Kotlin and the number of crashes (spoilers: there is!).

App quality

The quality of your app doesn’t only have an impact on your user experience. There are several other elements that will be affected by a high number of crashes:

  • App discoverability — Google Play store’s recommendations are composed of a mix of human curation and algorithmic calculations, of which quality is one of the largest considerations.
  • Brand — Your product performance can impact your ratings and reviews, which can impact brand perception.
  • Higher number of (engaged) users — Having improved organic traffic and brand perception can lead to better user acquisition and retention, which can also impact engagement and lower funnel metrics.

What role does Kotlin play in this? We looked at the top 1,000 apps on Google Play and we saw those that use Kotlin have 20% fewer crashes per user than those that don’t.

One example of this comes from the engineering team at Swiggy, where 74% of their code is in Kotlin — they saw a 50% reduction in crashes since moving new feature development to Kotlin.

Avoiding NullPointerExceptions

The #1 cause of crashes on Google Play are NullPointerExceptions. In 2018, the Google Home team started writing all new features in Kotlin and saw a 33% decrease in Null Pointer crashes over one year.

To avoid NullPointerExceptions, you need to make sure that the object references you’re working with are non-null before calling methods on them or trying to access their members. In Kotlin, nullability is part of the type system. For example, a variable needs to be declared from the beginning as nullable or non-nullable. By making nullability part of the type system you don’t have to rely on your memory and knowledge of the codebase, or on compile time warnings (if you annotate your fields / parameters with @Nullable) but rather nullability gets enforced, so you’ll get compile time errors, not just warnings. For ways to handle nullability check out this page.

Avoiding common issues

There are a lot of issues that we developers introduce without realising and a lot of them can be quite subtle and hard to investigate. Here are just a few of these issues that are avoided when using Kotlin.

hashCode() and equals()

If two objects are equal, then their hashcode should be the same — but yet, it’s common to forget to implement one of these methods or to update them when new properties are added to the class. When working with classes whose role is to just hold data, use Kotlin data classes. With data classes hashCode() and equals() is generated for you by the compiler and therefore automatically updated when you change the class’s properties.

Structural vs referential equality

Are two objects structurally equal (have equivalent content) or referentially equal (their pointers are the same)? In the Java programming language, for primitives you would always use ==, therefore, a common mistake is to call == (referential equality) for objects as well, when you actually want to check if they are structurally equal (checked by calling equals()). First, Kotlin doesn’t have primitive types, it uses classes like Int or String; so this means that you don’t need to make this differentiation between objects and primitive types anymore as everything is an object. Second, Kotlin defined == for structural equality and === for referential equality so you won’t be checking for referential equality when you shouldn’t.

When if else if else if else is not enough

When working with enums, you often need to ensure that you’re covering all the possible cases. This leads to using a switch or a chain of if elses. When you modify your enum to add a new value, you then have to manually check each code snippet where you’re using the enum and make sure you’re handling the new case. But this is error prone. In Kotlin, you can rely on the compiler for this, if you’re using when as an expression: you’ll get a compiler error if you’re not covering all possible branches.


The stability of your app is important for your users and your brand. Start using Kotlin to reduce crash rates, keep your users happy and stay on top of your retention and acquisition by keeping a high app rating.

Read more about how you can Build Better Apps with Kotlin, and see how developers have benefited from Kotlin by reading our case studies. To make your first steps with Kotlin, one of the most loved languages in the world, check out our Getting started page.

Android Developers

The official Android Developers publication on Medium

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store